DynDNS Won't Deliver NDRs

["Larry Seltzer" <Larry () larryseltzer com>]

Everyone please brace yourselves: It seems that spammers and malware
authors have actually taken to abusing the NDR mechanism. Can you
imagine?

The only real question I have here is that they say the value of NDRs is
nil. Not the first time I've heard this. Perhaps the RFC should change?

Larry Seltzer
eWEEK.com Security Center Editor
http://security.eweek.com/
http://blogs.eweek.com/cheap_hack/
Contributing Editor, PC Magazine
larry.seltzer () ziffdavisenterprise com

-----Original Message-----
From: DynDNS Lists [mailto:automailer () dyndns com] 
Sent: Friday, August 24, 2007 8:09 AM
To: Larry Seltzer
Subject: [DynDNS Newsletters] Issue 8: MailHop and NDRs

View at: http://www.dyndns.com/news/newsletters/08.html

Dynamic Network Services, Incorporated has come to a difficult decision
regarding the handling of locally-generated non-delivery reports (NDR),
also known as "undeliverable mail" or "bounce" messages. DynDNS will no
longer deliver locally-generated NDRs from any MailHop systems. To learn
how this may affect your MailHop service, please read below. Overall,
for normal mail handling, this change will have little effect to our
customers.

In the beginnings of the Internet and early e-mail (RFC822) systems,
message delivery was not nearly as reliable as it is today. Therefore,
when a mail server could not successfully deliver a message to a user,
it would generate an NDR, or a "bounce message" back to the original
sender, indicating that the message they had sent could not be
delivered. So, if our support team (support () dyndns com) sent an e-mail
to a customer (say
bob () example com) and the example.com mail server couldn't deliver the
message to Bob, the example.com mail server would generate a message
back to support () dyndns com, informing our support team that the message
could not be delivered. Since mail delivery was less reliable than it is
today, these information notices were useful, and frequent.

However, due to extreme abuse of this mechanism, we have explicitly
decided to no longer generate these messages on our MailHop systems.
This behavior goes against RFC 2821 Section 3.7. Specifically:

If an SMTP server has accepted the task of relaying the mail and later
finds that the destination is incorrect or that the mail cannot be
delivered for some other reason, then it MUST construct an
"undeliverable mail" notification message and send it to the originator
of the undeliverable mail (as indicated by the reverse-path).
It is through our operational experience that we believe that the
exploitation of this behavior has begun to far exceed its original
informational purposes. Specifically, spammers and other
Internet-abusers are using this behavior to distribute spam, malware,
and to otherwise cause troubles for e-mail systems It has become common
for spammers to forge originating e-mail addresses and to then send
large spam runs against different servers. When this happens, DynDNS
sometimes receives these messages, which cannot be delivered or worse,
get bounced back to the original forged sender, who now gets the spam in
his or her inbox (a.k.a. spam blow back).

We simply feel that this is not the right thing to do.

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. This is why no MailHop
system will ever generate a local bounce message ever again. This change
will help to cut down on the amount of unwanted e-mail that we are
generating to our customers and third-parties that interact with the
MailHop service.

For background, MailHop is a collection of services that process e-mail
with spam tagging, spam filtering, virus filtering, and DNS-based
blacklist filtering. We offer several different flavors of delivery
options: MailHop Backup MX, MailHop Relay, and MailHop Forward.

The MailHop Backup MX service is designed for customers who wish to
protect themselves from an outage of their own primary mail server. In
the event of a primary mail server failure, the Backup MX servers will
automatically queue your domain's e-mail for later delivery. Many times,
secondary MXes are exploited as they typically do not implement the same
levels of recipient verification as primary MXes do. This furthers the
"spam blow back" problem, because spammers will relay their outbound
messages to secondary MXes, which do no recipient verification, in order
to the get mail on queue. Once the secondary MX tries to the deliver the
mail to the primary MX, bounces are generated and "spam blow back"
occurs. DynDNS attempts to prevent this problem from happening by using
SMTP call ahead to our user's Primary MXes for the sake of recipient
verification. This helps to prevent this type of spamming, but only if
the user's Primary MX is up. When the user's Primary MX is down, we
queue all mail we get for later delivery, just as we should. DynDNS is
currently working on more elegant solutions to prevent this from
occurring.

The MailHop Relay service is used as a primary mail exchanger so that we
accept your mail, queue it if necessary, and send it off to a different
mail server, possibly on a different port. Since the eventual
destination is almost always up, we do recipient verification to see if
the destination mail server will allow that message to be delivered. We
do that before we accept the incoming message, which prevents later
cases of "spam blow back".

MailHop Forward is mostly immune to this problem. This service allows us
to accept and process mail for a domain and forward mail onto already
existing email addresses (Forward on domain.com would allow you to have
joe () domain com forward to joe () hotmail com or another address). Since we
have the real accept/deny list and real recipients, this service is
mostly immune from this problem.

Dynamic Network Services faithfully follows most Internet Standards set
forth by various standards bodies such as the Internet Engineering Task
Force (IETF). However, when individuals decide to break the rules (such
as spammers, in this case), the open nature of the Internet allows us to
make changes as needed to ensure the stability of the services that we
provide. With the Internet's roots being deep in open standards, such as
the DNS standard known as RFC1035 and the e-mail standard known as
RFC822, the responsibility lies on everyone to adhere to the rules.
However, the extreme damage being caused by spammers today have forced
us to, and not lightly, take the rulemaking on this matter into our own
hands.

Overall, for normal mail handling, this change will have little effect
to our customers. If anything, we expect our MailHop Backup MX and
MailHop Relay customers to experience faster queue delivery times, with
less NDRs and "spam blow back" in their inboxes. While we have watched
some providers silently cease the sending of NDRs, we feel that this
tough decision to make a change is one we wanted our users to know
about, as we feel with all changes that we make.

As always, your comments on the subject are greatly welcomed.
Your friends, at Dynamic Network Services Incorporated


### DynDNS Newsletters Mailing List Information ### You are receiving
this message because you subscribed to DynDNS'
Newsletters Mailing List. To unsubscribe, please see our mailing list
management page at
https://www.dyndns.com/account/settings/mailinglist.html. If you have
questions regarding this Mailing List, please contact our Support
Department, support () dyndns com.

Dynamic Network Services, Inc.
1230 Elm St. 
5th Floor Manchester NH 03101
http://www.dyndns.com/

_______________________________________________
Fun and Misc security discussion for OT posts.
https://linuxbox.org/cgi-bin/mailman/listinfo/funsec
Note: funsec is a public and open mailing list.