OT: Be sure your rDNS is in place...

[John Esak]

A few weeks back I found I couldn't get mail directly to bill at celestial.com.
He told me that it was because I didn't have my rDNS setup correctly (or at
all). I was under the mistaken impression that because we buy a managed
router from AT&T that this service would have correctly set up our rDNS for
us when we gave them the domain we wanted it attached to... no such luck. It
says they will do this in their contract, but they didn't! So for about two
and half years I've been running and periodically getting (but really very
rarely) email sent back because the reverse DNS was not there. I kind of
ignored them... but like Bill, most ISP's are implementing this method of
rejecting spam. They seem to all have started doing a few weeks to a couple
months ago. I just offer this note from our provider (Rapidsite/Verio) just
to let everyone on the list know it may happen to you too, if you have not
taken care of this. What was not so important a short while ago is now very
important.

John Esak


-----Original Message-----
From: owner-rsdealers-broadcast at mail.rapidsite.net
[mailto:owner-rsdealers-broadcast at mail.rapidsite.net]On Behalf Of Steve
Rogers
Sent: Friday, June 25, 2004 6:08 PM
To: rsdealers-broadcast at rapidsite.net
Subject: [rsdealers-broadcast] Update regarding Reverse Lookups


Dear RapidSite Resellers:

The RapidSite Management and Support Teams have received some very useful
and informative feedback regarding the Jun 18th, 2004 implementation of
reverse Domain Name Service (rDNS) checking of all connecting mail servers.
We appreciate and thank you for all your feedback and patience thus far.

In reviewing all of the feedback, it is apparent that some of our Resellers
have been impacted in a negative way by the recent changes.  At the same
time, others have applauded the changes that were made.  Due to the mixed
reaction, we feel it is necessary to provide each of our Resellers with
additional information that we hope will address any outstanding concerns.

First, we would like to reiterate our commitment to fight spam.  We would
also like to outline the spam filtering mechanisms we currently have in
place as a whole.  RapidSite currently utilizes the following:

.	Open Relay Database:  Each remote mail server connecting to a
RapidSite mail server is checked to see if the mail server making the
connection is open for anyone to send email through without authentication.
If the connecting mail server is found to be exploitable, thus an open
relay, a block is put in place until such time the problem is corrected.
This database and the systems in place to check for open relays is
technology that was created by RapidSite.  As of June 24th, 2004, over
108,000 mail servers are listed in this database, with slightly over 4,000
that have been fixed.  On average, 20-50 new open relays are blocked each
day.  This measure greatly cuts down on the amount of spam that would
otherwise be sent to our Resellers and consequently to their customers.
.	Database of Known Spam Sources:  RapidSite also utilizes proprietary
technology that denies connections from known sources of spam and spam
gangs.  This database contains single IP addresses, IP address subnets,
email addresses, domain names and other machine names that have been
identified as sources of spam not only to the RapidSite systems, but also to
the Internet as a whole.  Millions of entries exist in this database.
.	SORBS DUHL:  The DUHL (Dynamic User Host List) is a third party
database maintained by sorbs.net.  This database contains IP addresses that
have been confirmed as being assigned to Internet Access users in a dynamic
fashion, meaning the IP addresses are not static assignments.  This is
typically the method of IP assignments for dial-up, DSL, ADSL, and Cable
Internet Access clients.  Such IP addresses are a major source of spam today
because spammers have found ways to take over PC's using these connections.
Various Trojans and other recent virus outbreaks have been written to
exploit PC users' security weaknesses and use these IP addresses for spam,
in most cases without the knowledge of the end user or the ISP.  RapidSite
does not condone running any type of SMTP engine or mail server on
dynamically assigned IP addresses and in many cases, doing so is a violation
of the ISP's Terms of Service.  RapidSite firmly believes that ISPs'
authorized SMTP relays should be used at all times.  If any IP address
listed in the DUHL attempts a connection to the RapidSite mail servers, that
connection attempt will be rejected.
.	rDNS Checking (PTR Records):  On June 18th, 2004, RapidSite
implemented a further measure to combat the spam problem called rDNS check.
All IP addresses that attempt a connection to the RapidSite mail servers
will be checked for a valid PTR record.  If a PTR record does not exist, the
connection will be denied.  A large percentage of the mail servers without
proper PTR records are also sources of spam and viruses.

With regard to the rDNS implementation, we do realize that this was done
quickly and with no advanced notice to our Resellers.  The lack of advanced
notice was not something that RapidSite had in mind; however, the density of
the incoming spam problem from such IP addresses called for an immediate
reaction that precluded RapidSite from an advanced advisory.  We had to take
action immediately to help stop the flow of spam causing prolonged incoming
and outgoing email delays and mail server performance degradation. We
certainly did not mean to put any of our Resellers in a difficult position
with their end users or other clients.

We would also like to outline why RapidSite chose the rDNS implementation
rather than some other method.  As mentioned above, a great deal of spam and
viruses originate from IP addresses with no PTR records.  In addition to
this, any IP address without a proper PTR record is poor practice for any
ISP.  Many large providers today will not accept connections for IP
addresses without a PTR record.  AOL is a perfect example:

http://postmaster.info.aol.com/guidelines/standards.html

We firmly believe that the spam filtering is there to the benefit of our
Resellers, their end users and to ensure the reliability of the RapidSite
mail servers.  Our future spam filtering enhancements, which are underway,
will follow the same path.

In light of the impact to some Resellers, we have to roll back the
implementation of the rDNS check, effective immediately, until July12th,
2004.  However, the roll back of this feature is conditional based on the
following:

.	The rDNS check will be turned back on July 12th, 2004.  A future
notice to all of our Resellers will be sent as a final reminder of this
change.
.	If degradation of the mail systems occur prior to July 12th, 2004,
it is possible that RapidSite may need to implement this sooner than it
might have been expected.
.	We kindly ask that each of your end users and other clients be made
aware of the upcoming changes.  If any of your clients will be affected,
correctly defining a PTR record for the IP address will solve any mail
connection problems.  It does not matter what PTR record is established as
long as there is a PTR record.  RapidSite is currently not concerned whether
the 'A' record matches the PTR record.
.	When you contact your end users that may be affected, please advise
them that contacting the ISP that maintains their IP address and requesting
a proper PTR record will help ensure their email connection will not be
denied.  If there is a question whether an IP address does have a PTR record
or not, there is a useful tool for checking IP addresses for PTR records at
http://www.dnsstuff.com/tools/ptr.ch?ip=IPaddress.  Please make sure to
replace [IPaddress] with the IP you are checking.
.	RapidSite intends to research improving the error message returned
to the originating SMTP server as to provide more clarification of the
problem and where to find assistance.

We thank you again for your feedback and your continued support as we work
hard to reduce spam.

Kind Regards,

RapidSite Management and Support Teams