On Tue, Nov 24, 2015 at 11:08:55PM +0000, Brian Spraker wrote:
> Adding in the ability to accept TLS for authentication of clients to the
> Exim mail server - and for the Exim mail server to use TLS between other
> servers.
> Part 1 is done - allowing Exim to use TLS between servers.
> Part 2 is more difficult. I have setup a specific port to require TLS,
> but I am not able to allow TLS and non-TLS on the other ports. It seems
> to either be required that it is on or off.
> With migrating over to TLS, the non-TLS access needs to remain until all
> users are changed over. Is there any directives that can be set to do this?
The subject speaks of TLS for "authentication", not mere "encryption".
Presumably you have client certificates in mind? Is this for port
587 submission? Or for some sort of port 25 whitelisting approach?
On the server end the purpose of TLS authentication is not so much
channel integrity, but rather access control (authorization). If
that's what you want, TLS supports non-mandatory requests of client
certificates. In combination with STARTTLS it is possible to have
the following policies:
* TLS on connect on port 465 for submission with no client certificates
* TLS on connect on port 465 for submission with optional client certificates
* TLS on connect on port 465 for submission with mandatory client certificates
* Optional STARTTLS on port 25 and/or 587 with no client certificates
* Optional STARTTLS on port 25 and/or 587 with optional client certificates
* Mandatory STARTTLS on port 25 and/or 587 without client certificates
* Mandatory STARTTLS on port 25 and/or 587 with optional client certificates
* Mandatory STARTTLS on port 25 and/or 587 with mandatory client certificates
With "mandatory client certificates" the TLS handshake can be
aborted if client certificates are not presented.
After the TLS handshake is complete, provided you've requested
client certificates, you should be able to make access control
decisions based on the information (trust + subject name or
fingerprint) in any presented client certificates, and take
appropriate action if no certificate was presented or TLS was not
used.
With STARTTLS (ports 25 and 587) rather than TLS on connect, you
obviously can't enforce TLS before EHLO and STARTTLS, so if you
want "mandatory STARTTLS" you'd enforce it for AUTH by not offering
AUTH before STARTTLS and for mail delivery by rejecting "MAIL FROM:"
if TLS is not in place.
Once you have "MAIL FROM:" and "RCPT TO:" and possibly TLS with a
client certificate, you can make appropriate decisions on whether
to allow the mail transaction to proceed.
So the first step is to be explicit about which of the above is
what you're looking for.
--
Viktor.
