On Fri, 27 Apr 2018, Dianne Skoll wrote:
Hi,
I have reluctantly come to the conclusion that in some cases, it is
necessary to silently drop spam rather than reject it. This is the
situation:
An email comes in for two recipients in one SMTP trasaction (ie,
a MAIL, two RCPTs and then DATA).
One recipient's rules say to accept. The other recipient's says to reject.
You can't reject post-DATA because then it looks like both recipients
received the mail.
You can accept and create a failure message for one recipient, but then
you risk generating backscatter.
You can tempfail all but the first RCPT to force the message to be
split up into individual messages per recipient, allowing you to accept
or reject individually. But this will delay mail and possibly cause it
not to be delivered if there are many recipients and the sending relay
is impatient.
So I reluctantly conclude that in all but the smallest of installations,
dropping the mail for the recipient whose rules say to do so is the
best thing to do.
There have been SMTP extensions proposed to combat this. I recall an
extension that had you issue RCPTs until one of the RCPTs was
accepted, then DATA, then additional RCPTs with a "also send the
foregoing to this one" keyword so you could have per-recipient data
filtering, but of course spammers could not be obliged to use the
extension. :(
One possible way to deal with this situation (which would require some additional
complexity on the server and require good behavior on the senders) is:
Define two classes of recipients:
class A == all users who want everything
class B == all users who want "standard" filtering
At 'RCPT' phase of the SMTP transaction note if the first valid recipient is
class "A" or class "B", set a flag to remember it.
For each subsequent valid recipient see if their class is the same as the first
recipient. If not then return a "452 Too many recipients" reply code for that
one and all subsequent valid recipients.
Ideally the sender should then move on to the DATA phase, complete the
processing for the first batch of recipients, and then try again for the
remainder.
If all goes well, this should split up the different classes of recipients into
separate SMTP transactions allowing for appropriate processing with out loss.
Your classifications can be expanded upon to meet your site requirements but
the processing logic should be the same.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
