At 22:40 +0200 on 05/30/2005, Markus Stumpf wrote about Re: MTAMARK
(was: SPF I-D for review: draft-schlitt-spf-cla:
[...] if the connection originator cannot SMTP AUTH
or SMTP after POP or whatever. As MSAs are not allowed to accept connections
that are not authenticated
[due to being on Port587 which per the RFC requires SMTP AUTH]
MTAMARK is irrelevant for them.
In my Opinion relying on SMTP AUTH is foolish so long as it is
implemented (as it usually is) in an unsafe/insecure manner. So long
as the ONLY SMTP AUTH methods that the MSA offers is Login and Plain
you are NOT secure and your UserID/PW pair is not protected from
anyone who is monitoring the connection (such as being the Hotel
Ethernet or WiFi Provider, or is listening to the unencrypted WiFi
Connections), has (as occurred a few months ago to my ISP [Panix])
hijacked the DNS to point at their own SMTP Servers, or is an ISP who
does "Port25 Blocking" by not blocking the Port25 Connection Attempt
but by Hijacking the connection and force routing it to a ISP
Provided MSA Server. So long as the MUA attempts to use Login or
Plain AUTH it is exposing the UserID/PW pair to anyone who is
monitoring the connection. Only a use of AUTH CRAM-MD5 (or another
one-time encryption handshake) or a Port465 SMTP-over-SSL Connection
protects the UserID/PW pair during the handshake. Even the offer of
CRAM-MD5 (along with Plain and Login) is insecure so long as the MSA
does not support CRAM-MD5 and thus is forced to use the insecure
handshakes.