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?"

Finally, a service provider with a clue...

[Eggplant62]

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.

Re:RFC-Ignorant.org

[flabbergasted]

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 gets rid of NDRs for nonexistent users but still provides them for a user over their quota or suffering other delivery problems.

Re:RFC-Ignorant.org

[aaronl]

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:Finally, a service provider with a clue...

[jetkins]

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:Finally, a service provider with a clue...

[r3g3x]

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 this garbage has already been marked as spam by the bouncer! Why in the would would you bounce a message that you _already_ know to be invalid?!?!? All this does is amplify the volume of crap being flung around...

A sanely configured email server should not bounce on spam. Spam should be left to rot in the bottomless pit of /dev/null.

Remember, Its not a turd fight if theres only one monkey :-)

Re:Start at the top, with secure DNS.

[greed]

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.

Re:RFC-Ignorant.org

[mrjackson2000]

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.

Re:RFC-Ignorant.org

[Menchi]

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.