
<html><head><title>SOLUTION for white-listing senders for banned files.</title>

<META http-equiv=Content-Type content="text/html; charset=iso-8859-15">

</head>

<body>

<span style=" font-family:'Courier New'; font-size: 9pt;">Subject: SOLUTION for white-listing senders for banned files.<br>

<br>

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.]<br>

<br>

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.<br>

<br>

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.<br>

<br>

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.<br>

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.]<br>

<br>

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.]<br>

<br>

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.<br>

<br>

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.<br>

<br>

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.<br>

<br>

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.]<br>

<br>

---<br>

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.<br>

<br>

So, I decided to write a perl program to:<br>

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.<br>

2) Regex the pertinent stuff from the report for each quarantine report<br>

3) Grab some white-list data from a CSV file and then make decisions about what messages to white-list<br>

<br>

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.<br>

<br>

And we allow matches other than just the "return path" lines. [This is the "sender"]<br>

We also allow for FQDN [or partial FQDN matches] as well as IP address matching for the first-upstream MTA or the "Received" trace.<br>

<br>

---<br>

This approach has benefits as further Amavis development occurs.<br>

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.<br>

<br>

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.<br>

<br>

---<br>

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.<br>

<br>

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

<br>

So, I'd like to offer the code for a modest cost. [Say $300 USD] <br>

Once we reach, say 10 paid installs, from people buying this feature, I'll GPL license the source.<br>

<br>

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.]<br>

<br>

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.]<br>

<br>

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! :) ]<br>

<br>

So, I guess I'm asking - is anyone interested? <br>

I know I'm asking for some money for it, when Amavis itself is free - and I understand the disparity. <br>

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. <br>

[To be clear, I'm probably not going to starve, but I'm not raking in big bucks from my clients either. :) ]<br>

<br>

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.<br>

<br>

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

<br>

TIA!<br>

-Greg<br>

<br>

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

</span><a style=" font-family:'arial';" href="mailto:gregs@sloop.net"></a></body></html>