NDR and Backscatter - Does :fail: help this?

niatech

Well-Known Member
Feb 20, 2005
121
0
166
Hi all,

I've been having discussions with a customer of mine behind what is the best way to handle NDR and Backscatter spam.

We're under the impression that :blackhole: will not return anything to the potentially faked from address and thus would help the NDR and backscatter problem.

But, from what I read, many people suggest that :fail: is the right (or better) way to handle this.

Would someone be able to explain how or why :fail: would be better, since it does generate a failure or bounce message?

Thanks!
 

mtindor

Well-Known Member
Sep 14, 2004
1,363
65
178
inside a catfish
cPanel Access Level
Root Administrator
I'm sure somebody will disagree, but in _no_ way is :blackhole: ever a better option than :fail:. Use :fail: - forget about :blackhole:

Blackhole accepts the mail and devnulls it. This means it has to be accepted into your system and processed at least to some extent. With :fail:, you reject during SMTP any mail to a nonexistent address.

Blackhole accepts all mail - which makes spamming applications believe that the user actually exists, so you're even more likely to get mail to nonexistent addresses in the future if those addresses are handled by :blackhole:.

Mike
 

niatech

Well-Known Member
Feb 20, 2005
121
0
166
Ok,

What about spammers faking from addresses (using valid ones) and sending to incorrect addresses and then these bounces are going to these valid from addresses falsely and then our servers get added to RBL's?
 

mtindor

Well-Known Member
Sep 14, 2004
1,363
65
178
inside a catfish
cPanel Access Level
Root Administrator
Ok,

What about spammers faking from addresses (using valid ones) and sending to incorrect addresses and then these bounces are going to these valid from addresses falsely and then our servers get added to RBL's?
See, that's the thing - they aren't bounces. _Your_ server is not generating bounces. A bounce occurs when:
a. a mailserver accepts mail
then
b. for some reason decides the mail cannot/should not be delivered to the recipient
then
c. sends back a notification to the reported sender (with some or all of the original message included).

When you reject during SMTP, you are not sending a notification back to any sender. _your_ server is simply sending a rejection error back to the sending machine whether that be a hijacked spamming machine or another legitimate mailserver that was used to send spam to you through.

Lets assume that the sending machine sending you the spam [that you reject during SMTP] is an actual mail server that is relaying spam to your machine.

1. spammer relays mail to one of your nonexistent users through a server called test.example.com [xxx.xxx.xxx.xxx]
2. your mail server rejects during SMTP saying 'no such user' as part of the SMTP process
3. test.example.com then is unable to deliver the spam to you and it is test.example.com who then generates a bounce back to the sender (a valid forged FROM address) and then test.example.com ends up on RBLs.

Mike