You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Dianne Skoll <df...@roaringpenguin.com> on 2018/04/27 18:22:50 UTC
Dropping mail
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. :(
Regards,
Dianne.
Re: Dropping mail
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On April 29, 2018 11:11:18 PM EDT, Linda Walsh <sa...@tlinx.org> wrote:
> Except users who have their own rules are not likely
>doing it in the context of the initial choice of whether or
>not to accept the email onto the server.
They do in our system.
> I.e. it "should" never be the case that user-defined
>filters are run in the MTA's initial receive context as the MTA
>just received (or is in process of receiving) an email coming
>in on a privileged port (like port 25) which would imply a
>privileged context (most likely root).
No; see the milter API and library.
> Delays are not the same as dropped email.
I have seen sending MTAs give up after an absurdly small number of retries.
Regards,
Dianne.
Re: Dropping mail
Posted by Linda Walsh <sa...@tlinx.org>.
Dianne Skoll wrote:
> On Fri, 27 Apr 2018 14:39:43 -0500 (CDT)
> David B Funk <db...@engineering.uiowa.edu> wrote:
>
> [snip]
>
>> Define two classes of recipients:
>> class A == all users who want everything
>> class B == all users who want "standard" filtering
>
> This works if you have a limited number of classes, but in some cases
> users can make their own rules and settings so the number of classes
> can be the same as the number of RCPTs.
---
Except users who have their own rules are not likely
doing it in the context of the initial choice of whether or
not to accept the email onto the server. I.e. they'll run some
anti-spam filter in their "account" context as a normal user.
The users who want "standard filtering", may have it
done such that the email is never accepted onto their
email server.
I.e. it "should" never be the case that user-defined
filters are run in the MTA's initial receive context as the MTA
just received (or is in process of receiving) an email coming
in on a privileged port (like port 25) which would imply a
privileged context (most likely root).
>
> Even in the two-class case, there's still a delay for the subsequent
> class(es).
---
Delays are not the same as dropped email. People use
grey-listing which often causes some delay, but in this case,
I've seen examples of people who's mail-provider was
inspecting+filtering emails for spam+malware also have
problems in delivery time (60-90 minutes after the fact).
So it is already the case that mail-providers who do
filtering on the mail-server are sometimes slow to pass
on the email to their users, depending on their volume).
linda
Re: Dropping mail
Posted by Pedro David Marco <pe...@yahoo.com>.
>> Define two classes of recipients:
>> class A == all users who want everything
>> class B == all users who want "standard" filtering
Be aware of Class A users... once they click on where they should not, then as if by magic it was your fault and the s--t hits the fun... (of course when the fun point towards you)
---------PedroD
Re: Dropping mail
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Fri, 27 Apr 2018 15:18:28 -0500 (CDT)
David B Funk <db...@engineering.uiowa.edu> wrote:
> If you have that many different classes of recipients, just set the
> number of allowed recipients/transaction to one and be done with it.
That will cause mail failures. It's not *supposed* to, but I know
from experience it will. Some MTAs limit the number of retries to a
ridiculously low number like 10 or 20 and then give up.
Regards,
Dianne.
Re: Dropping mail
Posted by David B Funk <db...@engineering.uiowa.edu>.
On Fri, 27 Apr 2018, Dianne Skoll wrote:
> On Fri, 27 Apr 2018 14:39:43 -0500 (CDT)
> David B Funk <db...@engineering.uiowa.edu> wrote:
>
> [snip]
>
>> Define two classes of recipients:
>> class A == all users who want everything
>> class B == all users who want "standard" filtering
>
> This works if you have a limited number of classes, but in some cases
> users can make their own rules and settings so the number of classes
> can be the same as the number of RCPTs.
>
> Even in the two-class case, there's still a delay for the subsequent
> class(es).
If you have that many different classes of recipients, just set the number of
allowed recipients/transaction to one and be done with it.
The delay is entirely up to the sending side, they could immediately retry the
subsequent recipients.
I was just trying to suggest a solution to your conundrum that didn't require
you to drop messages. I didn't say it was optimal, just avoiding the loss of
messages.
--
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{
Re: Dropping mail
Posted by Dianne Skoll <df...@roaringpenguin.com>.
On Fri, 27 Apr 2018 14:39:43 -0500 (CDT)
David B Funk <db...@engineering.uiowa.edu> wrote:
[snip]
> Define two classes of recipients:
> class A == all users who want everything
> class B == all users who want "standard" filtering
This works if you have a limited number of classes, but in some cases
users can make their own rules and settings so the number of classes
can be the same as the number of RCPTs.
Even in the two-class case, there's still a delay for the subsequent
class(es).
Regards,
Dianne.
Re: Dropping mail
Posted by David B Funk <db...@engineering.uiowa.edu>.
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{