Re: Sending NDRs (if any) from different server than normal mails
On 01/26/2012 10:37 AM, Gábor Lénárt wrote: Hi, 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 ? I do sender/rcpt checking, and so on, No, you don't - see below. but still there are some cases when NDRs are generated or sent (for example: customer's own mail server which generates NDR - I have no control over it - and I have outgoing relay service for customers -, This is how it works: the sender SHOULD be notified of a failure to deliver mail. or when I accept mails at the MX server, but after some hops inside my system it turns out that the target mail server is over quota for that rcpt meanwhile, or customer has inbound mail relay service, and they can't provide map for rcpt check, etc). Do not accept mail that YOU cannot deliver. If there are multiple systems involved, share the valid recipients between these systems. Fortunately, the rate of sending out NDRs are quite low now (after I've introduced rcpt checking, also sender check for senders I have information on within a domain I'm handling, at least, not SAV!). 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 ? 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. I'm trying to implement this, but I have got few problems. First, I've tried this: sender_dependent_relayhost_maps = hash:/etc/postfix/sender_is_null_for_ndr The table specified the null-key and target is the ndr server. My second try was this: smtpd_sender_restrictions = [...] check_sender_access hash:/etc/postfix/sender_is_null_for_ndr_filter where the /etc/postfix/sender_is_null_for_ndr_filter file is: FILTER smtp:[10.10.10.10] The idea about this, that though it's a filter, it won't pass back the mail (the NDR server, 10.10.10.10 in this example) just I use FILTER action to be able to modify the target of the mails. However it seems both of these solutions has problems: It seems, locally generated NDRs (if there is any at all, it was a test scenario, that I wanted to generate) won't be handled well, at least not with the second solution. The problem I've experienced with the first solution: if I have a domain with a transport map, then NDRs (would be sent for an rcpt in that domain) are sent directly, bypassing my need to be relayed for the NDR server (which use the same ldap based transport map to send them out - or block, as I plan to analyze NDR traffic there, as I've told). My head hurts. WHY do you think bounces should be sent by a different server ? What is the nice and clean solution for this problem What problem ? -- J.
Re: Sending NDRs (if any) from different server than normal mails
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
Sending NDRs (if any) from different server than normal mails
Hi, First of all, I know sending NDRs is not a great idea. I do sender/rcpt checking, and so on, but still there are some cases when NDRs are generated or sent (for example: customer's own mail server which generates NDR - I have no control over it - and I have outgoing relay service for customers -, or when I accept mails at the MX server, but after some hops inside my system it turns out that the target mail server is over quota for that rcpt meanwhile, or customer has inbound mail relay service, and they can't provide map for rcpt check, etc). Fortunately, the rate of sending out NDRs are quite low now (after I've introduced rcpt checking, also sender check for senders I have information on within a domain I'm handling, at least, not SAV!). 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'm trying to implement this, but I have got few problems. First, I've tried this: sender_dependent_relayhost_maps = hash:/etc/postfix/sender_is_null_for_ndr The table specified the null-key and target is the ndr server. My second try was this: smtpd_sender_restrictions = [...] check_sender_access hash:/etc/postfix/sender_is_null_for_ndr_filter where the /etc/postfix/sender_is_null_for_ndr_filter file is: FILTER smtp:[10.10.10.10] The idea about this, that though it's a filter, it won't pass back the mail (the NDR server, 10.10.10.10 in this example) just I use FILTER action to be able to modify the target of the mails. However it seems both of these solutions has problems: It seems, locally generated NDRs (if there is any at all, it was a test scenario, that I wanted to generate) won't be handled well, at least not with the second solution. The problem I've experienced with the first solution: if I have a domain with a transport map, then NDRs (would be sent for an rcpt in that domain) are sent directly, bypassing my need to be relayed for the NDR server (which use the same ldap based transport map to send them out - or block, as I plan to analyze NDR traffic there, as I've told). What is the nice and clean solution for this problem which works in any cases? I met NDRs generated locally but also from customers' servers and I need all of them to be passed to the NDR server. Thanks a lot in advance, - Gábor
