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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.amavis.org/pipermail/amavis-users/attachments/20150911/7653c29c/attachment.html>