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