On Thu, Jan 19, 2006 at 12:54:34AM +0800, Bill Hacker wrote: > Kjetil Torgrim Homme wrote: [>> Bill] [>>> Kjetil]
> 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. STARTTLS is almost, but not quite entirely, useless on port 25. >> fair enough, but this is at odds with Internet standards > Depends on which rev/age of which Request For Comment you choose. How much do you know about the IETF Standards Track? This comment would appear to suggest that it's not a lot. (Note here the difference between: STANDARD, PROPOSED STANDARD, RFC, Internet-Draft). > 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. These comments are meaningless. >>>> 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. Well, well, an interesting idea of an argument, so I'll jump in. Out of interest, the certificate you present as a server cert? It might either be (a) self-signed or (b) signed by a certificate authority. If the latter I'd be very surprised if the signature algorithm wasn't RSA-MD5 (and collision certificates *have* been generated). If (a) then how does SSL/TLS actually protect you (think man-in-the-middle here)? > 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. Well, this is all very well, but let's suppose, for a second, that I have a work laptop using your service to send mail from my work address, and some random system to send mail from a home address or vanity domain. I have to authenticate to both. Why make yours different (yes, sure you can) from this, just so actually it's more pain for me in the end? This sort of thing is not actually a win for your customers, and it's probably not a win for you, in terms of your support calls, but hey, you can just carry on living in your own planet, because it does only affect your customers (unlike, say, running an open relay). Cheers MBM -- Matthew Byng-Maddick <[EMAIL PROTECTED]> http://colondot.net/ (Please use this address to reply) -- ## 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/
