On 03/02, Russ Allbery wrote:
> >> Today's proxies could provide authenticated mail submission for roaming
> >> users. Tomorrow's proxies could support backup servers, faster message
> >> injection, and maybe even strong encryption.
> > Yeah, the only question is: WHO will write such proxy? ;-)
> We did, for IMAP and POP. Was easier to write a proxy that spoke Kerberos
> than it was to try to get vendors to support Kerberos. SMTP is even
> simpler than those. (*Much* simpler than IMAP, which is a royal pain of a
> protocol to write software for.)
Is your proxy in public domain, GPL or whatever? :-)
> > BTW, correct me if I'm wrong, but I never saw any good SMTP
> > authentication schemes -- all of them send the password in clear :(
> ssh tunneling should work fairly well. Also, there's no particular reason
> why one couldn't wrap SMTP with a SASL negotiation, and have the proxy and
> the server take care of that and then just expose regular SMTP to the
> client.
RFC2222 was written in 1997, and now 1999. We still do not have
common SMTP authentication. Yes, everything above CAN be done, but
it's too complicated for an average programmer, and there are a lot of
assinine problems with strong encryption like U.S. export troubles,
prohibited strong cryptography in Russia, etc, etc. What we really need is:
1. Simple SASL implementation in public domain, available to everyone
without any restriction (quite probably it was done alredy),
2. Easy to use proxy for end-users, speakin this particular SASL, and
3. Someone who will patch every popular MTA and bugger MTA authors
to include these in the standard distribution. You know, 99.9% of mailers
work in their default configuration...
This problem can be solved only with complex actions -- both
programming and lobbying particular implementation (I don't like
the idea of free-for-all authentication methods -- Micro@&#*^$ will
come up with their own for sure). And lobbying is much more important...
--
Roman V. Isaev http://www.gunlab.com.ru Moscow, Russia
