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> '[email protected]' => ['[email protected]']
EJ> };
EJ> Cheers
EJ> Jan
EJ> ----- Original Message -----
EJ> | From: "Dominic Raferd" <[email protected]>
EJ> | To: [email protected]
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 <[email protected]> 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)
|>> # '[email protected]' => [{'[email protected]' => 10.0}],
|>> # '[email protected]' => [{'.ebay.com' => -3.0}],
|>> # '[email protected]' => [{'[email protected]' => -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,
|>> '[email protected]' => [{'[email protected]' => 1}],
|>> });
|>> @banned_files_lovers_maps = ({ # a by-recipient hash lookup table,
|>> '[email protected]' => [{'[email protected]' => 1}],
|>> });
|>> @bad_header_lovers_maps = ({ # a by-recipient hash lookup table,
|>> '[email protected]' => [{'[email protected]' => 1}],
|>> });
|>> or using the bypass_*checks_maps variables:
|>> @bypass_virus_checks_maps = ({
|>> '[email protected]' => [{'[email protected]' => 1}],
|>> });
|>> @bypass_banned_checks_maps = ({
|>> '[email protected]' => [{'[email protected]' => 1}],
|>> });
|>> @bypass_header_checks_maps = ({
|>> '[email protected]' => [{'[email protected]' => 1}],
|>> });
|>> and the result in both variants is that **all** emails sent to
[email protected]
|>> get whitelisted (not only the ones coming from [email protected]).
|>> 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)
