On Sun, 04 Jun 2006, C J Kenneth Tan wrote:
Thanks for the pointer. I see that you put on the Wiki claiming that SMTP AUTH is the alternative.
Indeed.
For the rest of this message, assume "DRAC", "POP-before-SMTP", "IMAP-before-SMTP", "SMTP-before-POP" and "SMTP-before-IMAP" to be mutually synonymous. These are one specific implementation (DRAC) and four names for the same scheme.
I was reporting that using 1.0.beta8, vpopmail's pop-before-smtp functionality stopped working. Is intentional?
I don't know if it was intended by the person making the change. I have never used vpopmail in production, and I don't like the vpopmail scheme that is wedded to the buggy qmail.
I didn't see any relevant changes in the ChangeLog file.
- Would you be able to explain to me how SMTP AUTH prevents virus relay that cannot be accomplished with POP-before-SMTP?
POP-before-SMTP "authenticates" an IP address (and behind NAT, perhaps a whole LAN) for relay for a given time span, anything between a few and 60 minutes, regardless of what's behind the IP address. In dynamic IP environments (DHCP, PPP dial-up), reassigned IPs may authenticate the next site/user to get your IP.
SMTP AUTH authenticates only a single TCP connection made by a single user for relay through the very same TCP connection, thus, effectively, a single users's single application's "send mail" operation.
A - With dynamic DNS, the DRAC server does not know that the client has gone away and been replaced by another, possibly infested, server, and permits relay to them.
B - Also, if using several machines behind a NAT or masquerading router (possibly WLAN without WPA2 -- many ship with "open" or "WEP" networks), the whole LAN is authenticated for the given time. If there are untrusted users, they can wreak havoc and shift the blame on you.
C - Only important for shell hosts with many users, one user authenticating on a given host also gives implicit relay permission to all other (possibly hundreds of) users on the same host. Again, malicious users can foist the blame upon you.
Note that A, B and C use YOUR credentials, so unless you can prove you lost the IP and which IP address you got, you're liable for all abuse.
SMTP AUTH authenticates a single end-to-end TCP connection, the same through which the messages are relayed. If the connection is terminated properly (all messages sent), times out, the client changes IP, whatever, the relay permit ends. It doesn't apply to other users on your computer, other applications that you run, other computers in your NATed LAN, or the next dialup user to get your former IP address assigned.
All in all, DRAC is only useful for a completely trusted LAN in a family or similar, when the authenticating host has a static IP. In such situation, DRAC isn't needed for static IP but can just allow relay to the static IP.
Thus, DRAC is dangerous in scenarious where it could be useful, and useless in scenarios where it could be used safely.
To make a long story short: DRAC and other POP-before-SMTP or SMTP-after-POP schemes should be prohibited and stipulated in the Penal Code.
- Would you be able to also explain what do you mean by "dangerous"?
- Would you be able to also explain what do you mean by "major security risk"?
These are inseparable. "Dangerous" or "security risk" means that you are giving relay permission to people you don't know or you don't trust or you otherwise do not mean to give relay permission, and one malicious user or innocently infected machine can spam viruses/phishing/whatever on your account.
I have received messages off-list (hence I cannot reveal sustaintable identifying information to substantiate this claim, you'll probably - given you know how to work scientificially - ignore this rather than take my word for it) confirming virus incidents in SMTP-after-POP schemes.
If you have an outbound router running Postfix or Exim, either is capable of authenticating depending on sender's address (for Postfix, you need a recent 2.3 snapshot - I'm running such a version and it works well for me in production).
HTH,
-- Matthias Andree