Whitelisting specific sender addresses for specific recipient addresses

[Gregory Sloop]

Jan - 
I have a client that needed the essential features you were looking for.
Essentially, allowing through banned attachments based on a sender+recipient pair.

I'm sure it's possible to extend Amavis to do that - but it really looked as though it was a "feature" that was not looked upon with favor. So, even if I wrote it, it wouldn't get integrated into the code, and would need maintenance as Amavis changed etc - and that would be entirely on my shoulders.

My approach was to handle it all externally. I have amavis configured to; for all banned files, send a report to a mailbox.
I then pull those report messages from the mailbox and process them.
I pull the details from the report [sender, recipient, sender IP etc]
I then do a lookup in a simple text file and start matching.


As I'm sure you're aware, sender addresses are trivially spoofed - and many readers of this list are probably having siezures right this second, at the thought of someone using them as criteria for allowing banned files through. :)

And they're right - it's not a fool-poof method. But it works for my client well enough.
And we don't *have* to only rely on the sender address, it's a pairing of sender+recipient.
And I can also trust the sender domain or IP address. [Which isn't trivially forged.]

[I can also control the types of attachments allowed - so really, it's a match of source-ip/domain + sender + recipient + attachment-type.]

I setup the script to run every few minutes and the system releases any quarantined messages to the original recipients. [So, there's some delay - in our case, a few minutes between runs. But it's pretty minimal.]

All the other messages stay in quarantine, and are purged via cron once they're 30+d old. That way if something isn't auto-released but we still need, we can manually do so.

We've been running this for years now, and by and large we're pretty happy. I *think* we've had a case or two recently, where one of those senders was infected with some malware/virus and it sent attachments that were forwarded through to an end user via this system - so it does have its risk. But, IMO, it's far better than the alternatives - No attachments at all, manual release of everything OR allow all attachments all the time. [I'm not the guy who manages the mail system day-to-day - so I should probably verify that it actually happened, rather than saying it did - but in any case it is a possible outcome. In our case, other layers caught those attachments and prevented any harm.]

-Greg


EJ> Hi Dominic,

EJ> thank you for your quick reply.

EJ> I've tried your proposal using the
EJ> $per_recip_whitelist_sender_lookup_tables
EJ> but unfortunately it only seems to affect the spam checking. The virus/banned/header
EJ> checks were still active after setting this variable.

EJ> I've tried using the following configuration:

EJ> $per_recip_whitelist_sender_lookup_tables = {
EJ>   'user1 at example.com'  => ['news at foobar.com']
EJ> };

EJ> Cheers
EJ> Jan

EJ> ----- Original Message -----
EJ> | From: "Dominic Raferd" <dominic at timedicer.co.uk>
EJ> | To: amavis-users at amavis.org
EJ> | Sent: Tuesday, January 8, 2019 9:47:59 AM
EJ> | Subject: Re: Whitelisting specific sender addresses for specific recipient addresses

EJ> | On Tue, 8 Jan 2019 at 08:37, Engels, Jan <jan.engels at desy.de> wrote:

|>> Hi everyone,

|>> I'm currently trying to setup amavisd-new for whitelisting emails **from** a
|>> specific sender address **to** a specific recipient address (under CentOS 7).
|>> By whitelist I mean no virus/banned/header checks and no spam tagging. The
|>> whitelisting should however only apply for specific senders on a per-recipient
|>> basis.

|>> Using the @score_sender_maps I can easily assign custom spam scores on a
|>> per-recipient basis, as shown in the default amavisd.conf:

|>>     @score_sender_maps = ({ # a by-recipient hash lookup table,
|>>                             # results from all matching recipient tables are summed

|>>     ## per-recipient personal tables  (NOTE: positive: black, negative: white)
|>>     # 'user1 at example.com'  => [{'bla-mobile.press at example.com' => 10.0}],
|>>     # 'user3 at example.com'  => [{'.ebay.com'                 => -3.0}],
|>>     # 'user4 at example.com'  => [{'cleargreen at cleargreen.com' => -7.0,
|>>     #                           '.cleargreen.com'           => -5.0}],
|>>     #...
|>>     });

|>> The problem is that using the *_lovers_maps variables does not work using the
|>> same syntax, i.e. I've tried for example:

|>>     @virus_lovers_maps = ({ # a by-recipient hash lookup table,
|>>       'user1 at example.com'  => [{'news at foobar.com' => 1}],
|>>     });

|>>     @banned_files_lovers_maps = ({ # a by-recipient hash lookup table,
|>>       'user1 at example.com'  => [{'news at foobar.com' => 1}],
|>>     });

|>>     @bad_header_lovers_maps = ({ # a by-recipient hash lookup table,
|>>       'user1 at example.com'  => [{'news at foobar.com' => 1}],
|>>     });

|>> or using the bypass_*checks_maps variables:

|>>     @bypass_virus_checks_maps = ({
|>>       'user1 at example.com'  => [{'news at foobar.com' => 1}],
|>>     });

|>>     @bypass_banned_checks_maps = ({
|>>       'user1 at example.com'  => [{'news at foobar.com' => 1}],
|>>     });

|>>     @bypass_header_checks_maps = ({
|>>       'user1 at example.com'  => [{'news at foobar.com' => 1}],
|>>     });

|>> and the result in both variants is that **all** emails sent to user1 at example.com
|>> get whitelisted (not only the ones coming from news at foobar.com).

|>> Is there some way to get the same behaviour using the *_lovers_maps or bypass_*
|>> variables as with the @score_sender_maps variable (i.e on a per-recipient
|>> basis)?

|>> Any help would be greatly appreciated.
EJ> | 
EJ> | I think you want: $per_recip_whitelist_sender_lookup_tables (although
EJ> | it is marked as deprecated)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.amavis.org/pipermail/amavis-users/attachments/20190108/14351692/attachment.html>