whitelist

[Gregory Sloop]

Yeah, I know the warnings about using it as pre-accept...
I have an OMD/Naemon monitor watching it, so I'll know ASAP if it does fail though - so I'm reasonably OK with that. [And it hasn't ever failed in the multiple years I've had it set that way - though it's a pretty small site - perhaps 150-200 users.]

Essentially the reasons for pre-accept are:

1) Lower volume of mail to handle, if we drop spam/viruses etc, all before they're actually accepted by the MTA.

2) While I love SA, I do really like the option to simply bounce [not accept] high SA scored mail. The only way to do that is pre-accept. Not accepting it at all simply means that my users have less spam [even if it's marked as spam] to deal with in the mailbox. [That's a HUGE win for users - the difference last time I checked was massive. But that's been years ago - so it's possible the ratios are different now - but I don't really think so.]

3) Related to #2. 
I *HATE* quarantining things. Not that I mind personally; but as a sysadmin, if there's anything that can block mail, you [as the sysadmin] are going to be blamed when someone doesn't get their mail. So, the less I can do where the system holds mail the better. I'd far rather reject a few pieces of legit mail and generate bounces than quarantine them and, over time, get people so they always suspect the mail system when something doesn't show up. I can simply say - the mail server NEVER holds mail that doesn't include attachments. Ever. If Sam's mail isn't here, you should check with Sam. :) [We are quarantining mail with attachments, so there's that - but lets not talk about that very loudly, ok?! :) ]

In general, I want to make most decisions about what/how I'm going to mail before accepting it. We do use RBL's in postfix pre-accept and those are immensely helpful. But the additional decisions in Amavis and SA have far more utility before the MTA gives a 200 accept response. [For example, IIRC, we reject 95% of spam [that got past the RBL's] pre-accept. Thus we only have to deal with 5% of the remaining amount in a mailbox. It's a similar story with attachments. That's huge. Disk-space, Disk I/O, CPU performance [not so acute these days with excess CPU, really, but still], etc.

And with attachments - having very few actually show up, means that users have less opportunity to open something they shouldn't.
It helps that the on-site sysadmin is pretty vigilant and available to handle user queries about attachments they're not certain of - but not allowing them through somewhat blindly is certainly a big piece.

I'm sure there are other reasons I prefer pre-accept - but those are the ones that first come to mind.
And I've been just incredibly happy with Amavis running this way - even though it's has potential problems. [We'd be easier to DOS, for example.]

In practical use, it's been far better than any other solution I've seen, other than something like a paid Barracuda box. [Even then, I'm not sure it would be all that much better.]

-Greg


 
Gregory,
 
I don’t have direct experience, since I’ve never used it that way. 
 
Additionally, as far as I understand, the Postfix Before-Queue setup is not recommended for amavisd-new since there is a risk of mail loss if amavis fails among other things and I’ve had it fail before with some message that amavis simply didn’t like (Russian language emails)
 
Any particular reason why you use it that way?
 
 
From: Gregory Sloop [mailto:gregs at sloop.net] 
Sent: Friday, July 12, 2019 1:48 PM
To: Dino Edwards <dino.edwards at mydirectmail.net>; Curtis Vaughan <curtis at npc-usa.com>; amavis-users at amavis.org
Subject: Re: whitelist
 
Dino...

IIRC the following doesn't work if Amavis is set in postfix as a pre-accept filter, right?
[It seems I looked at doing it this way, but since we use Amavis as a pre MTA-accpet filter, this wasn't even an option. Just wanting to confirm...]

-Greg

DE> Here's how to do it with BONUS blacklist:

DE> In postfix /etc/postfix/main.cf set the following for whitelist senders:

DE> smtpd_sender_restrictions = check_sender_access
DE> hash:/etc/postfix/amavis_senderbypass

DE> In the /etc/postfix/amavis_senderbypass file enter email
DE> addresses and/or domains you wish to whitelist (one per line) as follows:

DE> bob at example.com  FILTER amavis:[127.0.0.1]:10030
DE> example2.com  FILTER amavis:[127.0.0.1]:10030

DE> Ensure you postmap the file and reload postfix

DE> In Amavis /etc/amavis/conf/50_user set the following to whitelist
DE> recipients (ensure port 10030 is available in your system):

DE> $inet_socket_port = [10021, 10030];

DE> # This policy will bypass ALL checks.
DE> read_hash(\%whitelist_sender, '/etc/amavis/white.lst');
DE> @whitelist_sender_maps = (\%whitelist_sender);



DE> $interface_policy{'10030'} = 'BYPASSALLCHECKS';
DE> $policy_bank{'BYPASSALLCHECKS'} = { # mail from the pickup daemon
DE>     log_level => 5,
DE>     bypass_spam_checks_maps   => ['@whitelist_sender_maps'],  # don't spam-check this mail
DE>     bypass_banned_checks_maps => ['@whitelist_sender_maps'],  # don't banned-check this mail
DE>     bypass_header_checks_maps => ['@whitelist_sender_maps'],  # don't header-check this mail
DE>     bypass_virus_checks_maps  => ['@whitelist_sender_maps'],  # don't virus-check this mail
DE> };


DE> In /etc/amavis/white.lst enter the the SAME senders and/or
DE> domains as you set in the /etc/postfix/amavis_senderbypass file
DE> from above but without the  "FILTER amavis:[127.0.0.1]:10030" part as follows (one per line):

DE> bob at example.com 
DE> example2.com 

DE> So basically this tells postfix that any sender matching the list
DE> to inject to Amavis at port 10030 and then Amavis has an interface
DE> policy at 10030 where it takes action according to the policy
DE> settings. You can adjust the Amavis policy as you see fit. In the
DE> example above, it bypasses ALL checks (spam, banned, header and virus) checks.

DE> Here's the blacklist (much simpler)

DE> In /etc/amavis/conf/50_user set the following:

DE> # Blacklist Senders
DE> @blacklist_sender_maps=(read_hash(\%blacklist_sender, '/etc/amavis/black.lst'));

DE> And populate /etc/amavis/black.lst with senders you wish to block.

DE> There is also a way to do a sender to recipient block/allow but
DE> that only bypasses spam checks and it's a bit more complicated to
DE> set. I can send you info on that if you want.

DE> Thanks



DE> -----Original Message-----
DE> From: amavis-users
DE> [mailto:amavis-users-bounces+dino.edwards=mydirectmail.net at amavis.org] On Behalf Of Curtis Vaughan
DE> Sent: Thursday, July 11, 2019 4:38 PM
DE> To: amavis-users at amavis.org
DE> Subject: whitelist

DE> I have been unable for a very long time now to figure out how to
DE> whitelist certain email address or domains. 
DE> I have found several different blogs/help sites that "provide" an
DE> answer, but none of them have ever worked. 
DE> Creating whitelists for postfix that referred to by main.cf
DE> definitely haven't worked. Another "solution" involved including a
DE> line in main.cf that basically tried to bypass amavis.
DE> Anyhow, I feel I'm approaching the solution in either case the
DE> wrong way as they concentrate on postfix and not amavis. 
DE> Hopefully someone can't point me in the right direction?
DE> Thanks!

DE> I'm using postfix with amavis on ubuntu. 


-- 
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x82
EMail: gregs at sloop.net
http://www.sloop.net
---

-- 
Gregory Sloop, Principal: Sloop Network & Computer Consulting
Voice: 503.251.0452 x82
EMail: gregs at sloop.net
http://www.sloop.net
---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.amavis.org/pipermail/amavis-users/attachments/20190712/4ebb9d26/attachment.html>