On Fri, Jan 04, 2002 at 08:27:17PM +0000, gARetH baBB wrote:
Is there any likelyhood of STARTTLS/STLS support being added to fetchmail
for POP3/IMAP/SMTP ?
Got a specific application where it is needed?
The current "well known port" SSL support seems to be well on the way out
of fashion (thank god).
Hmmm... Funny... Considering that all the clients I know,
OutLook, Netscape, Mutt, for pop3 and imap switch to the alternate ports
and don't support STARTTLS on the non-encrypted ports, I don't really
see any evidence for that comment. What do you have to back that
statement up?
Do you know of any clients or servers which are dropping support
for "well known port" SSL for pop3 or imap? (Smtp is a totally different
story.) Do you know of any servers which use to support "well known port"
which are no longer supporting it? I just noticed that the imap and pop3
servers on RedHat are now supporting "well known port" SSL natively and
I no longer need to use stunnel with them (yes, they also support STARTTLS,
but "well known port" is still there as well)! I don't see any evidence that
"well known port" SSL support is "well on the way out" in any way shape
or form. I don't see were deployed support for it has abated one iota.
If anything, for pop3s and imaps, it's present anywhere and everywhere that
STARTTLS pop3 and STARTTLS imap is present. Where did you come to that
conclusion that it's on the way out.
In fact, the "well know port" mode continues to be very popular
since it lends itself to using firewalls to selectively block unencrypted
access across security zones and helps with proxying (unencrypted gets
proxied while encrypted goes direct). I'm now beginning to see some support
for STARTTLS in the imap and pop3 daemons being distributed with the distros
but they also support "well known port" mode as well. STARTTLS really
doesn't seem to offer much advantage over "well known port" mode for
services which already have allocated SSL ports, unless you started to
see some servers that were only supporting STARTTLS, and I'm not aware
of any. Since the ports are allocated for both imaps and pop3s, there
is no reason from the "port scarcity" basis, either since those ports
will not be reallocated, so they are a given factor with or without STARTTLS.
Now, of course, IANA rescinded the port allocation for SMTPS
so STLS is the only officially santioned way to support SMTP over TLS.
That is supported under recent versions of sendmail. But... Unless
fetchmail is delivering mail remotely, I don't see a crisis need for
it there either. Last I looked, Exchange and Outlook, and Outlook Express
were all supporting SMTPS over port 465 (the rescinded port) and not
supporting STLS (could be wrong on that last point, but I can't find it).
That may have recently changed with XP, but seem to be true with W2K and
Office2K.
Now, STARTTLS may be a good thing to add in, but it is protocol
dependent and SMTP has an explicit you MUST support non-TLS connections
for compatibility reasons (RFC 2487). Pop3, IMAP, and SMTP all have to be
individually coded for STARTTLS/STLS. The first two are documented in
one RFC (2595) while the later is documented in a different RFC (2487).
For imap you have to check capabilities and then reset the capabilities
after the STARTTLS acknowledgement. I haven't looked at pop3 deep
enough yet, but the initial recognition and setup will be different
there, too. So each protocol module will have to be enhanced for STARTTLS.
I've got one server against which I would be able to test pop3 and
imap STARTTLS and NONE that I can test smtp/STLS against. But if I were
to tackle the STARTTLS can of worms, I would start with STLS for SMTP
(since pop3 and imap are sufficiently covered by "well known port"
SSL and I know of no servers that support STARTTLS that don't support
"well known port" SSL). So the only real advantage, feature wise, would
be SMTP/STLS, but I have no clients and no servers that support it and
no real serious need in fetchmail (since fetchmail is generally deliverying
mail locally and the RFCs mandate that non-TLS mail must be handled in
the local case).
If you want to dig in, be our guests, by all means. I'll even
consult a bit about the structure and function of the SSL code that's
in there. But I don't have any plans on the table for it at this
time unless I need to learn that bit of protocol for some other
external reason.
_______________________________________________
Fetchmail-friends mailing list
Fetchmail-friends(_at_)lists(_dot_)ccil(_dot_)org
http://lists.ccil.org/mailman/listinfo/fetchmail-friends
Mike
--
Michael H. Warfield | (770) 985-6132 | mhw(_at_)WittsEnd(_dot_)com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!