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?"
Well, seeing as how a friend and I have a client who's being bombarded by NDRs as a result of a joe-job on the client's domain name, it's good to know that DynDNS is copping a clue. Too bad you can't get the rest of the ISP gang on board that easily and that quickly.
Stupid bastards.
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
While I do believe they should initiate an effort to update the standard, if they view it as a security threat or a spam vector they are entirely right in shutting down the service.
If a RFC said all boxes should have a port that users could telnet into with root access, and people start abusing that would you leave it and wait for the standard to change?
If SPF were more widely implemented, or required to be implemented, wouldn't this problem be solved? Don't send NDRs to domains without SPFs or when SPF fails. NDRs get through and problem solved.
And what DynDNS is doing is simply preventing all people from using their service from knowing whether email is being delivered properly. If I typo an email address, I damn well better be getting an NDR from the recipient domain, because simply having it go into an email black hole and never knowing whether it got there is not an acceptable alternative.
ACs are modded -6. I don't read you, I don't mod you, I don't see you. Don't like it? Don't be a coward.
And kill mailing lists. Not all mass mails are spam.
I still have more fans than freaks. WTF is wrong with you people?
Should they have made efforts to have the standard changed instead of defying it?
maybe by defying it, the standards will now be reviewed, and eventually changed.
We're like rats, in some experiment! -- George Costanza
It's email in general. The whole system is flawed and we've tried repeatedly to duct tape over the problem.
The main problem is a you have a system based on blind trust.
Second trust based duct-tape systems are simply too cumbersome for the average user.
I don't have the answer but I do know that email in it's present state is broken.
Tried and true standards make the net go round, but the most effective enhancements or changes to standards usually don't come from a committee working out best practices - it comes from individuals making hard choices on what to support. If those changes turn out to be beneficial, then they become adopted as new standards.
Going against standards can cause a bit of chaos as well, which is why it's good to avoid deviation - but sometimes a deviation makes sense, and you do it. Publicly announcing this (non-critical) deviation, and explaining exactly why, is the proper way to go about it.
Do not confuse "Freedom of Choice" with "Free Will".
Did I miss something or wouldn't the problem be solved by turning off the content of the original message in the bounce? If you can't see the original content, it removes the incentive for spammers to use that technique.
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.
Excuse me, but due to the vast amount of spam handling, modern e-mail systems are substantially less reliable than they used to be.
If you redirect email for your domain name to Hotmail, chances are good that it will disappear without a trace. (No NDR, not in the spam box either.)
Someone else already mentioned the problem of people typoing email addresses. This is a common problem.
Email can be bounced for other reasons, too, such as a full mailbox, or that there is a relaying mail server (yes, DynDNS, they still exist, and in abundance!) which gives up on delivery after a week of timeouts for the destination host.
And so on.
Someone at DynDNS needs a good whack with the clue bat.
Throwing out the baby with the bath water comes to mind when I read this...
The problem is not with NDRs. The problem is that their servers *accepted* the message that eventually had to be NDR'd in the first place, then after accepting responsibility, decided they didn't want that responsibility, so discarded mail that they promised they would deliver.
If their servers checked validity of local recipients, scanned and filtered the message, etc BEFORE accepting it (via 2xx series SMTP accept response), and instead properly REJECTED it with a 5xx series response, these messages would never be bounced. The NDR mechanism is not at fault - rather, the fact that they can't properly configure their servers to reject the message up front is at fault. If you properly REJECT the messages at the SMTP level instead of accepting the message for delivery, the only thing left to NDR are perfectly valid cases, such as mailbox over quota, etc.
Once you *accept* responsibility to deliver a message (via a 2xx series SMTP response), you MUST deliver it somewhere, else you have shirked your responsibility - either deliver it to it's destination, or bounce it. To do anything else would be to LOSE mail, which is the ultimate sin of any mail server. The key is not to throw out bounce messages, but to minimize or eliminate unnecessary bounces in the first place by rejecting instead.
Note that by properly REJECTING the message, you also effectively defeat most spam bots, since they can't "bounce" the mail that you reject to the "real" local sender.
I always hate it when providers like this take the short cut of *losing* mail intentionally rather than fixing their broken systems to work right.
One caveat to my comments - unfortunately, some mail software is symply not geared toward todays Internet, such that it can do the scanning and filtering of messages realtime fast enough to prevent a sending server from timing out while it's doing this scanning, so they queue the mail to process it for spam, etc later. Using such software is the first mistake most places make, and is the real reason why there are so many NDR's in the first place.
Way to confuse envelope-from, header-from and reply-to.
Besides, my home-brewed Linux-based mail server has a published SPF record, and anyone receiving mail can verify that machine is entitled to generate envelope-from with that domain. The SPF also spells out my relay provider, since my DSL line is in DSL blocklists.
What it really needs, at the least, is for people to stop accepting bogus HELO/EHLO addresses and other unverifiable envelope information. If there isn't even an A record for the HELO address, then 554 the message.
This means mail from many large corporations will be rejected, because they use HELO hostnames that only resolve inside the company.
Yes, the spammer can determine whether it has a valid account. But that means ...
#1. The spammer already HAS the account name and is checking to see if it still works. Defeat this by generously distributing SpamTrap accounts. And accepting email to them. And then opt'ing out of the email that they receive.
#2. The spammer is trying to guess a new name. Good luck with that. Sure, maybe SOMEWHERE there is an email account of "frank@example.com" but good luck finding it. If you want to have some FUN, watch your logs for examples of this. Then setup some of them as SpamTraps. And follow #1 above.
I use both of these approaches. It makes filtering spam VERY easy.
Here's an example of how mailing lists can be useful: I'm into music and bicycles, and I get periodic emails from several online vendors of music and bike gear letting me know what specials they are having, and quite often I see something I like in these emails, so I click a link and go shopping. I opted in to these mailing lists, and they help me find deals I wouldn't otherwise be aware of.
I wouldn't probably think to check a forum for an announcement on a free-shipping sale or a closeout on last year's tires, but if it comes in an email, it gets my attention, and I appreciate that.
My ISP offers spam-filtering, but I have turned it off because too many of these mailing lists I like were getting caught in its trap. So I agree that mailing lists make spam filtering more difficult, but I personally see them as being worth the hassle.
My truck is like a series of tubes.