In article <E11CfBt-0004Sg-00@???>,
Nigel Metheringham <Nigel.Metheringham@???> wrote: >sl@??? said:
>> Has any thought been given to adding SSL (level 2) support to exim to
>> allow secure inbound connections?
>
>Personally I would want to avoid embedding that sort of thing into exim
>- it would mean the various distribution mirror sites having to
>reconfigure to avoid falling foul of the US spooks. Additionally at
>this stage working our exactly what you want to do would be
>problematic, so I would lean towards using the stunnel type stuff as a
>front end to exim. With a very small amount of additional coding
>stunnel could be made to invoke exim in SMTP mode having passed it the
>appropriate parameters as to originating IP etc.
The suggested mechanism for SSL and SMTP is described in RFC 2487.
It mandates the addition of a STARTTLS command which pretty much does
what you would expect when used by the client (the server says huh
I don't know what STARTTLS is, I don't want to do it, or sets up a TLS
connection).
There are some wrinkles WRT to authentication issues once the TLS
connection is setup. A client may wish to issue a QUIT if it does not
recognize the server cert for example. This can be pretty much ignored
by the server initially (i.e. the server CAN use the client cert to
authenticate the user but it is not REQUIRED to do so).
Once the TLS connection is setup the SMTP protocol is reset to the
beginning. All information previously collected is discarded and the
protocol is restarted. I.e. the client will issue a new EHLO command
and the information returned by the server may be different than
what was returned in the original status.
Presumably the code to recognize STARTTLS and use the OpenTLS API should
not be a problem WRT to crypto export.
And turning it on and off via the configure either explicitly or
auto-magically if OpenTLS libraries are installed on the development system
is not difficult.
