Slashdot Mirror
DynDNS Drops Non-Delivery Reports
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?"
Stupid bastards.
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
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