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:[email protected]] Sent: Friday, July 12, 2019 1:48 PM To: Dino Edwards <[email protected]>; Curtis Vaughan <[email protected]>; [email protected] 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> [email protected] 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> [email protected] 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:[email protected]] On Behalf Of Curtis Vaughan DE> Sent: Thursday, July 11, 2019 4:38 PM DE> To: [email protected] 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: [email protected] http://www.sloop.net --- -- Gregory Sloop, Principal: Sloop Network & Computer Consulting Voice: 503.251.0452 x82 EMail: [email protected] http://www.sloop.net ---
