Among the more common questions I get from my users concerns Non-Delivery Reports (NDRs) they receive for messages they didn't send. Some users are understandably upset because many of the subject lines would lead you to question their character.
In addition, I see lots of questions from messaging administrators concerned that their environment is an open relay because either they are receiving a lot of NDRs from outside systems, or their own queues are clogged with NDRs to other SMTP domains.
Recently I posted this response at MSExchange.org to an Exchange administrator searching for a reasonable explanation for the flood of inbound NDRs his users were receiving.
===============
Consider this scenario:
1. I am a "Secret Creator of Unwanted Messages" (a.k.a. SCUM)
2. There is an SMTP domain named company.com
3. The address no.one@company.com does not exist
4. Your SMTP domain is unsuspecting-user.com
5. You have a user with the address someone@unsuspecting-user.com
6. I send out a message addressed from someone@unsuspecting-user.com and to no.one@company.com
The message goes out from my secret lair in a nearby septic tank out to the Internet.
The message then gets delivered to the server at company.com. That server accepts the message, attempts to find a match for no.one@company.com and discovers there is no such address. Being the RFC-compliant system it is, it dutifully creates and sends out an NDR to the sender. The trouble is, it thinks the sender is someone@unsuspecting-user.com and so sends the NDR there.
===============
This isn't to say that we shouldn't watch for signs that our system has been compromised, but more on that later...
Showing posts with label NDR. Show all posts
Showing posts with label NDR. Show all posts
Tuesday, October 23, 2007
Subscribe to:
Comments (Atom)