Dianne Skoll wrote:
On Fri, 27 Apr 2018 14:39:43 -0500 (CDT)
David B Funk <dbf...@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
