As stated in the original message, I have amvisd-new as a pre-queue
filter, but it's not working all of the time, so I'm still generating
backscatter.
I've got amavisd-new set up to run as a pre-queue test in the
postfix's master.cf:
smtp inet n - n - - smtpd
-o smtpd_sasl_auth_enable=yes
-o receive_override_options=no_address_mappings
-o content_filter=smtp-amavis:127.0.0.1:10024
-o smtpd_tls_security_level=may
smtp-amavis unix - - y - 2 smtp
-o smtp_data_done_timeout=1200
-o disable_dns_lookups=yes
-o smtp_send_xforward_command=yes
In my amavisd.conf, I've got it set to reject everything bad:
$final_virus_destiny = D_REJECT;
$final_banned_destiny = D_REJECT;
$final_spam_destiny = D_REJECT;
$final_bad_header_destiny = D_REJECT;
Most, but not all of the time, the message will either get passed
through, or it will get rejected and remain the sending MTA's problem.
However, there are some times with the current configuration, where
neither of these things happen and my local system generates a
backscatter message. That's what I'm trying to avoid.
--Todd
On 4/17/17 12:06 PM, Michael Orlitzky wrote:
On 04/17/2017 09:00 AM, Todd D. Taft wrote:
I was hoping to avoid dropping messages on the floor for well-behaved
servers. While it's rare, I have found the occasional ham that gets
marked as spam. With D_REJECT, at least the sender gets a notification
that the message didn't go through.
You can put amavisd-new in front of postfix, acting as a proxy:
http://www.postfix.org/SMTPD_PROXY_README.html
In particular, the pros and cons of that approach are listed here:
http://www.postfix.org/SMTPD_PROXY_README.html#pros_cons
Doing so lets you reject spam immediately, but the trade-off is that
it requires more resources because you can't just queue up messages
for later scanning.
(This is "not supported" by amavis, but works just fine.)
--
Todd D. Taft
t...@unclet.net
