DynDNS Drops Non-Delivery Reports 195
jetkins writes "In an email to subscribers, DynDNS announced that they will no longer deliver locally generated non-delivery reports (NDRs) from any MailHop systems. MailHop is a multi-faceted service offering in- and outbound relay services, spam and virus filtering, and store-and-forward buffering. DynDNS makes it clear that they are aware that this goes against RFC 2821 Section 3.7, but explains that in their opinion the increase in spam volume, and the use of NDRs as a spam vector, means that the value of NDRs is now far outweighed by their potential for harm. (DynDNS also points to the far greater reliability of email systems now than when the RFC was approved.) The company notes that other ISPs have quietly dropped RFC 2821-compliant NDRs. Will their public move start a flood (mutiny) of ISPs following suit? Should they have made efforts to have the standard changed instead of defying it?"
What I'd like to see... (Score:2, Interesting)
RFC-Ignorant.org (Score:5, Interesting)
Stupid bastards.
Turn off original message in the bounce??? (Score:3, Interesting)
This is how it goes on all our mail servers. All bounced messages have the original content stripped off. You get the error message with the reason the message bounced and that's it.
NDR are still usefull. There is PLENTY of mail servers not configured properly or messed up on the Net, even from big ISPs. Calling the current system as a whole, reliable, is a joke.
Problem is legitimate, solution is not (Score:2, Interesting)
First, by their own admission this is only a serious problem for what they call their MailHop Backup MX service. Their other services, MailHop relay and forward are "mostly immune" to DSN issues.
The reason for this is simple: With MailHop Backup MX they have no way to validate addresses so they end up accepting a ton of crap to invalid addresses that end up bouncing later when they relay it on. With the other services they can validate addresses and generate a "5yz recipient invalid" sort of error right there in the SMTP session - no need for them to generate a DSN.
So, if the problem is that they don't have sufficient recipient information in the one case, why not solve it by making that information available? One way this could be done is to have the primary MX publish their list of valid addresses using DNS protocols. A zone transfer could then be used to copy the information over so it is available when it is needed. DNS update mechamisms will keep the information reasonably current. (Of course they cannot assume it is current but they can handle that by issuing a "4yz" temporary error instead of a "5yz" permanent one for unknown addresses. Various issues such as needing to support subdomains or subaddresses can probably be dealt with by using NAPTR records. Obviously this whole thing has to be secured and there are various issues with spoofing, but none of these issues seem insurmountable.
Although I think a DNS-based solution could work, I'm really only using it as example. A different mechanism might be more appropriate. But regardless of the mechanism used, what's missing is the set of standards for how different organizations release and consume this sort of information. Without those their customers don't know how to publish the information and even if they did so a backup MX service provider cannot possibly afford to build a custom address import facility for every customer.
It really is past time that people who have such issues stop going their own way and break things when they could be working with others to actually solve the problem. I've brought this issue up in the IETF once or twice and not seen enough interest to pursue it. That might change if folks like DynDNS would get involved.
Re:Finally, a service provider with a clue... (Score:5, Interesting)
Bunk. Even if it was true, it's still no excuse for ignoring your responsibilities.
I run the mail servers for several domains, and brute-force attacks just don't happen. It's fairly obvious why, if you think about it. Dictionary attacks against common names are possible, but I've not seen evidence to suggest that's happening.
Firstly, I want to get back to "responsibilities". By this I mean that anyone who's connected to the internet has a basic responsibility to make at least a good-faith attempt to prevent their system being used against other people. This goes doubly for people who intentionally run publically accessible servers (e.g. mail servers and web servers). You should treat any mail system which indiscriminately generates NDRs the same way you'd treat an open relay, because that's effectively what it is. You are deliberately making a server available which will accept mail from anyone on the internet, and send it to anyone else on the internet*. This is reckless irresponsibility.
* - most NDR messages include at least part of the original message's text; at the very least, the subject line. So a system which generates backscatter does in fact carry some payload chosen by an anonymous third party.
Even if brute-force attacks on your mail server's address list do occur, there are ways to mitigate the effects of it that don't turn your system into a spam engine.
Having a look through the last 48 days logs on one of my servers, there's 2,308 addresses which were rejected because they're non-existent. The vast majority are either formerly valid addresses (i.e. of people who used to work here), or slightly mangled versions of valid addresses (presumably badly parsed). Particularly common are things starting with "3D" (presumably parsed from quoted-printable data which contains =3D) or people's surnames (smith@example.com) -- our email addresses are in the format firstname.lastname@example.com, and it would appear that some harvesters consider periods before the @ to be invalid.
The second part highlights why brute-force is impractical: the namespace before the @ is absolutely massive, and only a tiny fraction will be valid addresses. If you have no idea what format email addresses in the target domain take, you have no choice but to try everything, and that will take far longer than a week. Add to this the proliferation of very small domains with only a handful of email addresses (i.e. personal domains, promotional domains). Even with a vast botnet, trying to harvest addresses by brute force against a mail server is so horribly inefficient as to not be worthwhile. There's much easier ways to harvest addresses.
Then there's technical issues with that kind of harvesting. First, any reasonable mail server will start responding slower to a client which is making repeated errors, before finally shutting them off. This means you have to make lots of connections. Second, brute force or dictionary attacks stick out like a sore thumb versus normal mail traffic, making it trivial to block any IP which is trying to harvest addresses in this manner. The only possible way to do these sorts of attacks would be to use a vast distributed botnet, and even then it's not going to work. It would be easy (and fun) to build a system that watches for such attacks and blacklists any IP involved. Anyone harvesting in this way would then be betraying the IPs of most of their bots during the harvest! Then there's lots of clever things one can do: once you have a known harvester, start okaying its invalid addresses and add them to your list of spamtraps. Not only is the spammer not collecting any valid addresses, but you're poisoning their address list!
Brute-force attacks are too easy to detect, and too easy to use against the attacker. There's much, much easier and more efficient ways to harvest email addresses. Possibly it could be used if you're targeting a specific company or domain and can do some research into their configuration, but even then there
Re:Finally, a service provider with a clue... (Score:3, Interesting)