On 27 Jan 2012, at 23:57, Jeroen Geilman wrote: > On 01/26/2012 10:37 AM, Gábor Lénárt wrote: >> First of all, I know sending NDRs is not a great idea. > > .. they are a requirement of SMTP. > What on Earth posesses you to think they are bad ?
An increasingly crackpot attitude towards all forms of backscatter by the "Spam fighters" and other supposed legions of the light, I suspect. The idea is not to generate bounces in case the sender address is forged. While it's a legitimate concern, it's not enough of a concern to deny senders disposition reports. Those people affected by enough backscatter should seriously consider employing BATV. TMDA also has a built-in address signing mechanism which you should be using anyway if you use TMDA at all to help with this. A very small number of things are affected by SES; whitelist them (EG ezmlm, which has problems of its own worth considering replacing it anyway). >> However, still, I would like to make things better by passing NDRs to >> another server: its task is only send out the NDRs, nothing more. It would >> help to analyze/block the NDR traffic there, also if that server is >> blacklisted >> (because of being source of "backscatter"), it's not a real problem, as >> "normal" mails are not sent from there. > > I have no idea what you mean here. > Why should bounces be sent by a different server ? He wants to send bounces through another IP so *that* IP can get blocked. He wants to reduce the effects of getting blocked to just bounces, when one of the legions of the light swoop on him for daring to send backscatter. Example: http://www.backscatterer.org/ . Qmail has this as a patch. Courier has some nice backscatter suppression logic in it, to stop trouble users causing more trouble over a short period of time. These are both reasonable approaches. > If you're not already using proper client DNSBL blacklisting, as you seem to > indicate above - you're really running a decade behind the times. > > And if YOU are generating backscatter, then you are not using sufficient > restrictions on incoming mail. > > DO NOT accept mail that you cannot deliver. These are points I'd rather not debate, though not from agreement. I think it is fair to say though that where options exist not to accept mail, according to your policies, then you should not accept that mail. This almost always includes protocol violations, viruses, known spam, MX relay RCPT, etc. It won't include autoresponders, challenge-response, mailing list servers, failed/delayed mail, etc, at least until implementations of some of these come along which reject at SMTP time, where that makes sense. Cheers, Sabahattin
