Ideally, I would have started this as a page in the Wiki, since that seems to be the most efficient way. However, it appears it has to go out in the forum first? Anyway...

Question: I got an email from SpamCop saying "(IP address) appears to be sending unsolicited bounces." What is an "unsolicited bounce" or "misdirected bounce"?

First, let's clear up the term "bounce". A bounce is a message, also known as a non-delivery report (NDR) or delivery status notification (DSN), which has been generated by a mail server to report on the delivery status of an email message.

For example, a "bounce" could result when a user "Joan[at]from.com" attempted to email a user "Fred[at]to.com", but there is no such user "Fred" at that domain. The mail server at "to.com" generates a new message (NDR) and addresses it to "Joan[at]from.com" to let her know that her mail couldn't be delivered because there is no such user "Fred".

So, the term "unsolicited bounce" or "misdirected bounce" refers to a bounce that is sent to a user who should not have received it.

Using the above example, the mail server sends an email to "Joan[at]from.com" stating her message could not be delivered, whereas she never tried to send such a message in the first place.

If your mailserver is sending "unsolicited bounces" it could get block-listed by SpamCop. This is because your server is technically sending bounces to users who don't deserve to get them.

Question: How does an "unsolicited bounce" or "misdirected bounce" occur?

The simple answer is that the "From" address (or the MAIL FROM field in SMTP) in messages your mail server can easily be forged, because of a loophole in the design of email protocols. This loophole is commonly exploited by spammers. They almost always lie about who the "sender" of a message is. Sometimes the "sender" is a random user that the spammer generates, who doesn't exist. Sometimes the "sender" is a real address, either because the randomly generated "sender" turns out to be a real address, or because the spammer has specifically used a real address as the "sender" without it being random.

When a spammer addresses email to "Fred[at]to.com", as in the above example, he can also forge the sender's address to say that the mail is from "Joan[at]from.com". Sadly, "Joan[at]from.com" will receive an unsolicited bounce, unless the mail server for "to.com" is properly configured.

Question: How do I prevent my mail server from sending "unsolicited bounces"?

• Configure your mail server to only generate bounces to local recipients. Using the above example, the mail server for "to.com" should only generate new emails to users who have sent email from addresses that are local to "to.com".
• Configure your mail server to reject messages at the SMTP session if they are addressed to invalid recipients. By rejecting the message at the SMTP session, any "bounces" will be sent by other mail servers involved in the transfer (ideally a server local to the sender, if indeed the sender is not a spammer). Sadly, it is not always possible to configure all mail programs to behave in these ways. But even AOL changed their mail server's behavior back in the days when this problem first began, because of how many people were getting "misdirected bounces".

For more info on how to configure your mail server to not generate misdirected bounces, see the SpamCop FAQ entry at http://spamcop.net/fom-serve/cache/329.html#bounces

Question: Why has this loophole (of being able to forge "From" addresses) not been fixed yet!

The short answer is that the protocols used on the Internet to send email have to be agreed upon by all parties involved. Lots of solutions have been proposed. But so far, nobody has been able to propose a technical solution that is acceptable to everyone.

First of all, the impact of such a change would be huge, because of the huge numbers of mail servers and the different software used to support those servers. In some ways, it would be almost like getting the entire world to convert their electric current to some new voltage.

To understand why the loophole exists, it's useful to know that when the Internet protocol used for email transfer was designed, nobody anticipated that the users involved would misuse the system (how many times have we heard this before!). This is because they were mostly scientists and government contractors. Now, everybody in the world is using this protocol, and the spammers have taken advantage of the design flaw.

The lawmakers have attemtped a legal solution, called the CANSPAM Act http://www.ftc.gov/bcp/conline/pubs/buspubs/canspam.shtm, which bans falsifying header information in an email. Given that spam has increased in volume since this act went into legislation, you can see how ineffective this legislation is.

Other solutions have been proposed and which are being used to help authenticate the identity of email senders, but they are only small steps with respect to solving the big problem of forged headers.

A good explanation in technical terms the weakness of the protocol can be found at http://www.ironport.com/pdf/ironport_toc_bounce_report.pdf

The way it is supposed to work is that the to.com server reports an error during the transaction and the from.com server generates the message to its user. The problem comes when a server accepts the message (tells from.com all is well) but then determines it is not deliverable.

Hi Steve - not sure what your point of posting that is. I have clarified exactly what you said in the questions ans answers that followed... or at least I thought I did...

Very good FAQ entry, two thumbs up. I agree this would be helpful to have in the Wiki as well.

Though I'm thinking the printed copies stapled to the foreheads of certain mail server administrators might be more effective

IMHO, the difference between a 'bounce' generated during the smtp connection and a 'bounce' email composed after acceptance of the message should be defined in the very first question. Don't think it 'clears up' the question of 'misdirected bounces' since the mail administrator who doesn't know the difference is the one who will be asking the question.

I don't see any mention of the RFC which addresses this (and which, to my knowledge, has not been amended) and which some admins quote as showing that they are not doing anything to warrant being blocked.

I also would add a paragraph about how the domain owners who receive these bounces are shocked and angered that their name is associated with spam and also that some have real difficulty handling the hundreds or thousands that they receive.

I would have organized the information differently, but other than the three comments above, I think it probably is a good addition to the FAQ.

Miss Betsy

ps I don't think there is any requirement that a FAQ be added to the forum before being entered in the wiki.

...A rare (first?) instance of a Newbie posting a proposed FAQ entry without even being prompted to do so. Thanks, Fuhrmanator!. Hopefully, you've started a trend.... <g>
...By the way:

• SpamCop Wiki entry "Bounce"
• SpamCop Wiki entry "BlowBack"
• SpamCop Wiki entry "How to Stop Bounces" (mostly not relevant to what your FAQ says, except for Steven P. Underwood's part)

Dang, I hate to ruin the joy, but .. you know me ....
[Scspamcop] Suggestion to improve FAQ wrt reports about "unsolicited bounces"

No such requirement. The Forum predates the Wiki, so data was 'here' first. FAQ entries that could use discussion would usually start 'here' as this venue is more conducive to carrying on a discussion, comparing notes and thoughts, the end result probably ending up in both venues.

Definition of the word Bounce .... takes work, the real problem being when folks fo the 'net' to do their research. way too many references out there that use bad definitions, but that's what someone found, so they continue to use what thry 'learned out there' and further help to muddy the waters.

Strictly speaking a 'bounce' can only occur during the initial SMTP attempted transaction. The receiving server rejects the incoming e-mail attempt with some reason, the 'sending' server then transmits this rejection to the actual sender. This is the only true definition of a bounce.

However, some folks wanted to fancy that up a bit, so the terms soft-bounce and hard-bounce showed up, originally meaning that the rejection was based on a temporary (soft) or a permanent (hard) error. Other folks didn't understand the 4xx vs. 5xx error code definitions, so they started translating things themselves, deciding to bring other things into their attempted descriptions of things not understood for others less knowledgable than themselves ... which then left 'new' data out there for even 'newer' users to find ....

The basic point is, if the rejection does not occur at the time of the initial attempted SMTP delivery, then it is not a 'bounce' ... a rejection notice of non-delivery sent by the 'receiving' server at a later time is actually specifically defined as a "brand new e-mail" .. and the fact that it usually is sent to the only data it sees as 'official' (specifically, for the scenario of this discussion, the forged data in the "From:" line) it then becomes the "Misdirected Bounce" .... which actually is further screwing up the definition, as once again, beig sent out after the fact, it is not actually a "Bounce"

And I hate to dampen the OP's enthusiasm also, but what a 'misdirected bounce' is explained twice in the Why Am I Blocked FAQ first page. It doesn't go into detail, or explain how to configure your computer to reject at the SMTP stage so that his FAQ could be linked to it to expand on the subject.

The problem that the ng poster had was that there is a special link in spamcop reports for 'misdirected bounces' that goes to the official spamcop FAQ which is not well written from his viewpoint. And there is nothing that can be done about that.

If the receiving admin doesn't understand and does come to the forum and does read the Why Am I Blocked FAQ then s/he will see the basic definition (without the history and reasons for 'bounce' emails being no longer useful).

Since the difference between rejection at the server and an email sent after acceptance is explained in an existing FAQ perhaps it would be better to rephrase the FAQ and include some of the history that Wazoo added plus my suggestions.

First, let's clear up the term "bounce". What we are talking about is a non-delivery report (NDR) or delivery status notification (DSN), which has been generated by a mail server to report on the delivery status of an email message.

For example, a "bounce" could result when a user "Joan[at]from.com" attempted to email a user "Fred[at]to.com", but there is no such user "Fred" at that domain. The receiving mail server at "to.com" generates a rejection message (NDR) to the sending server and the sending server composes an email to "Joan[at]from.com" to let her know that her mail couldn't be delivered because there is no such user "Fred".

The second example is an email composed by the receiving server after accepting the email and discovering it can't be delivered. The receiving server sends that 'bounce' email to the From: or the return path (or the MAIL FROM field in SMTP). There is an RFC about this and it was very useful at one time to be able to accept email and then send the NDR back when internet users could all be trusted.

However, the spammers discovered that the From: (return-path) could be easily forged and now routinely forge the return path with addresses from their list. The result is that if the receiving mail server accepts email and then sends NDRs, all those bogus addresses the spam is addressed to are rejected and the rejection notices are sent to another address on the spammer's list - often a real email address. Now, someone who has been getting spam, not only gets spam but also all the spam that has been accepted and a NDR sent because it wasn't deliverable.

So, the term "unsolicited bounce" or "misdirected bounce" refers to a bounce that is sent to an email address that did not send the email in the first place.

These 'unsolicited or misdirected bounces' are just as annoying as spam and, sometimes, worse than spam. Innocent domain owners are shocked and angered to wake up one morning to find hundreds or even thousands of NDRs that look as though the spam came from their domain. Aside from being really upset that their name is associated with spam, it may be a technical nightmare to keep the NDRs from overwhelming their email system.

If the reason your IP address was added to the spamcop blocklist is because of spamtraps, then 'misdirected bounces' is often the culprit. Spam trap addresses have never been used to send email. The only way that a spammer could have put it on a list is by using a spider to collect it from a website. Therefore, there is no reason a mail server should be sending any email to that address and if it does, then it is either spam or an email bounce generated after acceptance.

Question: How do I prevent my mail server from sending "unsolicited bounces"?

* Configure your mail server to only generate bounces to local recipients. Using the above example, the mail server for "to.com" should only generate new emails to users who have sent email from addresses that are local to "to.com".
* Configure your mail server to reject messages at the SMTP session if they are addressed to invalid recipients. By rejecting the message at the SMTP session, any "bounces" will be sent by other mail servers involved in the transfer (ideally a server local to the sender, if indeed the sender is not a spammer). Sadly, it is not always possible to configure all mail programs to behave in these ways. But even AOL changed their mail server's behavior back in the days when this problem first began, because of how many people were getting "misdirected bounces".

For more info on how to configure your mail server to not generate misdirected bounces, see the SpamCop FAQ entry at http://spamcop.net/fom-serve/cache/329.html#bounces

That's a start on the link if a server admin needs more information on what a misdirected bounce is after reading the Why Am I Blocked FAQ.

Miss Betsy

Let's continue the adaptation of this content on the Wiki!

Wikis do a great job of showing what has been changed by each person and we can see the motivation for the changes, revert them, discuss them, etc. It's a waste of our time to do this in a forum program, IMO. I can't easily see, for example, which parts you modified or added.

Later this weekend I'll start the page on the Wiki, now that I have access (I only need to find some time).

It's true that the link in the SpamCop report sent on a misdirected bounce is not clear enough (the SpamCop FAQ should be developed more for this kind of thing). Miss Betsy, are you saying there's no way to update the SpamCop FAQ from info that has been "matured" eventually on the Wiki?