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. In looking at the logs, I think the
backscatter messages are generated when the spammer disconnects the
session immediately after ending the DATA part of the SMTP session but
before the system responds with a reject code. A legitimate MTA should
wait for a reply. Ideally, I'd like to try to reject, and only drop if
the reject fails.
--Todd
On 4/14/17 6:22 AM, Robert Moskowitz wrote:
On 04/14/2017 04:35 AM, Todd D. Taft wrote:
I'm running amavisd-new on a CentOS 7 system with postfix as my MTA.
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;
However, I've noticed that somehow I'm still generating some
backscatter on this server. (mails from local MAILER-DAEMON going
out to alleged spam senders).
Is there a way to stop this?
I use:
$final_banned_destiny = D_DISCARD;
--
Todd D. Taft
t...@unclet.net
