Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
Spam The Internet IT

DynDNS Drops Non-Delivery Reports 195

Posted by kdawson
from the one-less-spam-vector dept.
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?"
This discussion has been archived. No new comments can be posted.

DynDNS Drops Non-Delivery Reports

Comments Filter:
  • by Eggplant62 (120514) on Friday August 24, 2007 @03:04PM (#20347569)
    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.
    • by jetkins (1049838) on Friday August 24, 2007 @03:55PM (#20348089)
      A large proportion of Joe Jobs are made possible by lame endpoint SMTP servers which accept incoming mail, close the connection, then check to see if the recipient is valid, and generate an NDR to the address specified in the headers, which are too easily forged.

      A properly-configured endpoint server should check addressee validity during the SMTP exchange, and reject the transfer before it even gets into the system, so the spammer's attempt goes nowhere and "Joe" doesn't get an unwarranted NDR.

      Of course that doesn't help proxy providers like DynDNS, unless they have some way of authenticating their clients' valid addresses in real time via a direct connection or regular updates.

      • Re: (Score:2, Insightful)

        by bvimo (780026)
        Isn't it time we changed something. Amended or created a new RFC, or design mail servers that don't talk to poorly implemented servers.

        /. commentators have spouted enough hot air about Joe Jobs, Non Delivery Receipts etc, we should stand up and do something.
        • Re: (Score:3, Insightful)

          by morcego (260031)

          Isn't it time we changed something. Amended or created a new RFC, or design mail servers that don't talk to poorly implemented servers.


          "If you think you can create a foolproof system, you are one of the fools" - No idea who I'm misquoting.
    • Re: (Score:3, Informative)

      by r3g3x (1147243)

      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

      Ignoring a problem isn't the same as fixing it... NDRs serve a useful purpose assuming the original message was actually useful. The problem isn't sending out NDRs. The problem is sending an NDR in response to spam!

      I've had to deal with the whole joe-job+NDR+DDOS scenario on several occasions... I have found that 65~80% of th

      • Well, let's see. The friend consults me for help on mail problems. He says that the customer won't accept changes in his system to something more reliable and easier to configure, and since he's paying the bills and won't foot for the changes necessary, it sounds like we're living in la-la land already, so an easy solution isn't going to be easy.

        I'm certain you've seen the syndrome: Speak to the business owner and his management team about the problem in easy-to-understand terms, and their eyes glaze over
    • Re: (Score:3, Interesting)

      by Warbothong (905464)
      Just as an issue to note, I sent somebody a relatively important email recently from my Gmail account (accessed using Evolution via POP3 and SMTP). Around a week later I was at someone else's house and couldn't be bothered set my laptop up with their wireless system (their network is encumbered by encryption algorithms) so I used Google's webmail system to check my email. Sitting in the 'Spam' folder was a failed delivery notice from the important email I'd sent earlier (turns out the address I had used had
  • 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.
    • by AuMatar (183847) on Friday August 24, 2007 @03:13PM (#20347675)
      And kill mailing lists. Not all mass mails are spam.
      • Re: (Score:3, Insightful)

        by Chyeld (713439)
        as well as providing a fairly simple manner of performing DOS against a domain, simply spoof your way into seeming to be their mail server and slam in the garbage.
        • by profplump (309017)
          That's a non-trivial attack though -- it's not as though you can send mail with uni-directional traffic.

          In order to spoof a remote IP address you'd have to basically have to share a wire someplace between the mail server and your spoofing target, or exploit some secondary flaw on a router/host along that same path. It could be done, but there are easier ways to DoS, and most of those ways are effective beyond the single-host-to-single-mailhost-for-mail-service-on ly scope that is targeted with the attack y
          • by quanticle (843097)

            That's a non-trivial attack though -- it's not as though you can send mail with uni-directional traffic.

            You don't have to send mail with unidirectional traffic. You just have to make sure that the traffic doesn't point back to you. In other words, if you send mail from a botnet, you're still free and clear as long as you don't use too much of your botnet at once.

            • by profplump (309017)
              That doesn't create a DoS for anyone other than your botnet, which effectively *is* you if you're using the botnet to do things on your behalf. And somehow I don't think "DoS with the scope of a single mail host" is the biggest concern of someone who's box has become part of a botnet.

              I'm not suggesting you couldn't get some box other than your own desktop blocked, or that blocking by IP would be effective at stopping spam. I was just refuting the original statement that you could use IP-scoped blocking in r
    • This scheme would be useless against a distributed botnet attack.
    • 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 ...
  • RFC-Ignorant.org (Score:5, Interesting)

    by nagora (177841) on Friday August 24, 2007 @03:06PM (#20347591)
    I did this some time ago for the same reasons and the wankers at RFC-Ignorant.org put my home email server on their blacklist. The twats argued with me that NDRs are such a vital part of email that any amount of spam was a price worth paying for maybe one NDR a year.

    Stupid bastards.

    • Re: (Score:3, Insightful)

      by Anonymous Coward
      What's needed is for servers to start determining immediately whether they can deliver the mail or not and respond to the sender with an appropriate error code if not, instead of sitting on it for a few hours and then creating a bounce message. This can even work over multiple hops if the sending server isn't an open relay, the destination server replies to your ISP's mailserver with "550 Cant send shit captain!", and leave it up to your ISP to decide to retry, generate a bounce to you (which it should hav
    • Re: (Score:3, Insightful)

      by Jeff DeMaagd (2015)
      I don't see the point in dogmatically upholding a rule for its own sake. If a rule doesn't always make sense, then change it. An RFC for RFC's sake doesn't do us any good unless the principles in it are still a good idea. Having said that, I think RFCs in general a bit baffling, harder to comprehend then legislation.
      • by Applekid (993327)

        If a rule doesn't always make sense, then change it.
        So I wonder, why DynDNS and the others are just doing it without going through the effort of having it changed?

        It's easier to get forgiveness than permission, I suppose.
    • by fm6 (162816)
      You're an evil person! I'll bet your whois record doesn't even have your correct email and phone number!
    • Re: (Score:3, Informative)

      by flabbergasted (518911)

      Why are you accepting a message for a nonexistent user in the first place? As soon as the sending SMTP connection specifies RCPT you should be able to check if it is valid and terminate the connection if it is for a nonexistent user. This can all be done before the DATA command is issued. Why waste cycles virus scanning, spam screening and bouncing a message for a user you don't even have? You're not just RFC ignorant, you're ignorant of how to properly run a mail server!

      Note that the method above get

      • Re: (Score:3, Insightful)

        by plague3106 (71849)
        That's a great way to determine VALID accounts to spam.
        • That's a great way to determine VALID accounts to spam.

          Possibly, but it does prevent the backflow DOS problem.
          • Re: (Score:2, Informative)

            by mrjackson2000 (733829)
            there are ways to avoid this problem also, or atleast lessen the impact. my server will watch for non existant addresses being tried from a single ip, when a threshhold is hit the server drops the connection, i can then block that ip via tcp.deny or any other method and they cannot try again.
        • by fimbulvetr (598306) on Friday August 24, 2007 @05:00PM (#20348685)

          That's a great way to determine VALID accounts to spam.
          A lot of people bring up this point, but it's only ostensibly helpful anyway. The resources you save from not verifying an address are _quickly_ eaten up by the fact that you're queueing messages for invalid addresses on your domain at oftentimes insane rates. Pretty soon, your lame server is going to start to deliver these zillion+ NDRs and not only ruin the rest of your day for your users by stealing bandwidth and mail server resources, but also for many, many other people on the internet who need to delete the 80+ NDRs you sent them.
        • by khasim (1285) <brandioch.conner@gmail.com> on Friday August 24, 2007 @05:11PM (#20348777)
          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.
        • Re: (Score:3, Insightful)

          by dondelelcaro (81997)

          That's a great way to determine VALID accounts to spam

          If someone is going to pull off a dictionary attack against the SMTP server, then you just discard connections to them after a specific number of invalid users.

          Almost all mainstream MUAs support this sort of thing now.

          At the end of the day, if you actually accept the message for delivery and later reject it, you should do so silently.

          • >>At the end of the day, if you actually accept the message for delivery and later reject it, you should do so silently

            That works real well when the incoming e-mail is a complaint to sexual harassment anonymous hot line and the sender thinks the e-mail went through, but we silently dropped it due to a mistake on the spelling.

            I hate sending and e-mail and having no idea if it ever went through or not.

            So I setup all my outgoing e-mail to have delivery and read receipts to try and discover lost e-mail.
            • That works real well when the incoming e-mail is a complaint to sexual harassment anonymous hot line and the sender thinks the e-mail went through, but we silently dropped it due to a mistake on the spelling.

              If the incomming e-mail is actually an anonymous complaint then there's no way to actually notify the sender in any event, is there? The best case would be the receiving MTA rejecting it immediately because it was mispelled, but if it doesn't, how do you expect it to talk to the original sender anyway

      • Re: (Score:3, Informative)

        by aaronl (43811)
        If you're a backup mail exchanger, then you must accept mail on behalf of the primary mail server, and relay to it later. You don't necessarily have any way to verify the account as valid at that time. If you don't do a NDR, then the message originator has no way to know that an error occurred when the backup MX tried to relay into the primary.
        • Re: (Score:3, Insightful)

          by gi-tux (309771)
          And this is exactly the case with DynDNS and their MailHop service. They will receive email for many folks that are behind and ISP that blocks all incoming traffic on port 25. Then they will relay it to the server on a different TCP port, such as 52525. So if I were a customer of DynDNS and someone sent me an email but misspelled my username (gitux instead of gi-tux), then a problem is going to happen. DynDNS accepts the email which was intended for me (but the wrong username). DynDNS then forwards the
          • Re: (Score:3, Informative)

            by Menchi (677927)
            There's even a solution for this kind of problem: It's called "recipient callout". The proxy SMTP Server will attempt a fake delivery attempt to the endpoint SMTP server before OKing a recipient. If it succeds, OK it, if it fails, deny it. Sure it costs some resources, but less than a bounce. And if you don't have enough resources to run an email server, don't run an email server.
          • by redelm (54142)
            What ISPs block 25 inbound? What exploit are they trying to prevent? 'dozy boxen aren't running anything on 25. Legit SoHos with static IPs certainly need 25 in.

            Many ISPs block 25 outbound to be good netizens and avoid their lusers'botnets spewing spam. Legit users can get the block lifted.

            • Re: (Score:3, Insightful)

              by TheRaven64 (641858)

              What exploit are they trying to prevent?
              The 'business customer buying a consumer account' exploit. This is more important to a lot of ISPs than a number of other exploits that have no impact on their bottom line.
      • Real mailers do that. Some folks, for odd, unknown reasons, keep using mail systems that refuse to do those things you specified, which started and continue to propagate the problem. Until we can get them to change to real mail server equipment, extreme solutions like ignoring RFCs seems to be the only way to find solace.
    • by megaditto (982598)
      Am I the only one here that likes NDRs? If some important email is not delivered, I would much prefer that a sender is notified about that failure. Wouldn't you?

      Outright NDR ban is just plain stupid, akin to curing headaches with guillotine. If they must do something, why not place a cap and delay on the NDR traffic.

      • Am I the only one here that likes NDRs?


        Yes
      • by nuzak (959558)
        Proper mail servers bounce during the SMTP session. Even AOL has LDAP integration so they can bounce during the SMTP session. If they can do it, anyone can. DynDNS is simply no longer doing accept-and-bounce, which is a GOOD thing. That they're not moving to an architecture that would prevent accept-and-bounce isn't so hot, but considering what they are, I don't see how they could. This makes them one of the few organizations that actually has an excuse.

        I'm not one of the people that shouts how "email
      • Am I the only one here that likes NDRs?

        Probably

        The concept is nice, but I get scores of them every day from ignorant mailservers telling me that the spam that I didn't send, but had my address on it didn't get delivered. I filter them off into a folder, which frankly, I just purge every week or so. I don't have the time to read through them.
        • by megaditto (982598)
          You are being smart about NDRs: they do not work for you, so you filter them out. If another user needs them, they pay attention to them.

          NDR ban sounds like a solution in search of a problem which will hurt legitimate users if this thing catches on.
          • Eh, honestly, When it comes to accepting them from external sources, I don't know anyone they work for anymore. Properly set up systems won't accept email for non-existent addresses, which means the NDR is generated on the sender's SMTP server. Which means that the overwhelming majority of NDRs not generated by the near-end SMTP server are bogus.

            Frankly, this article has me considering the possibility of refusing/blackholing NDRs on my own servers. I'm betting it might drop nuisance mail by as much as 5-10%
    • by dskoll (99328)
      RFC-Ignorant doesn't "blacklist" anyone. It just informs people that such-and-such-domain does not follow a particular part of an RFC.
    • by Ant P. (974313)
      A blacklist for IPs that disobey RFCs? Whoops, there goes 255.255.255.255/0 for ignoring the IPv6 RFC. Whoops, there goes ::/0 for deliberately ignoring the Type 0 header spec in the IPv6 RFC.
      Utterly retarded idea, and an utterly worthless list.
    • by Vancorps (746090)
      My domain was added back in 2002 when it was hosted by an ISP that is now bankrupt. why should I be concerned about being blacklisted by them? Does anybody use them for filtering?
  • Change or Defy (Score:4, Insightful)

    by Astrogen (16643) on Friday August 24, 2007 @03:11PM (#20347639) Homepage
    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?
    • I would find whoever wrote the stupid standard and make sure they are incapable of drafting any more standards in the future.
    • You know, I don't see anyone following this RFC [sunsite.dk]. So, as it stands, it seems these RFCs aren't always adhered to.
    • Re: (Score:2, Insightful)

      by TheSolomon (247633)
      I agree, although refusing to deliver NDR emails is overkill. Sending abbreviated NDRs instead would work just as well, without denying the utility of valid NDRs.

      By "abbreviated," I mean mail servers should look at incoming apparent NDRs, drop most of the message content, and provide summary information instead. So instead of getting a fake NDR with a SPAM payload, you'd get something like "Your message addressed to fakeaddress@someplace.com, with subject beginning 'First three words,' could not be delive
  • SPF? (Score:5, Insightful)

    by Southpaw018 (793465) * on Friday August 24, 2007 @03:12PM (#20347653) Journal
    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.
    • by Sircus (16869)
      If you typo an address, the receiving mail server should be able to reject it during the SMTP conversation. This should result in an NDR for you from the sending mail server.
      • Some places are set with their external servers as dumb as possible... they know nothing about whose accounts are valid or not, so if they ever do get hacked, you don't have all legal addresses available for mailings lists, sales, etc...

        Granted, you can pick up alot from logs, but not all
    • by jchawk (127686)
      If you send to an address at one of my corporate domains that is incorrect you're not getting an NDR.

      Your email will go into a catchall mailbox and it will be forwarded to the appropriate person. Yes this is tedious however 1 missed email could be a missed chances at *TONS* of business. Often times people won't email you again if they get an NDR back.
    • by ajs (35943)

      If SPF were more widely implemented, or required to be implemented, wouldn't this problem be solved?

      Yes.

      Don't send NDRs to domains without SPFs or when SPF fails.

      A fair point.

      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.

      Welcome to 2007. I hate to say it, but this is the state we're in. When I used mailhop, I used it for secondary MX, so I would not really have cared too much about the off chance that when my primary MX was down, you sent mail with typo in the To address. Failure recovery doesn't need to be 100% perfect for me to appreciate having it.

    • 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
    • "If I typo an email address, I damn well better be getting an NDR from the recipient domain,"

      And if your typo matches a real person's email, you won't be getting an NDR. Heck, I've gotten tons of email from people who have sent their stuff to the wrong person - including the new password for someone whose name misses mine by one letter.

      If the mistake originated with you, don't expect someone else to take responsibility for fixing it.

    • by kindbud (90044)
      If SPF were more widely implemented, or required to be implemented, wouldn't this problem be solved?

      No, SPF/Sender-ID are bad ideas, which even their creators don't put much trust into. Don't believe me? Try sending a brand-new newsletter to Hotmail and MSN subscribers. Make sure all your Sender-ID and SPF records are in place and verified with Microsoft's own Sender-ID checker. Make sure all your WHOIS data is current, valid and not obfuscated for privacy. Setup your mail servers on freshly-allocated
    • Re: (Score:3, Insightful)

      by cleverhandle (698917)

      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.

      Which is why you run a real secondary MX that can either do recipient callout or use valid recipient lists in order to reject during SMTP. DynDNS is a che

  • by chef_raekwon (411401) on Friday August 24, 2007 @03:14PM (#20347687) Homepage
    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.
    • by rhizome (115711)
      maybe by defying it, the standards will now be reviewed, and eventually changed.

      And your daily lesson in passive aggression comes to you from chef_raekwon today.

      Not very Wu of him, if you ask me.

  • RFC (Score:2, Funny)

    by networkzombie (921324)
    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.
  • by jchawk (127686) on Friday August 24, 2007 @03:16PM (#20347719) Homepage Journal
    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.
    • 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.

       
    • ...email in it's present state is broken.


      I'm reposting this to make certain that if one point gets made here, this is it.
    • I respectfully disagree.

      E-mail works fine, with the various hacks that have been added on to fight entropy. Dealing with normal spam is no worse than the annoyances of closed networks - you still get spam on facebook etc!

      Compare and contrast e-mail with the alternatives - you get instant messaging, which solves a different problem and *still* sucks, or you place yourself at the mercy of a third party. No thanks.

      If you can't use e-mail chances are you don't:

      Run an well configured server (or pay an insignific
      • Do you have SPF set up? As I understand it, most of the big providers now use SPF when receiving email, and ignore it if the record is present and the sender does not match the allowed list. This should mean that Joe jobs don't work if you have SPF correctly configured.
    • by pkulak (815640)
      I don't know why everyone keeps saying this. Sure, if I apt-get Postfix on my local box it's going to be flooded with spam, but throw SpamAssasin on there, use the spamhause blocklists, and you get just about none. There are only so many servers that should be sending mail. Just block the rest and you're done. Sure that's a bit complicated, but so is all this talk of Email 2.0.
    • I have an answer (Score:3, Insightful)

      by Phroggy (441)
      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 [techweb.com], 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 i
  • by LithiumX (717017) on Friday August 24, 2007 @03:18PM (#20347731)
    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.
    • Re: (Score:3, Insightful)

      by OldeTimeGeek (725417)
      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.

      The process of modifying standards is a bit more complex [rfc-editor.org] than that, but there is a process for change. You just have to become part of it rather than just picking and choosing which standards annoy you the least and then hoping that someone else will fix the ones that don't work the way you think they should.

    • by _anomaly_ (127254)

      Publicly announcing this (non-critical) deviation, and explaining exactly why, is the proper way to go about it.

      I tend to differ...
      What they're doing is making a change to a service that they provide so that their problem is resolved (which they have a right to do IMO).
      It's kind of a move towards an 'ignorance-is-bliss' policy rather than fixing a problem for their customers... after all, if they aren't aware of a spam problem that their customers are experiencing then there isn't a spam problem.
      I'm a f

  • by Anonymous Coward on Friday August 24, 2007 @03:21PM (#20347765)
    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.
    • by Andy_R (114137)
      It's not just a good idea, here in Britain, it's the law too.

      Basically, our spam law says it's illegal to send unsolicited commercial e-mails to private individuals - there's nothing to say that you have to be the author of the spam to fall foul of that law, you are still guilty if you send me an unsolicited commercial e-mail by bouncing it to me from a third party when I'm being joe-jobbed.

      A nicely worded 'please change your settings, or I'll tell the information commissioner to fine you £5,000 per m
    • by Sleepy (4551)
      >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.

      NO. Once a spam MO becomes commonplace, that technique will NEVER go away.
      You seem to be implying that if the "effort" is wasted in vain, then spammers will deprecate their old technique. They won't - they'll just ADD new techniques. The NDR loophole will never die.
  • 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.
  • 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
  • by jani (4530) on Friday August 24, 2007 @03:53PM (#20348065) Homepage

    With this reliabity levels of modern e-mail systems being substantially higher than its past predecessors, the practical needs for this NDR messages are nil. These practical, anti-spam, merits far outweigh the prevailing RFC 2822 technical requirements.


    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.
    • by lamber45 (658956)
      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.)

      If you have a DynDNS account, chances are good that you don't forward all your e-mail to a HotMail [live.com] account. In fact, you might run your own mailserver; in that case, you can make sure that your own server returns whatever bounce messages you feel are appropriate. Even the forwarding service will normally be pointed at RFC-compliant servers, which may c

  • 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.

    T
    • Re: (Score:2, Insightful)

      by Jubal Kessler (7025)

      With MailHop Backup MX they have no way to validate addresses

      Not necessarily. Backup MX services could do address validation if they're given a userlist. Of course, this entails some security concerns (example: why trust a backup service with a userlist?), but that can be figured out satisfactorily (answer: use a backup service you can trust, and engineer a secure solution).

      Further thoughts:

      There is little reason to avoid address validation these days. As for the argument against address validation --

  • 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.

  • NDR's are not evil (Score:5, Insightful)

    by Anonymous Coward on Friday August 24, 2007 @04:12PM (#20348303)
    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.

    • Re: (Score:3, Insightful)

      by profplump (309017)
      Except DynDNS doesn't have local users, so they can't verify directly that messages will be delivered.

      A similar problem occurs when you submit outbound mail to your ISP -- unless it's going to someone else at the same ISP, the local SMTP server can't verify that delivery will succeed. At the ISP level it's still probably reasonable to generate bounce message, at least for local users. That way you don't have to do the final delivery right away, users can still get error messages, and you don't risk sending
  • Then how come people are paying for a Backup MX service?

    • How about: "Email is so reliable these days because anyone running a server worth talking to has a backup MX service"?
      • by kindbud (90044)
        There seems to be a contradiction here. The problem DynDNS is trying to solve stems directly from backup MX that can't verify recipients, which then become spam relays via asynchronous DSNs. But what problem were people trying to solve by using a backup MX that can't read their organizations global address book? Mail will queue on the originating system if the destination can't be reached. If there is a backup MX, this means the recipient organization wants to queue mail destined to themselves on a host
        • Yes, in a double-fault scenario (you sent email to a non-existent account [fault 1] at my domain when my primary MTA was down [fault 2]), you end up with sub-optimal behavior.

          High-availability systems generally accept degraded performance in a double-fault situation. Really, email only needs to rise to the level of "high-availability" (as opposed to "fault-tolerant"), given users' current expectations. If you need anything better than that, users generally rely on "layer 8" (human) acknowledgment (largely b
  • 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 tha
  • POTS (Score:2, Insightful)

    by banished (911141)
    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?

Klein bottle for rent -- inquire within.

Working...