[Dovecot] vpopmail

[Matthias Andree]

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.
> 
> 1. 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.

> 2. Would you be able to also explain what do you mean by "dangerous"?
> 3. 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