Misdirected bounces

[craigt]

I routinely get various misdirected bounces and report them all as spam. Occasionally I get a response when the misdirecting system receives the SpamCop spam notice; the following is an interaction with what I thought was a particularly clueless sys guy at a U.S. government funded organization [text to obfuscate the organization]:

Received from these guys in response to their spam notice:

You´re reporting the [clueless organization] email server as a source of unsolicited email bounces.

Spammers are forging your identity as the From: header when originating email, and our server responds to this header with a bounce when a spammer sends an email using your identity to a user that doesn´t exist at our organization.

We did not originate the spam, nor can our server determine that you personally were not the client using your forged address.

The spammer appears to be in Japan.

Please do not report messages of these type to SpamCop. It tags an innocent third party as a possible mail abuse source.

We´re responsible for an email communication system that sends automated alerts to all of [some area] disaster management community.

Sent my response to attempt alerting to the misdirected bounce issue:

Sorry but I disagree on who the "innocent" party is in this transaction -- the spammer sent an email into your server. The settings on your server caused it to resend the crap into my system.

Please refer to SpamCop reference on the subject at http://www.spamcop.net/fom-serve/cache/329.html#bounces

Resulting in another response from this guy:

Well, apparently you must not be innocent if you're the destination of Backscatter. Because I have external relays that do spam/anti-virus/other government proprietary actions long before it gets to my exchange server, I don't see why it's that big of an issue. I block 95% of spam at my border.

I thought maybe I could still provoke a positive reaction so I sent one more response:

It's not that big of an issue; all bounces that I receive that didn't result from a message sent from my domain is treated as exactly what it is -- unsolicited and reported as such.

Which met with the following system response:

The following message to <[somebody [at] the org]> was undeliverable.

The reason for the problem:

5.1.0 - Unknown address error 554-'<me[at]spamcop.net>: Sender address

rejected: spam Crusader ignoring RFCs'

I guess he showed me; no more correspondence on any issues!

[rconner]

The reason for the problem:

5.1.0 - Unknown address error 554-'<me[at]spamcop.net>: Sender address

rejected: spam Crusader ignoring RFCs'

I guess he showed me; no more correspondence on any issues!

Ho! spam Crusader! Don't let bin Laden or Ahmadinejad find out that representatives of the U.S. government have been using the C-word!

Obviously you won't be hearing from these guys anymore (unless they start relaying their spam to you again), but for the next occasion I put together a little web page that might be of some use: http://www.rickconner.net/spamweb/notmyaddress.html. It was written more for end-users who try to bounce or respond to spam, so perhaps we need a companion page for clue-deficient admins.

-- rick

[Miss Betsy]

Since the RFC is still on the books, the server admin (a true bureaucrat) is only going by the book.

And, also like many bureaucrats, if one points out that there is a problem, he says that there can't be a problem because of the procedure that is supposed to eliminate that problem.

At least you got a prompt reply! I once, long ago, tried to alert a US government agency that one of their computers was sending a virus. After many tries at finding an abuse address, I finally found something. Three months later I got a reply! (Since I did have a correspondent in that agency, I had emailed him and he contacted his IT department and within a short time, the viruses stopped coming.)

My mother could get the government to correct mistakes, but she was a character similar to Wazoo.

Miss Betsy

[Farelf]

Since the RFC is still on the books, the server admin (a true bureaucrat) is only going by the book. ...

Is it still? I seem to recall the rfc821-2821 series is superseded now? Replacement makes it more obvious that NDNs are issued only in the SMTP session, NOT post-acceptance. In fact I posted something about that - somewhere (even I can't find it now). Anyway, any admin who thinks it's okay to "return" mail to an address in the header hasn't even read 2821. And the Wiki article isn't bad, in my estimation - http://en.wikipedia.org/wiki/Backscatter_(e-mail)

In any event, it's quite clear who's ignoring the rfcs and of course it ain't you craigt - I wonder how that twit admin would explain the ips.backscatterer.org DNSBL? A whole heap of "spam crusaders" outa control, no doubt. Wonder how he'd enjoy being listed there?

"Sender address rejected: spam Crusader ignoring RFCs'" eh? A message to savour, the day will come when its author gets a clue and is deservedly mortified about it. But public humiliation would be good too - "to encourage the others", as Candide was told.

[Wazoo]

My mother could get the government to correct mistakes, but she was a character similar to Wazoo.

My bucket list (things to do before I die) has long included an actual meeting with Miss Betsy so I could give her a great big hug in addition to all the verbal thanks I could muster up. Yet another person now added to that list .. but concerned a bit about the past-tense words used in the above. If taken correctly, my extreme condolences, additions made to my after-life list of folks to try to track down and have a long meeting with.

Is it still? I seem to recall the rfc821-2821 series is superseded now?

RFC-5321 Simple Mail Transfer Protocol

Network Working Group ...................................... J. Klensin

Request for Comments: 5321 ............................. October 2008

Obsoletes: 2821

Updates: 1123

Category: Standards Track

Section 3 contains numerous changes/updates, etc. dealling with things like "no such user" scenarios.

"Sender address rejected: spam Crusader ignoring RFCs'" eh? A message to savour, the day will come when its author gets a clue and is deservedly mortified about it. But public humiliation would be good too - "to encourage the others", as Candide was told.

In general, I love being proved wrong, as that tends to increase my little sphere of knowledge. I suspect that this particular Admin doesn't subscribe to that philosophy <g>

[kmolloy]

The admin is wrong. The RFCs which require such behavior have been superseded by RFC 5321, which says:

Conversely, if a message is rejected because it is found to contain

hostile content (a decision that is outside the scope of an SMTP

server as defined in this document), rejection ("bounce") messages

SHOULD NOT be sent unless the receiving site is confident that those

messages will be usefully delivered.

"Hostile content" includes spam, by definition. If you cannot be confident that an NDR will go to the actual sender, don't send an NDR at all.

[craigt]

Thanks for the references -- I just went and dug up the RFC's and sent this guy my last attempt (from a different email domain):

RFC 5321 Section 6.2 states:

Conversely, if a message is rejected because it is found to contain

hostile content (a decision that is outside the scope of an SMTP

server as defined in this document), rejection ("bounce") messages

SHOULD NOT be sent unless the receiving site is confident that those

messages will be usefully delivered. The preference and default in

these cases is to avoid sending non-delivery messages when the

incoming message is determined to contain hostile content.

RFC 5321 obsoletes RFC 2821 which obsoletes RFC 821.

My last attempt at contacting you about this issue. As you stated your organization provides a needed service so altering your MX behavior may keep your domain out of various block lists that could affect delivery of your emails.

[rconner]

Thanks for the references -- I just went and dug up the RFC's and sent this guy my last attempt (from a different email domain)

Attaboy, hope this makes a more positive impression.

I just got a delay bounce today at work, a couple of seconds after receiving the same spam myself. My own copy was addressed from someone other than me, which suggests that this outfit was popping different from-addresses into each outgoing packet.

The maddening thing was that the bounce message was completely clobbered by MS Exchange -- no way to view its headers or even the raw body. So, I had nothing by way of evidence for a LART. I'm wondering why MS thought that this was a good idea.

-- rick

[Farelf]

...The maddening thing was that the bounce message was completely clobbered by MS Exchange -- no way to view its headers or even the raw body. So, I had nothing by way of evidence for a LART. I'm wondering why MS thought that this was a good idea.

That doesn't sound right Rick - last time I had something like that it turned out someone was relaying through our server. But, with 'straight' backscatter, plenty of others, in many different formats, but with retrievable headers and bodies (sometimes as attachments) for most/all. That was MS Exchange Server 2003 . Can't check now though.