From: Anthony Howe
Date: 2010-09-02 04:01:53 -0400
Subject: Re: milter-spamc 2.0 testing
On 01/09/2010 18:38, Emanuele (aka Skull) whispered from the shadows...:
> On 9/1/10 5:35 PM, Anthony Howe wrote:
> If one of my user wants me not to reject his spam, I can set a
> whitelisting for him:
> milter-link-To:firstname.lastname@example.org OK
> This way, he receives everything.
> But if I want to check his mail anyway and just add an X-spam header, I
> need (at the moment) to run spamc on the mail outside the milter, since
> the whitelisting rule above jumps over spamc completely.
Not correct. You used a milter-link-to: specific tag. milter-spamc would
never white list on this. You would need
That is the correct answer since the user wants all mail, so doing extra
filtering just to add X-Spam-* headers is pointless, particularly on
high volume systems. When a user wants to be white listed, open the
flood gates on them and don't waste any time with half measures. They'll
either accept it or get a clue-stick and ask for filtering.
With multiple milters, with the current B/W behaviour you can mix it up:
# This entry actually not required unless you have
# the To:user OK below for sendmail/postfix white listing.
Assuming milter-link comes before milter-spamc in call order in your
configuration, then milter-link is by-passed for this user, but not
> Also, with the "old whitelisting behavior", this causes multi-recipient
> spam to pass through my filters if the whitelisted user is between them...
There will always be issues with multiple-recipients containing a white
listed user. My goal with milter-spamc (hopefully for others after) is
to find some way to satisfy most postmasters preferred handling by
providing a new choice(s).
a) Current behaviour for BW handling, a single white listed user in a
multi-recipient message will white list all subsequent recipients that
follow after in the SMTP sequence. This is efficient, but "weak".
b) New proposed choice for BW handling in the case of content filters
like milter-spamc (and milter-link later) is to apply the filters and if
spam then remove the non-white recipients and send a DSN to the sender.
Given SMTP, the milter API, and RFC practices, this the correct
solution. Yet begs the question about backscatter. Keeping backscatter
to a minimum will always be an issue, but keeping your clients is
probably more important.
c) I finally see your other proposal for BW handling, which is to apply
the filters for the white listed users and those that followed and if
spam then simply add the X-Spam-* as would normally be done and deliver
the message to the users for MUA level filtering. This work for power
users, but risks annoying your non-technical users - they might tweak it
once in their MUA when you explain it and forget, later they upgrade
machine, and find they lost all their personal filters and wonder why
they are getting spam again.
Remember that one of the original design goals of milter-spamc and the
reason for other milters is to off-load the very very resource heavy
processes like SpamAssassin. milter-link came about, because I did not
want to invoke SpamAssassin via milter-spamc for what I saw as a clearly
reject-able class of test.
Finding balance between efficiency, policy, and inter-operability
standards is a never ending problem.
> If you're able to reject the mail, reject. This will inform the sender
> that things went wrong (the remote MTA, if any, will generate the DSN).
You still get backscatter if the remote MTA is an intermediate hop, not
> If you're not able to reject it, deliver it to the recipient. Maybe in a
> spam folder, but deliver it.
This is fine for a single user, but multi-recipient messages will cause
some annoyances. Some postmasters will opt to use a MTA that does
envelope splitting to solve this.
> If you accept it and generate a bounce, you have lost your chance to be
> sure you're dealing with the real sender.
> And if the mail was really spam (as your spamassassin thinks), you are
> almost surely going to deliver that bounce to the wrong address, since
> the amount of spam with a non-forged sender address, out there, is a
> tiny minority...
Here I disagree. I see huge number of randomly generated bogus senders
vs forged real senders. I would also put forward that spammers that
forge a sender are actually creating bogus accounts for use as a drop
box equally as much for disposable backscatter collection.
Forging a real user gets you noticed too quickly. Forging the sender as
the recipient (ie. send to self) is more common, since there is no place
for the backscatter to go. A randomly generated sender, may cause
double-bounces going no where.
There are clearly opposing views and without updated RFCs and
responsible admins reading those documents, there were always be issues.
The best I can do is find some measure of balance and offer choices.
Years ago, I tended to opt for efficient and standard conforming choices
and I still do, but now allow choices that diverge from that view.
Clearly smtp-dsn-enable can be refined given the argument you've made as
summarised by point c) above, yet a) and b) would still be offered.
Anthony C Howe Skype: SirWumpus SnertSoft
+33 6 11 89 73 78 Twitter: SirWumpus BarricadeMX & Milters
http://snert.com/ http://nanozen.info/ http://snertsoft.com/
Copyright 2009, 2012 by SnertSoft. All rights reserved.