On 3/30/16 10:11 AM, Noel Jones wrote:
On 3/30/2016 6:24 AM, Miles Fidelman wrote:
Hi Folks,
I'm busily trying to tune our system to reduce the amount of bounceback
we generate. (Wietse - thanks for earlier reply!)
Context: Postfix mail system, with sympa mailing list manager.
Obviously, I'm doing what I can to discard incoming mail with forged
addresses.. still a struggle.
One obvious thing that I did was to changed the "bounce" lines in
master.cf to "discard" - which has eliminated multiple attempts to
deliver messages to addresses that accept-then-bounce.
But I'm still seeing things like this:
Mar 29 14:10:44 server1 postfix/smtp[13617]: 0320DCC5E0:
to=<substanceab...@expern.top>,
relay=o4pz11.expern.top[216.169.122.211]:25, delay=1373,
delays=1193/0.05/0.31/180, dsn=4.4.2, status=deferred (conversation
with
o4pz11.expern.top[216.169.122.211] timed out while sending message
body)
Don't accept mail you can't deliver. Surely this mail would have
been blocked by zen.spamhaus.org before it entered your system.
And the .top TLD is an excellent candidate for blacklisting before
it enters your system.
Easier said then done. This is one example of a class of messages that
are getting caught in our deferred que.
These messages are postings to moderated email lists from forged
addresses. The incoming messages are delivered just fine - to the list
management software. The messages that are getting deferred are "your
message has been submitted to the moderator" kinds of messages, directed
to non-existent returned addresses.
Given that we get a huge number of these, from a huge variety of sources
(mostly spambot infections, I expect), blocklists are not a big help in
catching them on their way into the system (though we try).
The problem is avoiding accumulating these in the deferred que, where
postfix tries to resend periodically.
For messages that get a firm bounce, we can simply discard (and I've
configured master.cf accordingly).
My question is how to to detect and discard messages that are
not-quite-bounced - i.e., by an abnormal, early disconnect during SMTP
session initiation.
Where messages are getting rejected during the smtp phase
(presumably by
header checks and/or blocklist checks) - what's the magic configuration
change to have these discarded rather than deferred?
The "timed out" means the receiving system stopped responding.
Probably the spammer's system is overloaded with others trying to
return undeliverable mail.
Yes, I get that - as noted above, the question is how to detect and
react, such that these messages are discarded rather than re-queued.
Miles Fidelman
--
In theory, there is no difference between theory and practice.
In practice, there is. .... Yogi Berra
