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.
In addition to not providing NDRs, it would be great if the ISP took the following approach: If 5 or more non-deliverable messages to different addresses within the ISP's domain are received within a period of 10 minutes, then the sender's IP address should be blocked for a period of 24 hours. That, I think, would do a small bit to slow down the spam.
<Complete your profile by adding a signature!>
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.
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
Setup the NDR delivery to cc the postmaster. That'll force him to block those emails during the session rather than letting them get through. Let's face it; if you're getting too many NDRs, you are accepting email from illegitimate sources that need to be blocked. It will stop the joe-jobs and allow the legitimate NDRs to continue. I'm gonna build my own RFC 2821, with hookers and blackjack.
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.
I knew some ISPs started doing this in the late 1990s after broken mailing lists sending spam from forged addresses generated floods of NDRs in response, smashing the original forged recipient (often some unbelievable sound address like "someone@everywhere.org"). Original NDRs quoted the whole bounced email, but first that changed, then many went to one-liners, and finally, they started disappearing.
technical writing / development
ideally the server sending the message should generate the NDR, this way network traffic would be reduced and delivery of NDRs quicker. for this to work is neccessary that the receiving server runs a directory search for the recipient and replies with a 5xx message (permanent error) after the sending server issues a "RCPT" command.
sendmail and postfix both do this. don't know about MS exchange or courrier. a default qmail install (without patches) certainly don't. i believe there's a patch to implement this, but it's unofficial.
standard qmail accepts and queues anything you throw at it, then pipes the message to another proccess that runs the dictionary search. the result is that if you suffer a dictionary attack (i.e. a spammer takes a huge list of common names - say, 100.000 - and prefixes them to @yourdomain.com), you end up with a thousands of NDRs on your outbound queue, effectively swaping the server and/or connection.
sendmail and postfix in contrast, issue an error if the recipient doesn't exists, which leaves to the sending server the task of creating the NDR, wich IMHO is the correct thing to do.
i wasted too many time cleaning qmail's queue in a couple of servers i inherited from a previous admin untill i got fed up and replaced it with postfix. life is too short to waste cleaning up after spammers.
What ? Me, worry ?
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.
They absolutely do have a legitimate problem, one that needs to be addressed by appropriate standardization and implementation activities. But unconditionally failing to generate DSNs is not the answer. What they need is a mechanism that eliminates most of the cases where they currently have to generate DSNs.
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.
It has to start with secure DNS. Receiving mail servers have to be able to test that the originating mail server actually represents the domain it says it does.
Deleted
Unilaterally deciding to ignore an RFC (or part of an RFC) just because you don't like it is almost never a good idea. When Microsoft does it, everyone (correctly!) gets up in arms. DynDNS shouldn't get off any easier.
At most, I would agree with a temporary block of NDRs to a particular user or domain if a large joe-job run is recognized. But this should never be made permanent or blanket.
The problem is one of architecture. There is no excuse in the modern world for running a secondary MX server that lacks knowledge about local recipient addresses. While this architecture may have been OK 10 years ago, it no longer is. Just don't run a secondary MX unless you have a way to transfer your account list to the secondary in a way that the secondary can have local knowledge of valid addresses even if the primary is unreachable.
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.
I would find whoever wrote the stupid standard and make sure they are incapable of drafting any more standards in the future.
But I don't think it's a solution. Between softfails, ISP's who block outgoing connections to port 25 (in favor of using their own SMTP servers) and generally low scoring on most spamassassin configurations I've seen I'd consider it helpful (particularly in getting your email OUT) but not a definitive answer.
That said I DO wish more people would use it so that it's overall impact would be increased (as people began to rely on it more). TMDA aside (which has a whole batch of problems, I know) it's my next favorite tool.
Quack, quack.
I've always refered to that as a "phone book attack".
...
After X failed addresses, block the sender.
Except you have to make exceptions for things like gmail and hotmail and other major ISP's and mail delivery services.
Instead of sending and NDR though, I just reject at SMTP time. If the ISP's were a bit smarter, they'd see X rejections (5xx-series) and shut down ALL outbound email from that account.
And I want a pony and a plastic spaceship and
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.
This case involves a backup MX for third parties. So it's rather unusual, and the rule that should apply 99% of the time ("don't accept it unless you know the recipient is valid") is hard to apply. So I would suggest:
- Check the SPF.
- If the SPF is neutral, do some basic spam filtering, e.g. greylisting or RBLs. Probably not content-based unless they have plenty of CPU cycles to burn.
If the SPF or the spam-filter passes the message, accept it. If it ultimately can't be delivered, send an NDR.
If the SPF or the spam-filter reject the message, still accept it and attempt delivery (after all, the end user isn't asking for spam filtering at this point). However, in this case, if it ultimately can't be delivered then discard it.
I reckon that this would keep everyone happy, and wouldn't be hard to implement.
I haven't looked at email as reliable for years, because of all of the games being played with it.
I'm not sure who's worse: the spammers or the anti-spam facists. Sure the spammers aren't doing anyone but themselves a favour, but the anti-spam facists seem to believe that technical tacticts are an effective way to solve a social problem. Unfortunately, they only seem to be making things worse by creating a sort of arms race. So now rather than having 50 unique spams sent once, I get 10 unique spams sent 20 times over -- where each of those 20 tries use a slightly different approach to get through filters. Sure the spammers created the problem, but the actions of the anti-spam facists only made it worse.
Then how come people are paying for a Backup MX service?
Edith Keeler Must Die
TZO Dynamic DNS people did this 3 months ago.
This step might not have been necessary if everyone customized (read: FIXED) their Microsoft Exchange installations, but that's never going to happen.
TZO stated that 80% of outbound relayed mail was DSN from spammer attempts.
With a lot of Exchange installs, even if that server is NOT an "open relay", they WILL send out DSN's for spam relay attempts. NO mail server should send out DSNs for domains that are not their own - just reject it up front. Unfortunately that is not always true.
I'm a sysadmin for a small company (a few hundreds employees) and our mail system just don't need that. We built mail frontends with Qmail, Spamassassin, ClamAV and a few of our own Perl scripts. The way we made it the mails are either refused at the end of the MAIL TO: command (User unknown) or DATA command (Spam, viruses, etc). The valid emails list is fetched regurarly from the enterprise LDAP directory and top offenders (spam ratio too high or too many invalid recipients) are blacklisted at the TCP wrapper level.
:)
Since we refuse mails during the initial connection instead of using an NDR we don't end up spamming all over the world with faked mails. The number of NDR returned by the mail system is very minimal. It is also much more efficient performance-wise and all the software we used is FREE
Oh, great. Now I have to use POTS to make sure my e-mail was received and didn't go into a black hole. Either that, or request a read receipt on every e-mail. The only problem is I never respond to read receipts, so why should I expect anyone else to?
It's that simple people. Set the "Request return receipts" setting to ON (and beg your email client to start handling receipts with a checkmark next to the original message in your Sent Items folder). And use digital signatures. People do not understand how easily email can be faked!
I run the servers for a hosting ISP. We've had NDRs turned off for years. We delete suspected spam without comment. When people ask me what the chances are that a legit message will be silently blocked, I tell them the odds are 1 in 300 and if they talk about how they just came from a hot weekend due to the new cialis prescription they might not get through either. If I'm this cavalier about messages, imagine how I feel about NDRs.
Since about 2004 it's been a terrible war. My servers have 75% of their cpu resources taken up by spam filtering, not useful work.
If you aren't a full-time sysadmin with a real workload of domains, you don't even have the standing to comment on this topic.
Bounce messages that don't contain the original message suck because you can't filter them easily. Normal bounce messages you can check if the original messages contains a rcpt from your mail server or not, and if it doesn't its obviously bogus so drop it. If it does, then its a legit non-deliverable message so you want to deliver it.
Is the author stuck in some sort of weird timewarp? NDRs are a huge source of spam and disabling most NDRs should hardly be concidered optional. In fact any ISP still arbitrarily sending them needs to have their head examined. But don't take my word for it....
The inclusion of your mail server on SPAM related RBLs the constant pitter patter of disk accesses on the servers disk array coupled with the gigabytes of SMTP traffic logged by MRTG might indicate that yes...Its pry about time you too catch a clue and turn off NDRs.
Mail servers as painful as it may be to them need to do as much as checking as humanly possible upfront and only send an NDR if there is a truely exceptional reason such as a disk array catching fire.
Some of the spam to a domain I run came to addresses like this:
pydh
uuja
cmap.ihnc
I've got no idea where these came from. I never used such email addresses anywhere. Oddly, they're used repeatedly; it looks like somebody decided they were valid and then sold them.
Another account had valid addresses "ma" and "ac". I'm quite certain that they couldn't have been harvested, because they were used only in very tightly constrained circumstances. I believe that they were picked randomly. They were replaced by longer email addresses and no spam shows up to those.
And I've seen plenty of emails to "firstname" where that name has never had a valid email address, and it's clear that they're just guessing.
Congress needs to earmark funding for the FBI to prosecute spammers under CAN-SPAM.
Yeah, whiners on Slashdot say CAN-SPAM is horrible, because it legalizes spam. What they forget is that CAN-SPAM only legalizes it under certain rules, which spammers are ignoring because there's no enforcement. According to this article from last year, only 0.27% of all junk mail actually complies with CAN-SPAM, which means the other 99.73% is clearly illegal. On top of that, the 0.27% is deliberately easy to filter out if you choose.
We don't need a new law to make spam illegal; CAN-SPAM already makes it illegal. We just need to start actually prosecuting people who break the law.
Yes, some spam comes from other countries where the FBI has no jurisdiction, but not as much as you might think, and I believe the FBI already has partnership agreements with agencies in several other countries to work together on fighting spam - they're just not doing enough of it.
Why won't this happen without an act of Congress? Because without a direct congressional mandate, the FBI has better things to do with its time and money. I don't blame them, really - raiding meth labs or catching serial killers is certainly important. But fighting spam is important too, and there's no reason the FBI couldn't do both.
So that's the answer. Spam is a social problem, more than it's a technical problem. We can try to fight it with technology, but spammers are fighting back, and they have the huge advantage of not being limited by morals or legality. We can't win with the odds stacked that high in their favor. The only way to win is to throw them all in jail.
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Milter-sender uses a number of techniques:
Some of the SnertSoft milters are free, but the king-pin milter-sender, is a commercial product under a derivative BSDish license. Still, well worth the price.
I wonder why we don't hear more about Internet Mail 2000, where storage is taken by the sender, not the receiver.
__
Men with no respect for life must never be allowed to control the ultimate instruments of death.
GW Bu