@All Using amavis in a pre-queue setup is the best you can do in MTA to MTA traffic. It is effective, stable and carefree.
We've (sys4) been using amavis in pre-queue setup on mail plattforms – performance clusters – that do more than 900 msg/second and in more than 15 years there hasn't been one incident related to anything related to a pre-queue setup. I do recommend to integrate amavis as MILTER in Postfix, since that gives the greatest flexibility to combine amavis with other MILTERs. Running it as smtpd_proxy_filter by Postfix design limits its ability to integrate with other tools – MITLTERs won't be able to "see" the body, which mostly makes them useless. p@rick P.S. Any pre-queue process will introduce a noticable delay. This is imposed by the scan process itself. It is the same delay you have in post-queue – its just that now you get to "see" in SMTP sessions. Clients won't bother. The typical client timeout is 600 second. That's ten minutes a client will wait for your amavis setup to get the job done. If it hasn't finished by then you have a problem – no matter if you are using a pre- or a post-queue setup. Am 12.07.19 um 20:10 schrieb Dino Edwards: > Re: whitelist > > > > 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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]> > http://www.sloop.net > /---/ > -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Schleißheimer Straße 26/MG,80333 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer, Wolfgang Stief Aufsichtsratsvorsitzender: Florian Kirstein
smime.p7s
Description: S/MIME Cryptographic Signature
