[Top] [All Lists]

Re: MTAMARK (was: SPF I-D for review: draft-schlitt-spf-classic-01.txt)

2005-05-30 20:36:29

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.