eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Im a paying subscriber to several of DynDNSs e-mail services. Today I got a newsletter from them announcing that they will stop generating local NDRs (non-delivery reports) from their services. NDRs, also known as bounce messages, are error messages from mail relay servers back to the message sender saying that the message cannot be delivered.
In one sense this is boring, dog-bites-man stuff. Everyone knows that NDRs are trouble. It wasnt always this way.
Back in the early days when Al Gore invented the Internet, message delivery was far less reliable than it is now. The systems and connections between them were unreliable. Often a connection would be taken offline because, for example, someone needed that phone line to call Mom.
For this reason the standards that defined e-mail on the Internet (RFC 821/822, 2821/2822), created a requirement that a relay server must send a NDR if it experienced a problem delivering a message to a destination.
From RFC2821 section 3.7:
Emphasis is original to the RFC. You MUST send the NDR. But DynDNS wont be doing it anymore, and good for them. They shouldnt, because these days “the originator of the undeliverable mail (as indicated by the reverse-path)” is almost certainly some innocent third party who did not send the e-mail. (Johannes Ullrich of the ISC basically agrees.)
One upshot of this is that DynDNS will not be RFC-compliant, and this they clearly dont like. It bothers them a lot more than it bothers me. Look at where standards have got us with e-mail. Just because theyre “standards” doesnt mean we shouldnt protect ourselves from the consequences of their design flaws.
NDRs have other nefarious uses. Many services stopped sending NDRs years ago because of DHAs (Directory Harvest Attacks), where a spammer attempts to construct a list of accurate addresses in a domain by using a dictionary of names and sending test messages to all of those names in the domain (john@example.com, mary@example.com, etc.). If the spammer gets an NDR back, he knows its not a real address. If he doesnt get an NDR, its a real address.
The downside to turning off NDRs is that customers and other outsiders may get the impression youre ignoring them when in fact they just typed the wrong name. But leave them on and you guarantee that eventually someone can create a highly accurate copy of your directory. They can use this not only for spamming but for targeted attacks that need to look credible, like an e-mail that needs to look like it came from the CFO.
There are actually good. RFC-compliant ways to address bounce abuse. BATV (Bounce Address Tag Validation) is one way to block any bounces that didnt actually come from the users who purportedly sent them. Sadly, BATV has to be implemented in the MTA (mail transfer agent), which DynDNS doesnt generally control, so it wouldnt work for them. (Would it? Doesnt seem to me like it would.)
When even good citizens like DynDNS start going non-compliant in order to do the right thing, its time for the standards people to get off their duffs and do their jobs. The RFC is broken. NDRs are hardly the only thing wrong with SMTP, but once its right to ignore the RFC things can only get worse.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
More from Larry Seltzer