On 3/30/2016 9:42 AM, Miles Fidelman wrote: > > > 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 >
There isn't a good solution other than better filtering on the front-end. The ugly hack is to reduce maximal_queue_lifetime, but that affects all mail -- including good mail with delivery delays -- and is strongly not recommended. The proper solution is to be stricter on what you accept. Yes, this is a difficult problem, but it's worth a great deal of effort. -- Noel Jones
