On 2005-05-12 12:28:09 -0600, Bryan Scott wrote:
Would the sending server DATA for the first recipient and
reconnect for the next ones?
The RFC's definitely require that a 4xx in the RCPT TO: phase be treated
as a temporary error for that recipient only (think disk quotas), so any
MTA that doesn't requeue is broken.
Consider also that some recipients may not exist (account deleted, typo
in original sender's message).
Why not just send a 5xx for the specific recipient? I don't know why
you would want a 4xx if you're going force a reconnect just to reject it
anyway.
Because you don't know yet if you are going to reject it. Consider the
use of a content-filter which is configurable per user.
You are receiving an incoming SMTP connection:
EHLO foo.sender.invalid
MAIL FROM:<someone@sender.invalid>
RCPT TO:<alice@recipient.invalid>
RCPT TO:<bob@recipient.invalid>
RCPT TO:<charlie@recipient.invalid>
RCPT TO:<debbie@recipient.invalid>
DATA
Subject: Enlarge your INBOX!
We will send you 200MB of spam per month, guaranteed!
.
According to their different filter settings, alice and charlie want the
mail rejected, bob wants it to be marked up as possible spam, and debbie
wants to receive it unaltered.
How do you handle that? You don't know that the message has to be
rejected for some recipients until after you have received the message
and run the content filter - but then you can only accept or reject it
for all recipients.
The easy solution is to accept it for only one recipient at a time:
EHLO foo.sender.invalid
250
MAIL FROM:<someone@sender.invalid>
250 sender ok
RCPT TO:<alice@recipient.invalid>
250 recipient ok
RCPT TO:<bob@recipient.invalid>
450 only one at a time, please!
RCPT TO:<charlie@recipient.invalid>
450 only one at a time, please!
RCPT TO:<debbie@recipient.invalid>
450 only one at a time, please!
DATA
354
Subject: Enlarge your INBOX!
We will send you 200MB of spam per month, guaranteed!
.
550 Spam detected.
If the client is a legitimate MTA, it will generate a DSN, stating that
the message could not be delivered to <alice@recipient.invalid> and will
retry for the other three recipients:
EHLO foo.sender.invalid
250
MAIL FROM:<someone@sender.invalid>
250 sender ok
RCPT TO:<bob@recipient.invalid>
250 sender ok
RCPT TO:<charlie@recipient.invalid>
450 only one at a time, please!
RCPT TO:<debbie@recipient.invalid>
450 only one at a time, please!
DATA
354
Subject: Enlarge your INBOX!
We will send you 200MB of spam per month, guaranteed!
.
250 Queued!
Now it has successfully delivered the mail for bob and will retry for
the other two.
The main problem with this solution is that many MTAs will retry only after
the queue interval (typically several minutes to a few hours, but
sometimes with an exponential backoff). If the list of recipients is
large, it will take a long time to deliver the mail to all recipients (I
have seen legitimate mails to 100+ recipients in our logs - assuming a
queue interval of 30 minutes, that means more than two days until it has
been delivered to the last recipient).
A smarter approach (which I think I proposed on this list before) is to
assume that for most messages with multiple recipients either all
recipients want it or none. And for those messages which only some want,
the decision will be the same for each recipient as for other messages
with the same sender. So we do the following:
For the first message from this recipient, accept all RCPT commands.
Run the filter on the message. If it returns OK for all recipients,
accept the message. If it returns DENY for all recipients, reject the
message permanently. Otherwise, reject the message temporarily, and
store the tupels (sender, recipient, set) in a database, where set has
one value for all recipients which would have accepted the message and
another value for all those who would have rejected it.
The next time the the message is received, we can look up the set values
from the database: We accept all RCPT commands for those recipients
with the same set value as the first recipient, and reject them
temporarily for all others. So the chance that content filters will now
"vote" the same for all recipients is very high.
This should reduce the number of retries from n-1 to 2 in the typical
case.
I eventually plan to get to a per-user config (like Gavin built) that
would allow some users to get everything (spam trap) and others to block
all of it, and this would certainly help that.
At the time of the RCPT command you generally don't have enough
information to decide whether you want to accept or reject.
hp
--
_ | Peter J. Holzer | Weil wir die materielle Welt nicht so
_|_) | Sysadmin WSR | wahrnehmen, wie sie ist, sind Sachen wie
hjp@hjp.at | JPEG, MP3 usw. möglich.
__/ |
http://www.hjp.at/ | -- Heiko Schlenker in drsm.