Topic: Allowing attachments per whitelist?

[Brenno]

Has anyone come across anything that would enable me to allow certain file types as attachments only from whitelisted senders?  My specific problem is that Corporate is forcing us to allow .zip attachments for some of their reporting requirements (and I cannot change this) but we are in the meantime getting flooded with Spam and Phishing emails with .zip attachments and it's putting our network at significant risk.

Ideally, I'd like to be able to allow .zip attachments only for selected domains - perhaps the ones already "trusted" in my whitelist - or via a separate list that I could maintain.  Perhaps allowing by IP would be even better since that would potentially be more spoof-proof.

I've done some searches here in the forums but haven't been able to find anything at this point.

[janet]

Brenno

You could enable the greylisting plugin.
This will over time give you a set of trusted users, with whitelists etc, so you should then be able to automatically exclude spam & virus senders.
Greylisting is quite effective as long as your users can tolerate the way it works. Many of them will not even be aware of delays in email delivery.

Search here on greylisting, I think there is something in  the Forum, FAQ or Howtos

[Brenno]

Hi Janet,

I'll have to look more into the greylisting option to see how that might work.  For now, due to the surge in .zip attachments coming through this morning, I've temporarily re-enabled blocking those files.

I also had to add a new default signature to the mailpatterns DB, UEsDBBQDA, since that was getting through even though I'd enabled blocking Zip1 and Zip2 attachments (their signatures are slightly different).  Curiously, Google returned no hits on "UEsDBBQDA" (other than used BBQs, LOL) so I'm not sure if this is something new or not.  I'm going to monitor the logs and see how many hits I get on those rejections for now.

[janet]

Brenno

I also had to add a new default signature to the mailpatterns DB, UEsDBBQDA,

Please create a bug report to add that signature to the default mailpatterns database so that your experience can benefit others, thanks.

Did you test that signature thoroughly as per instructions in the appropriate Howto ?

[Brenno]

I followed the instructions in the appropriate howto but didn't do any testing on it before enabling.  According to the logs, there have only been 4 message blocked due to the new signature in the last 9 hours or so (obviously a few came in before the block, too).  All of them are pretty obviously valid rejections, but given the low number of them, the rule might not be of significant value at this point; I only added it after noticing that two or three messages had come to me (admin mailbox) with .zip attachments despite me enabling the block on types 1 and 2.

I looked into the greylisting option and I'm not sure that it's going to be feasible for us; my instinct tells me we'd encounter way too many false positives using this approach.

[janet]

Brenno

I looked into the greylisting option and I'm not sure that it's going to be feasible for us; my instinct tells me we'd encounter way too many false positives using this approach.

The system is supposed to have false positives, these messages then get delayed & sending servers retry (unknown to the end recipient). On subsequent redelivery attempts the mail gets delivered & the sender is added to the whitelist automatically.
You can manually create extensive whitelists of all known senders so that mail gets delivered immediately without being delayed by greylisting.
You will be stunned at the virtually zero spam & virus messages coming through (actually not coming through).
Over a short period of time after implementation, you would have most popular senders whitelisted, so there would be no further delays for those senders.
Spammers etc usually use servers that will not retry sending, so their original messages do not get delivered as the greylisting rejects them, which typically also include virus laden messages.

See http://wiki.contribs.org/Greylisting

The main downside of greylisting, is that local recipients (users) often expect to immediately or instantly receive email messages within a minute after they are sent, but when new senders (who are not yet in whitelists) send an email message, there can be a few hours or even a day or two delay (depending on external sending mail servers).
So users have to tolerate a (usually unknown in most cases) delay the first time they receive a message from a sender, otherwise that sender can be immediately added to a whitelist to have instant delivery (eg for urgent situations).
For regular senders there is no delay.

As I said, uses need to tolerate the way greylisting works, & accept that trade off as a means of protecting themselves & the network against viruses & spam etc.
Greylisting does work very effectively.

[mmccarn]

Could you do what you want by finding a spamassassin rule to score all emails with 'zip' attachments high enough to be blocked, then whitelist the domains that must be allowed?