I'd like to propose two new items for the WishList:
1) TLS support (requires external SSL library)
There is a separate SMTPS port currently listed by the IANA;
but according to draft-hoffman-smtp-ssl-08 widespread consensus
is that it should be abandoned. That draft specifies a new
STARTTLS capability to allow negotiation of an authenticated
and/or secured connection after the EHLO.
2) SASL (RFC-2222) support
The Simple Authentication and Security Layer was originally
proposed for IMAP; but is general enough to apply to almost
any of the application-level Internet protocols. It provides
a mechanism to negotiate arbitrary authentication and security
mechanisms. It's application to SMTP is proposed in draft-
myers-smtp-auth-11.
Either of these extensions would allow for the possibility of much finer
grained control over who is allowed to relay by making it possible to
authenticate individual clients.
SASL and TLS can work together either by using TLS as a SASL-negotiated
mechanism; or by negotiating a TLS connection first and then performing
the SASL authentication over the encrypted link.
The TLS extension should probably be done first; since it is supported
by at least one MUA which is likely to gain widespread use (Netscape 4.5).
Simple TLS handling to provide optional encryption is probably a fairly
easy extension using SSLeay. The interesting part will be designing the
necessary exim config extensions to specify the required authentication
matching to restrict relaying.
The basic SASL framework should also be fairly easy to implement. Then
comes the problem of identifying available mechanisms... (I haven't
looked into this very deeply; but it might be reasonable to have a separate
generic SASL library and API which could be easily used to support any
protocol that has SASL extensions.)
-Pat
P.S. I'd volunteer to do this; but as a US citizen, I probably
couldn't make it widely avaliable.
--
*** Exim information can be found at
http://www.exim.org/ ***
