Kjetil Torgrim Homme wrote:
*SNIP*
there were no Internet standards starting in encrypted mode until the
publication of SSH as RFC 4250..4256. so this month, this piece of
trivia changed, but it didn't change the philosophy of IETF in the
design of Internet protocols. LDAP, IMAP, SMTP, etc. etc -- it all
starts unencrypted and negotiates afterwards.
Heavy sigh....
Find a (probably *BSD) box that has been running for six or seven years,
find these in /etc/services:
smtps, spop, pop3s, imaps, etc.
Change to Requests For Comment are never-ending.
Ports still work as they are told (locally).
Support for these old standbys in for example, Mozilla Mail, and scads
of older MUA's wasn't added yesterday....
All STARTTLS brought to the party was the ability for a 'stranger' to
seek one standard port, then adapt to what was offered by 'negotiation'.
That has immense value on port 25, and 'public facing' MTA's less so on
other ports or private/internal MTAs.
what happens
after initial EHLO handshake will depend on negotiations between server
and client.
Only if you do not want it to begin life in an SSL 'tunnel'. We do.
fair enough, but this is at odds with Internet standards
Depends on which rev/age of which Request For Comment you choose.
Everything is in compliance with some, at odds with others - current or
otherwise.
'Internet Standard' is a goal - and a desireable one generally - but not
a reality.
TWX, TELEX, and RTTY, OTOH, *did* have 'standards'. Most were very
rigid ones, too.
Likewise SNA, HDLC, X.25, X.75, and so on. But we had less room for
innovation in those days.
Few RFC's get adopted immediately, entirely, or as widely as they might be.
Look at the discussion on RFC-mandated domain_literals (which we
support, but few others here do, BTW).
it is NOT required to use STARTTLS, many prefer to use
CRAM-MD5 or similar schemes which aren't vulnerable to sniffing.
How, pray tell, is the know-long-ago-compromised MD5 less 'vulnerable'
than the
current higher-level releases of SSL/TLS?
I didn't make such a claim. (and CRAM-MD5 is not compromised by MD5
collision attacks, anyway.)
Be that as it may, (not betting either way...) plaintext inside of a
pre-existing SSL tunnel is *way* easier to use, and no less secure, *so
long as* you do not permit 'fallback' to unencrypted.
Forcing SSL/TLS-on-connect by port 'up front' in the configure guards
against that possibilty, whereas an obscure coding error in your
authenticators might permit fallback to plantext with 'negotiated' TLS.
Belt and braces....
YMMV,
Bill
Bill
--
## List details at http://www.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://www.exim.org/eximwiki/
