SOLUTION for white-listing senders for banned files.

[Gregory Sloop]

Subject: SOLUTION for white-listing senders for banned files.

So, I've created some perl code to handle white-listing senders in relation to banned files [attachments]. [It's a little more capable than this - but that's a good start for a summary.]

I've seen the request to white-list banned files based on a sender email address. And I've seen it posted quite a number of times too. And I've really needed it for an installation for a client of mine.

There's some ability, native to Amavis, to whitelist an IP, from what I understand, but no ability to white-list a sender's email address in Amavis itself.

And yes, I do understand that sender addresses can be forged, and often are - and that this makes this type of white-list less secure.
However, it's probably pretty rare that someone would forge both the proper sender and proper recipient pair and send a "baddie" file for a user on my system. [Not to mention that I also provided a method that will prevent some types of files even if there's sender+recipient match.]

That said, reading between the lines, it looks like the devs for Amavis have made an explicit choice *NOT* to put in _sender_ white-listing. And I can see the point, even though I disagree with the decision. [IMO, it's a debatable decision.]

Yet with Amavis, having made such a decision, implementing a work-around is difficult. I don't want to code a patch to Amavis itself that has to be maintained as Amavis changes. Plus, working out how best to integrate it into the Amavis code-base would be hard too. So, a patch was out, IMO.

There are *some* work-arounds for white-listing stuff, but they aren't really pair-wise white-lists. Essentially they allow any white-listed sender to send to ANY white-listed recipient. Thus, if sender A is white-listed and recipients W, X, Y and Z are also white-listed, then A can send to any of W,X,Y or Z.

In our implemented case, A is paired with, say, Z. B is paired with W. Thus, sender A can't send to W - they can only send to Z. And B can't send to Z and get white-listed either. This is a more strict system - which also negates some of the risk of white-listing a _sender_ alone which can easily be spoofed.

Also, the work-arounds built into Amavis won't work for Postifx proxies [pre-accept] setups like ours at all. [At least they (the work-arounds) won't if you want to also use Amavis to do spam identification also reject high spam-scored mail before the mail server accepts it. i.e. Reject high spam-score mail at the MTA with a 5XX code, instead of quarantining it, or bouncing it.]

---
Then it struck me. Amavis can send a quarantine report for banned files and it has all the data I'd like to use for a white-list anyway.

So, I decided to write a perl program to:
1) Open up an IMAP mailbox to read/process a list of waiting quarantine-report messages - generated by Amavis when a banned file is quarantined.
2) Regex the pertinent stuff from the report for each quarantine report
3) Grab some white-list data from a CSV file and then make decisions about what messages to white-list

If the message matches the criteria for the sender+recipient pair, we also check that the file type isn't listed as impermissible. [It's part of the CSV input/configuration file - unique for each sender-recipient pair.] If all those criteria are met then we use amavisd-release to release the file to the user.

And we allow matches other than just the "return path" lines. [This is the "sender"]
We also allow for FQDN [or partial FQDN matches] as well as IP address matching for the first-upstream MTA or the "Received" trace.

---
This approach has benefits as further Amavis development occurs.
Changes in Amavis that modify the report shouldn't be much of a problem, as long as the same basic data points are still available on the report. We'd have to modify the regexes that grab this data from the report - but that's pretty easy.

Thus I think this tool could live quite long-term - even without any tacit support from Amavis development. Plus there's no need for Amavis to give any "approval" to this approach, if they believe it's foolhardy. It's simply a stand-alone modular tool that works independently of Amavis.

---
Now, here's the catch. I created this for a client. I've got a fair amount of time and testing invested into it and I'm not going to be able to recoup all that dev cost from the client.

I appears as though there's some interest here for this feature, given the history of requests for such a feature.

So, I'd like to offer the code for a modest cost. [Say $300 USD]
Once we reach, say 10 paid installs, from people buying this feature, I'll GPL license the source.

I'm also glad to offer a full-satisfaction guarantee. [Subject to some details, but in short - if you don't like it, I'll gladly refund your money.]

I'm no star programmer, so any perl guru's will probably snigger at my code. But, it's well documented and my real-world production version works well so far. [It's been in use at a working site for several months without any problems.]

Paying me a little is far less expensive than coding this feature yourself - unless you work incredibly cheaply and are a way better programmer than I am. [The latter is perhaps likely, but probably not both! :) ]

So, I guess I'm asking - is anyone interested?
I know I'm asking for some money for it, when Amavis itself is free - and I understand the disparity.
But I do need to eat too, and I decided to do this project even though I wasn't sure I'd be able to bill a client for all of it.
[To be clear, I'm probably not going to starve, but I'm not raking in big bucks from my clients either. :) ]

And, as noted, I'm glad to GPL the code once I've had enough people buy a copy of it to make up the difference - and that's a win for the community too, IMO.

So, is anyone interested in it? If so, please email me directly - not the list. We can discuss.

TIA!
-Greg

TAGS: white-list, white list, whitelisting, white-listing, sender, senders, sender-recipient, release, quarantine.

[Gregory Sloop]

>> There's some ability, native to Amavis, to whitelist an IP, from what I understand, but no ability to white-list a sender's email address in Amavis itself.

DE> Doesn't the Amavis wblist MySQL table or the
DE> @whitelist_sender_maps directive provide that very functionality that you say is missing?

While I'm no master Amavis user, the documentation [and my testing] show that @whitelist_sender_maps only applies to spam and NOT banned files. Since we want to allow some banned files through - for example, zip files from certain senders to certain recipients - this was the only way we found to accomplish it.

[From the Amavis docs, Here: http://www.ijs.si/software/amavisd/amavisd-new-docs.html#checks
"It should be emphasized that whitelisting (and blacklisting) only affects spam checks. It has no influence on other checks such as virus, banned or header checks. Infected mail from whitelisted sender would still be blocked if our policy is to block viruses." ]

So, while I'm more than glad to be shown a way this can be accomplished otherwise, and it's certainly possible I've missed something, I don't believe there's any way to do sender whitelisting for banned files, while also running as a proxy setup. [Important in our case, where we want to 5XX spam mails with scores higher than Y.]

Finally, I'll note that we don't completely pass anything from a white-listed sender. We can allow .zip files, while not allowing .exe's, for example. This is an important feature for us, and would not be possible, even if @whitelist_sender_maps worked the way you think. [Which they don't, so the discussion is mostly moot anyway.]