Unsolicted bounces, aka backscatter

[newwebsite]

I have a question about this because something doesn't make sense to me and I am looking for a solution.

Here is a scenario. I send an email to user[at]example.com. user[at]example.com is set up to be forwarded to another server and address user2[at]example2.com. But user2[at]example.com does not exist so it refuses to accept the email. Now should the server that handles the email for user[at]example.com, the one in the middle, bounce the email back to my isp mail server or not?

My concern is that the server in the middle has no way to know if it is sending back to the original sender or creating backscatter.

I manage many mail servers that have forwards set up. I want to eliminate backscatter but I also want the legitimate senders to get the bounces. I don't know if both are possible.

[turetzsr]

<snip>

Here is a scenario. I send an email to user[at]example.com. user[at]example.com is set up to be forwarded to another server and address user2[at]example2.com. But user2[at]example.com does not exist so it refuses to accept the email. Now should the server that handles the email for user[at]example.com, the one in the middle, bounce the email back to my isp mail server or not?

My concern is that the server in the middle has no way to know if it is sending back to the original sender or creating backscatter.

<snip>

...IIUC, you have answered your own question, almost! <g> The server that handles the email for user[at]example.com has no way of knowing who the actual sender (e-mail address) is, because both "From" and "Reply-to" addresses can be forged. Therefore, a server handling e-mail must never try to return to any e-mail address found in the "From" or "Reply-to" address fields.

...That is different from "bounc[ing] the email back to [the originating] isp mail server, though -- the IP address of that server is much less likely to be forged. The recommended solution is for the receiving server (the one handling the e-mail for example.com) refuse receipt with a "500"-level reply.

...For a better explanation, see SpamCop Wiki entry "BlowBack."

[Farelf]

For a prescriptive treatment of the topic, refer to the official SC FAQ entry - http://members.spamcop.net/fom-serve/cache/329.html

[newwebsite]

For a prescriptive treatment of the topic, refer to the official SC FAQ entry - http://members.spamcop.net/fom-serve/cache/329.html

I cannot read that as I am not a spamcop member. I am a mail admin trying to figure out what the accepted is now.

EDIT: I figured it out. Reading it now.

[newwebsite]

I want to know what the preferred policy is from spamcop members perspective.

If a server in the middle gets a rejection for whatever reason then it needs to just drop it and not try to send a message back to the original sender since it cannot trust the from email address and at that point does not know what the ip address is of the original sending server.

For a server in the middle it is better to drop bounces. In this case if the original sender is legit then they will not get the notice that the email was undeliverable. Is this the policy mail server admins should be following now?

Is the fact that a legit sender may not be notified of an undeliverable email accepted now?

Thank you for your time and explaining this to me.

...IIUC, you have answered your own question, almost! <g> The server that handles the email for user[at]example.com has no way of knowing who the actual sender (e-mail address) is, because both "From" and "Reply-to" addresses can be forged. Therefore, a server handling e-mail must never try to return to any e-mail address found in the "From" or "Reply-to" address fields.

Correct. I understand that.

...That is different from "bounc[ing] the email back to [the originating] isp mail server, though -- the IP address of that server is much less likely to be forged. The recommended solution is for the receiving server (the one handling the e-mail for example.com) refuse receipt with a "500"-level reply.

I understand that as well.

The problem is when the email is forwarded to another server and that next server rejects it for some reason. What is the server in the middle supposed to do?

To avoid backscatter the server in the middle must drop the rejection response since at that point it cannot trust the from address and cannot send a rejection back to the originating server. In this case even a legit sender will not get the rejection response and know that his email was not delivered.

If that is considered acceptable now then that is what we will work on trying to do.

[rconner]

I cannot read that as I am not a spamcop member. I am a mail admin trying to figure out what the accepted is now.

Change "members" to "www" and you should be able to read the link. Here: http://www.spamcop.net/fom-serve/cache/329.html

I think the recent update of SMTP has included some language to recognize that it is sometimes appropriate not to bounce to an address that is "seriously fraudulent or otherwise inappropriate" (see http://en.wikipedia.org/wiki/Bounce_messag...opping_messages).

I've been told that SPF (http://openspf.org) could be used to verify the bona-fides of a return-path address to help you decide whether or not you wanted to bounce to it, but I'm not an expert here. Anyway, SPF may still not be widely enough used to rely on it in all cases. Also, not clear how well this would work in the case of a relay situation such as you describe.

-- rick

[turetzsr]

<snip>

If a server in the middle gets a rejection for whatever reason then it needs to just drop it and not try to send a message back to the original sender since it cannot trust the from email address and at that point does not know what the ip address is of the original sending server.

For a server in the middle it is better to drop bounces. In this case if the original sender is legit then they will not get the notice that the email was undeliverable. Is this the policy mail server admins should be following now?

Is the fact that a legit sender may not be notified of an undeliverable email accepted now?

<snip>

...Thank you for taking the time to return and further explain your situation! I believe I get it now! <g>

...I see no good alternative to your dropping the bounce. Not that I'm an expert by any means, but while I appreciate your conscientiousness, IMHO it is not your responsibility to notify the original sender but, rather, the responsibility of your customer to ensure that forwards are sent to a valid e-mail address. The most I would think you can be expected to do is to use an alternate contact method for your customer if your customer has provided a method that is valid (not, for example, the invalid forwarding address). If your terms of service does not already include some such language, you may wish to consider adding it!

[newwebsite]

In my further research I have found that much of the problem is with the postmaster[at] address.

RFC states that postmaster addresses have to be accepted. So the exim is set up by default is to accept postmaster addresses. But then when postmaster[at]example.com is undeliverable, because the owner of the domain has not set it up, then it bounces the email to the forged From address. At that point it is too late to reject the email because it has already been accepted and then it was determine that is was undeliverable.

So the choice in this case is to either disable the default of accepting of all postmaster emails or to set up postmaster addresses for all domains hosted on the server even if you have to blackhole them.

Forwarding to a bad address is still an issue but I do not now think it is the biggest problem. It probably does not account for very much of the backscatter. Probably the postmaster issue accounts for 99% of my backscatter.

So far today in 7 hours several hundred emails addressed to postmaster that were probably bounced to forged email addresses. Now I know how to stop that problem anyway.

I do not remember seeing this particular problem mentioned anywhere in the spamcop help sections. Hopefully this information can be past on to others having a similar problem and don't know what to do.

[turetzsr]

In my further research I have found that much of the problem is with the postmaster[at] address.

<snip>

...Thanks for returning here and letting us know. Good sleuthing!

Hopefully this information can be past on to others having a similar problem and don't know what to do.

...You posting here does that. Thank you!