> On the other hand, the fact that "tls_privatekey" requires a group
> that exim is a member of derives from the fact that (a) the exim
> user needs read access, and (b) it isn't world-readable (for obvious
> reasons). The fact that "tls_privatekey" must be readable by exim I
> presume is for using STARTTLS for sending messages, although the TLS
> error message about the "tls_privatekey" path occurred on a received
> message. (I questioned the need for access to the private key to
> receive a message, not considering usage in the other direction.)
I think that you have TLS backwards here.
In STARTTLS SMTP (as in HTTPS), it is the *server* (not the client)
that has a TLS certificate and must authenticate that certificate to the
client as part of setting up the TLS-encrypted channel between them.
Thus when Exim is receiving email it must always have access to the
private key for its TLS certificate (and because Exim may decide on
what certificate to use relatively late in the process of receiving
email, well after it has dropped root permissions, your TLS keys must
be readable by Exim's UID or group).
When sending email to other SMTP servers, Exim can (and will) use
STARTTLS without even having a TLS certificate available. The only
time it needs a TLS certificate and access to that certificate's
private key is if it is sending a client certificate to the remote
server, and I don't think that's the default behavior.
- cks
