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...
Subscribe to:
Post Comments (Atom)
6 comments:
Is there a solution to this problem? I have one account that gets heaps of NDR's daily for emails they have never sent...
Me too Wayne. Any solution for this?
This is an awesome blog, very informative and answers my exchange questions!!!
Thanks
One of the better solutions is to make sure your domain has an SPF record (see openspf.org).
One solution for this type of problem would be for the server at company.com to check for the existance of the "no.one" mailbox during the SMTP conversation This way it can reply 550 - No such user in response to the "RCPT TO: no.one@company.com" command. This way the message is never accepted and company.com is no longer responsible for the NDR message.
In this case, the nasty septic server goes home sad that it's message was never accepted.
I'm not sure if Microsoft Exchange can be configured to do this out of the box, but a really good idea is to have an edge MTA receive these messages and have it configured to perform this lookup in real time. This way even if you get many many requests like this, the Exchange server is never bothered with these requests which are really just a nuisance. Best yet, the edge is on another network so that such an attack doesn't effect the local network.
Peter LeBlond
Product Development Engineer
MxToolBox
It was certainly interesting for me to read the blog. Thanks for it. I like such topics and everything that is connected to this matter. I would like to read more on that blog soon.
Post a Comment