On Mon, 2009-06-29 at 08:20 -0400, Charles Marcus wrote: > On 6/29/2009, Steve (steve.h...@digitalcertainty.co.uk) wrote: > > I've read a few archive posts regarding the generation of bounce/ndr > > messages and I can understand some of the cutting remarks such as 'don't > > accept mail for invalid users in the first place'. > > Yep - but accepting for invalid users is different from your problem > described below of bouncing due to failing CONTENT inspection... > > > That aside, is it actually possible to stop the SENDING (or the > > generation) of NDR/Bounce messages. > > It might be possible to do this ONLY for messages that fail the content > inspection, but otherwise, postfix doesn't 'send' NDRs, it simply > rejects the message at smtp time - it is the ORIGINATING server (the one > that SENT the message) that generates the NDR. > > If your server is accepting then bouncing, something is broken... fix > the problem. > > I don't do it, but I think you can have a before queue content filter > using amavisd-new and spamassassin... > > > I have a couple of content milters / filters running that hold the mail > > during the data stage and inspect it. I appreciate that the RFC's say > > the decision needs to be made before the DATA section - but that is not > > always ideal. > > The rule is simple... if you accept the message, don't bounce it > afterwards, but if you must for some specific reason accept a message > and then reject it for whatever reason afterwards, the RFC requires a > bounce (I think). The best way to deal with this is if you accept the > message and then it fails some content inspection, just tag it and > deliver to a spam folder or something. > Appreciate that - but to do this defeats the object of rejecting mail at SMTP time (to avoid the bounce in the first place). What appears to happening is the spambot sending the mail does not hang around for the 250 OK at the end of the <lf>.<lf>. If it did, it would have been SMTP rejected. (no bounce ever needed).
Sure - it's not RFC compliance to *not* bounce something you have accepted responsibility for - but Postfix had not taken responsibility. It never gave a 250 OK. I would never have given a 250 OK for the message concerned. I have some concern that clamsmtp may be 'misfiring' because the logs show (127.0.0.1[127.0.0.1]:10025) it being involved. However, I can recreate this if I telnet it and drop off without waiting for the OK after the data. Jun 29 08:54:27 mta1 postfix/smtp[14068]: 5B63AAC10C: to=<andyspa...@munged>, relay=127.0.0.1[127.0.0.1]:10025, delay=2, delays=1.2/0.01/0.06/0.76, dsn=5.7.1, status=bounced (host 127.0.0.1[127.0.0.1] said: 550 5.7.1 Blocked by Spamassassin (in reply to end of DATA command)) But as far as I can tell, it's not given a 250 OK anywhere so it should not have gone on to produce a bounce from the blocked message (which in turn was 550'd); Jun 29 08:54:27 mta1 postfix/bounce[14074]: 5B63AAC10C: sender non-delivery notification: 60FDDAC8C2 Jun 29 08:54:27 mta1 postfix/qmgr[13983]: 5B63AAC10C: removed Jun 29 08:54:27 mta1 postfix/qmgr[13983]: 60FDDAC8C2: from=<>, size=4371, nrcpt=1 (queue active) Jun 29 08:54:30 mta1 postfix/smtp[14076]: 60FDDAC8C2: to=<adamdickinsonwat...@coolest-gadgets.com>, relay=coolest-gadgets.com[75.127.98.32]:25, delay=3.4, delays=0.01/0.01/3.3/0.15, dsn=5.0.0, status=bounced (host coolest-gadgets.com[75.127.98.32] said: 550 No Such User Here" (in reply to RCPT TO command))
