Per-Recipient filtering (was: Re: [Mimedefang] filter question)

[John Rudd]

On Sep 8, 2005, at 11:33 AM, <Matthew.van.Eerde at hbinc.com> wrote:

> David Koski wrote:
>> I'm looking for a filter to allow an opt-out per user using any type
>> of filtering (Or more in the case, I would prefer to allow the user
>> to opt-out of using SpamAssassin but not Clamav (But an example that
>> just allows the user to opt-out of any filter would be fine, gets me
>> started in the right direction)).  I have a couple of system users
>> that I know we don't want to do any sort of Spam filtering on.
>
> Meh.  There are certain deep and fundamental problems with this 
> eminently natural feature request.
>
> That is to say, you have to accept the RCPT commands BEFORE you get to 
> see the email message.  And once you've seen the message, you have to 
> accept it or reject it for ALL accepted recipients unilaterally.  
> That's just how SMTP works.


So, this used to come up on the MailScanner list every so often (how do 
I make sure each message has exactly 1 recipient? so I can do per-user 
preferences).  There is a way to do it with MS, but the problem is: MS 
is run AFTER sendmail drops the message into a queue (MS runs with 2 
sendmail instances; the daemon drops messages into 
/var/spool/mqueue.in, MS munges them and then drops them into 
/var/spool/mqueue, where a second sendmail running only as a queue 
processor, picks them up), whereas MimeDefang is not.  So, I don't know 
if this technique would work for MimeDefang.

I'm presenting it not for the end user, but for those who might want to 
experiment with it and see how it does or does not translate into 
MimeDefang.

Here's the FAQ entry from MailScanner:

http://www.sng.ecs.soton.ac.uk/mailscanner/serve/cache/169.html

What it does, is cause sendmail to split messages into multiple copies, 
one to each recipient.  But I don't know if this is done in a way that 
is compatible with milters.  I mean, one possibility is that sendmail 
invokes filter_relay, filter_sender, and filter_recipient on the 
original message, reads the body, and then splits the message and 
invokes the remaining filter commands on the individual messages.

I think that would be ideal.  But, it may be that sendmail invokes the 
splitting process too late for that (after all miltering has finished). 
  Or it may be that I am completely oblivious to how the miltering 
process works, and it's just not possible to do what I just described.  
So then you'd be in exactly the same situation you're in now.  (and, I 
don't see how it could invoke the splitting process any earlier than 
that)

If someone does look into this, please post results to the list.  I may 
or may not end up getting a chance to tinker with this in the future, 
but it almost certainly wont be any time soon.

(also note: we do not use this technique on our mailscanner systems, so 
I can't even help on that level)


> But what I do is...
>
> I reject (action_bounce) all viral email.  Users don't have a choice 
> to opt-out of virus protection.
>
> I tag all spam (add a header, tweak the subject.)  Users are stuck 
> with spam... I don't action_bounce it.  But they can set up custom 
> spam handling preferences on their Inbox.
>
> Users who don't get much spam just have it go into their Inbox, 
> reducing the consequences of false positives.


What we do now, since we use MailScanner, is replace viruses and bad 
attachments with warnings, and tag spam.  What I do at home, after 
moving from MailScanner to MimeDefang, is reject viruses and bad 
attachments during SMTP, reject spam with a score over 40, reject spam 
if $names matches "IN_BLACKLIST" and not "IN_WHITELIST", or otherwise 
tag spam.

(why "over 40"?  because at one point I started using the AWL as a 
blacklist/whitelist, running a script on my spam folder that submits 
each message to the AWL for "blacklist"ing, so if the message score is 
extremely high, then they were probably one of those senders)

In the near future, at work, we're moving anti-virus and bad attachment 
checks to MimeDefang, for rejecting during SMTP (but only if the relay 
is from outside our LAN; if it's from inside our LAN it's most 
definitely from our CommuniGate Pro cluster, so it's an outbound 
message ... and that would cause issues if we rejected it ... so we're 
going to replace them instead of reject them ... the programmatic 
nature of mimedefang-filter lets me do that).

It's still up in the air what we're going to do in the longer term.  
Though, I'm more and more disillusioned by the vendors we originally 
selected for evaluation (after our RFI process), and I'm re-considering 
Roaring Penguin now that I have used MimeDefang.