On 11/10/2012 9:09 AM, Daniele Nicolodi wrote: > > What I observe is that postfix is receiving messages containing a forged > Delivered-To header that makes postfix think it is seeing a mail > forwarding loop. The local(8) daemon bounces the messages, but > those messages are spam and the from addresses are invalid, therefore > the bounces get stock in the delivery queue. This is not a problem in > itself, but I do not like to generate bounces for spam messages. >
If it's just a handful of messages, probably "do nothing" is the best solution. It's also worth examining the spam to see if there is some common feature other the the Delivered-to header you can use to reject them. If you are seeing a lot of these, there is no perfect solution, but there are some things you can do. Do whatever seems to work best in your environment, or do nothing. Separate incoming and outgoing - If you happen to have (or care to set up) multiple postfix instances to separate incoming and outgoing mail, it is somewhat safe to REJECT incoming internet mail containing a Delivered-to @yourdomain. Don't do this on outgoing mail; your users won't be able to forward messages. Plus-1 loop detection - Use header_checks something like /^X-Loop.*@example\.com$/ REJECT /^(Delivered-to: .*@example\.com)$/ REPLACE X-Loop-$1 This will push the loop detection back one loop. I can imagine cases where this will break horribly. Nuclear option - Remove the Delivered-To header and hope real loops get detected by the presence of too many Received: headers before something melts. /^Delivered-To: .*@example.com/ IGNORE Some forwarding methods alter/remove Received: headers, so this is Not Recommended. Use this as a temporary crutch if you're getting hammered with forged headers and can't tell which are legit and which aren't. Run spamasssassin sooner - detect spam before local(8) gets the mail by using a smtpd_proxy_filter or milter to detect and reject spam before it enters your server. amavisd-new and spamass-milter are popular and effective choices. Note running spamassassin pre-queue may require more resources than running it during delivery since there's a time limit involved; your server must be able to finish scanning the mail before the remote server disconnects. Good luck. -- Noel Jones
