Whitelist and disarming

[Laszlo Nagy]

>> I would handle it slightly different :
>>
>> create /etc/MailScanner/rules/disarm.rules :
>>
>> From:   *@some_domain.com       yes
>> FromOrTo:       default         disarm
>>
>> replace "disarm" in /etc/MailScanner/MailScanner.conf with
>> "%rules-dir%/disarm.rules" where "disarm" is set (e.g. Allow IFrame Tags,
>> Allow Form Tags ....)
>>
>> restart MailScanner
>>
>> So mails is getting scanned and Spam and Virii will be detected but header
>> and body will not get disarmed.
>>
>>     
Thank you, I dit it. I hope it will work.
> A couple of notes:
> - Lets be clear about why adding the stansa to spam.whitelist.rules
> didn't work... It is only concerned with spam handling, not any other
> (dangerous content) scanning at all... Hence the need for something
> like what Ralph suggests.
>   
I see. Thanks. :-)
> - Use the sending servers IP address instead of a domain glob
> pattern... Relying on something that easily forgeable (iow spoofable)
> is not good. You should be able to find out which IPs are used and use
> that for your whitelist.
>   
I'm affraid that this company uses a widely used ISP to send out emails. 
I guess I have to use the From: header. Or maybe both: From + sender ip, 
but I'm not sure how to do that.
> - It isn't the brightest idea possible to build an automated system
> like that, depending/relying on something that is inherently not that
> reliable...;-). Although all messages are guaranteed to be handled,
> either by a delivery or a rejection (leading to some type of
> bounce/NDN/DSN/whatever), you have no guarantees about _when_ it will
> happen. 
Yes, I know. But these companies have their own systems. They send out 
automatic emails, and we cannot ask them to send data feeds on FTP or 
anything else. They insist on sending XLS and CSV files in emails. (Even 
worse, some of them are sending PDF and word doc files...)

> "Within the next few days" might not be good enough;-). 
But much better than never. In most cases, these emails actually arrive 
within one minute, so in 99% of the cases, it works.
> If it
> is something like index pricing information (MSCI has been known to
> use this), it is a really _bad_ idea, since the info is likely not
> that ... valid... after a few days delay. "Ok", you might be thinking,
> "We'll solve it by setting 'High Priority', so it is guaranteed to go
> through fast..." -> Nope. Only thing that does is to make it fail/give
> up faster (and decorate your mail with a ghastly exclamation mark, or
> similar). So that would only aggravate any problem, not solve it.
> We've had this type of setup and are moving away from it as fast as
> possible... To more sane things like FTP or, even better, SFTP.
>   
Yes, that would be fabolous. But we cannot do that.

Thank you for the detailed explanation. It was a big help!

   Laszlo