Rulesets with multiple recipients

Steve Freegard steve.freegard at fsl.com
Thu Nov 26 11:01:11 GMT 2009


David Jacobson wrote:
> Hi List / Julian,
> 
> I understand that this has been discussed a few times, however would 
> like to raise this topic again.
> 
> Scenario:
> 
> We offer a service to certain users only for some domains where we 
> forward a copy of their mail to a seperate server and deliver (kinda 
> like an insurance policy) - incase they have trouble with their server 
> and need to access a mail urgently and/or respond.
> 
> This works fine - unless the mail has multiple recipients in the same 
> domain.
> 
> Example : user1 at company.com sends to user1 at company2.com and 
> user2 at company2.com MailScanner will parse the non spam action rules and 
> see that the action for user1 at company2.com is to forward to another 
> server and deliver, then it will do that and skip the rest of the 
> forwards and deliver mail normally.  This is a problem, as all users in 
> the RCPT TO should be forwarded & delivered.
> 
> I understand this is not a MailScanner issue as MailScanner does not 
> split the mail and can only really do one action with the message 
> (understandable).
> 
> I also understand I can change the default behaviour from first match to 
> use default ruleset with "Use Default Rules With Multiple Recipients = 
> yes" however since we only do this for certain users and only for 
> certain domains that change will not help.
> 
> So I assume the fix people will suggest is to actually split the mail so 
> MailScanner can do the right thing per message.  I have done this with 
> Exim and it works fine in terms of splitting the mail and then doing the 
> correct rules per mail.
> 
> My major concern with this is as follows:
> 
> 1) Increasing the load on the server, 1 message to 10 recipients is now 
> 10 seperate messages
> 2) Bandwidth increase to customer
> 3) MailWatch logs seperate messages to maillog
> 
> Point 3 is my biggest problem - we don't want to have 10 of the same 
> messages logged in maillog - this will increase our DB size (which is 
> already huge) and it will be "non efficient" to have multiple of the 
> same messages in the DB for us to search and release etc.
> 
> Additionally I could be wrong but I'm not even sure if splitting mail 
> like this is RFC compliant.
> 
> OK, so now that my rant is over about the issues we have - is it at all 
> possible to change MailScanner in any way to parse through the ruleset 
> via a subroutine or something similar so it doesn't do first match and 
> works out it's to multiple recipients and somehow parses the ruleset 
> correctly?
> 
> Or perhaps any other way EXCEPT splitting the mail as I can see it 
> causing more problems than it's worth.
> 

Recipient splitting is advisable anywhere users are able to set-up their
own preferences as you have to consider that case of a multi-recipient
e-mail where one user has blacklisted the sender (this will cause the
mail to be blacklisted for all recipients).

The SpamAssassin cache reduces a lot of the overhead of recipient
splitting however there are a few disadvantages as you point out; IIRC
Exim and Postfix recipient splitting is also pretty ugly whereas
Sendmail definitely wins out in this regard (it generates multiple qf/df
files on message reception instead of requiring re-injection).

However - forgive me for saying - but the whole method of (mis)using
Non-Spam Actions for what you are attempting is a nasty hack which is
why it's causing you issues.

The most straightforward way to achieve what you are trying to do would
be to maintain a 'map' of the users/domains that have this 'feature'
enabled e.g.:

blah at blah.com ->  forward at blah.com
...

Then either in a MailScanner CustomFunction *or* in your MTA; build up a
Bcc: header based on the envelope recipients using the map.  If
MailScanner delivers the message (e.g. it's non-spam) then the 'copy'
mailbox automatically gets sent a copy via the Bcc: header.

IMO - that's a far less horrible way to achieve this without trying to
misuse the message actions.

Regards,
Steve.



More information about the MailScanner mailing list