i don't use smtp auth, so i wouldn't know. i thought you were
claiming that most providers these days are doing smtp auth.

I was stating that most mail CLIENTS (Outlook, Thunderbird, etc) tend to prefer any mangled authentication method in favour of sending a password in clear text, based on my observations.  Even better, many (especially newer ones) tend to use challenge/response algorithms for SMTP-Auth for example, which ensure one-time use, and prevent creating an open relay if the connection is viewed.

Now, I'd also argue (unrelated to my previous e-mail) that more and more ISPs are turning to SMTP Authentication and blocking port 25.  This number is growing, but based on the customers who contact us, there seems to be more regions with this upcoming issue.  Mainly this is to prevent worms from sending mail on their own (port 25 blocking).

The SMTP Authentication is more popular because mail no longer comes from an IP, but instead comes from an e-mail address.  With pop before smtp, you know that has a virus or is relaying Spam through your server, or is producing a lot of bounces, who's settings can be easily obtained and used via MAPI.  With smtp authentication, you see in the headers that the user is [EMAIL PROTECTED]@ and that's on mail that goes out, Spam reports that comes back, etc.  It associates the connection with a username in addition to an IP, which is really what matters.
it's reliable
Except when it's done in the wrong order, which some mail clients do... or if a users' IP changes.
, it's simple, it's low overhead
You sure about that?  Every successful POP/IMAP authentication will do a CDB lookup for the IP address, and if not found will add it to the open-smtp file, expire old entries, and then rebuild the CDB file.  CDB is fast to read, but building it, while not very slow, isn't super-quick.  Each future POP authentication will update the expire time of the open-smtp entry and rebuild the CDB file again.  So for every pop authentication you have a CDB rebuild, versus a CDB read. [note to see the benefit of not updating it, you'd need to phase it out and then disable the feature or it'll happen anyway].
. if someone believes their email is important enough that
someone would want to sniff the line to get it, then they should be
using PGP or some other means of making the actual content secure.
It's deceptive and lying to the user really to use SSL and think it's secure.  While your [not you, but the gp] mail server may have the TLS patch and SSL ports, others may not.  So you encrypt your super-secret message thinking it's going from your computer to the end encrypted... but it's not.  It's encrypted to your mail relay.  Then it's decrypted and put onto disk in CLEAR TEXT.  At which point it's then sent to another mail server... which could be encrypted or not.  In the end, the plain text insecure file sits on a final mail server, and then is picked up by the user, likely unencrypted and stored unencrypted on a workstation that's probably not secure.

In any case, the point is that no matter how you look at it, SSL from the client to mail relay or client to POP server is one part of the process, and creates a false sense of security.
in my opinion, of course.
Naturally... Of course most of what I say is my opinion on the matter.  I'm sure there are many schools of thought, but we've transitioned mostly from POP-before-smtp.  It's difficult, and has been YEARS in the works to detect and transition users (similarly difficult was moving from ip aliased domains to using [EMAIL PROTECTED] authentication).  The end result is that it's easier to track down and follow mail when it needs to happen.


Reply via email to