[milters] Archive

Lists Index Date Thread Search

Article: 1055
From: Emanuele (aka Skull)
Date: 2010-09-02 05:58:31 -0400
Subject: Re: milter-spamc 2.0 testing

On 9/2/10 10:01 AM, 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:spamreceiver@domain.tld		OK
>>
>> This way, he receives everything.
> 
> Not correct. You used a milter-link-to: specific tag. milter-spamc would
> never white list on this. You would need

My fail.
I wrote "milter-link-To" but intended "milter-spamc-To".

Sorry.



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

Some simply want to receive everything and get all spam foldered.


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

And I really appreciate that, trust me :-)


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

Yes, this could happen.
But the same foldering could also happen at local-delivery time
(sieve/procmail/whatever), so it's done "on my side"...


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

Yes, agreed. That's why I run both here.


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

The forged sender is going to receive it, yes.
But it's not being caused by *my* systems: now it's up to the
intermediate MTA -probably an MSA through which the spam was injected-
staff fix the issue (compromised account and no egress filters?) that
caused their system to relay spam.


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

Not manageable from the recipient side, though.

With multi-recipient mails you need to accept the first RCPT and 45x the
rest.
The sender puts the mail back in queue with all the recipients except
the delivered one in order to retry later.

If the mail has several RCPTs and a queue-reflush time of 5 minutes, the
last recipients is going to receive the mail after hours...

A thing that came to my mind in my worst nightmares is:
let the system reject with 45x all the recipients that differ from the
first one in their "whitelisting status".

Say we have two users in our system that are whitelisted:

To:User1@domain		OK
To:User2@domain		OK


A multi-RCPT mail reaches our system, trying to deliver a message to
User4, User5, User1, User2 and User3  specifying them in this specific
order.

We behave this ay:

[...]
RCPT TO: User4@domain
250 Ok
RCPT TO: User5@domain
250 Ok
RCPT TO: User1@domain
450 Mail for this user cannot be delivered in this session. Please
resend separately
RCPT TO: User2@domain
450 Mail for this user cannot be delivered in this session. Please
resend separately
RCPT TO: User3@domain
250 Ok
DATA
[..]


The sending system will queue the mail for User1 and User2 ad send it in
a separate 2-recipients session.
This time all the RCPTs have the same "whitelisting status", and will be
delivered in a single session.


This could be another way to manage the issue, but it's much more
tricky, expecially if one runs several filters/milters having different
access files.




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

Several spamware out there picks up (or at least used to, for a long
time) the sender address from the same list it takes the recipient from.
This allows the spammer to defeat mechanisms like sender verifications,
that would have rejected the email if the sender was randomly generated.


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

IMHO a very very tiny fraction.
Usually, I expect (and observe) this behaviour from "manual" spammers
abusing freemailers.

Annoying, but very low in number.

Al least in my experience...

:-)

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