Re: [exim] Setup for authenticated submission

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