[milters] Archive

Lists Index Date Thread Search

Article: 1052
From: Emanuele (aka Skull)
Date: 2010-09-01 12:38:04 -0400
Subject: Re: milter-spamc 2.0 testing

On 9/1/10 5:35 PM, Anthony Howe wrote:

> Well I always do X- header tagging (unless disabled) so that would not
> be an issue or something new needed.
> 
>> "If the recipient (or one of the recipients) is whitelisted, run spamc
>> anyway but fallback to this other policy".
> 
> That's the point of +smtp-dsn-enable, though not sure what you mean by
> policy and how it might be different from what this option aims to do.

If I want to reject mail exceeding a given score, I can set "policy=reject".

If one of my user wants me not to reject his spam, I can set a
whitelisting for him:

milter-link-To:spamreceiver@domain.tld		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.

Also, with the "old whitelisting behavior", this causes multi-recipient
spam to pass through my filters if the whitelisted user is between them...


Let's say we change the whitelisting behavior so that, if the recipient
(or one of the recipients in case of multi-recipient) is whitelisted,
milter-spamc *still checks* the mail through spamassassin, but treats it
like it would do if "policy=none".

This means:

- single-recipient spam gets X-spam header, and the user can use them if
he wants to

- multi-recipient spam with one or more recipients whitelisted are
treated with "policy=none": X-spam header is added allowing for later
filtering/foldering; non-whitelisted users will still receive the spam
(like they do now with the old behavior) but will be able to filter it out

- mail with no whitelisted recipient will still be rejected if they
exceed score



> There will always be this problem, but its a sacrifice for telling legit
> senders that something went wrong.
> 
> But bouncing back is the only way to inform a legit sender of failures.
> While anti-virus bounces are a bane, anti-spam bounces are more grey.

I tend to disagree.
When the sender is a botnet and/or the sender is forged, there is no
difference.

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).

If you're not able to reject it, deliver it to the recipient. Maybe in a
spam folder, but deliver it.

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...

This, at least, my SMTP philosophy ;-)
-- 
Paranoia is a disease unto itself. And may I add: the person standing
next to you may not be who they appear to be, so take precaution.
-----------------------------------------------------------------------------
http://bofhskull.wordpress.com/

Lists Index Date Thread Search