smtp.easydns.com and smtp2.easydns.com now rejecting mail from clients with no reverse lookups or bogus reverse lookups

nospam@example.com (Simon Carr) — Fri, 06 Mar 2009 10:22:16 -0500

Greetings everyone,

Due to a breathtaking number of new compromised PCs hitting our primary and secondary mail hubs, we are now rejecting e-mail from hosts that have no reverse lookup, or a bogus reverse lookup.

This means that if the IP address of your mail server does not have a legitimate reverse "PTR" record, we will reject your mail with a 450 error. This is a soft-bounce, meaning we will not instruct your mail server to discard the mail, rather we ask your mail server to try again later.

This gives everyone lots of time to resolve reverse lookup weirdness.

In the event that your mail server is being rejected by this new method, the best thing to do is to contact your service provider and have them set up a legitimate PTR record for your IP address that has a corresponding forward lookup.

So let's say my mail server is mail.example.com: my IP address is 172.16.1.1.

If I do a "host" command to look up the PTR of 172.16.1.1, and my PTR record comes back as 172-16-1-1.provider.example.com, but then when I do a host on 172-16-1-1.provider.example.com, that record doesn't exist, smtp.easydns.com will reject that mail with a 450 soft-bounce error.

The solution is to set a PTR record on 172.16.1.1 to mail.example.com. Either by doing it on your systems (if you have that access, great!) or by contacting your service provider to have that PTR record set up.

This policy stops two things; 1) Mis-configured or compromised hosts that were never supposed to send mail, but are sending mail, have a harder time sending us mail and 2) Malicious hosts that have fake PTR records like "totally-legit.mail.google.com" are not able to forge authenticity.

This is actually an industry norm; previously we haven't turned this method up because we've had the capacity and tolerance to let it slide in the past, but the landscape of e-mail and SMTP based service has changed to the point where we don't have that luxury anymore.

An example log line is included below;

Mar 6 06:26:08 mymailserver postfix/smtpd[21246]: NOQUEUE: reject: RCPT from unknown[172.16.1.1]: 450 4.7.1 Client host rejected: cannot find your hostname, [172.16.1.1]; from= to= proto=ESMTP helo=

Companies: formulate a coherent management plan for your domains

nospam@example.com (Mark Jeftovic) — Wed, 05 Oct 2005 11:23:37 -0400

We all hear about it from time to time: some large corporation letting a precious domain name drop off the deletion cliff only to have it snagged in the "drop game" seconds after it is released. I watched, stunned, a couple years ago as oracle.net (it was not a client domain) moved through its expiry period, redemption period, then pending delete for 5 days, and then it was gone. Snagged by a domainer and is still being monetized for its traffic.

Every night we get a list of domains that are about to be deleted by the registry for non-renewal, and every night I manually inspect that list to see if anything leaps out at me as something that probably shouldn't be deleting. We have a number of checks and balances in place to avoid this, but there isn't anything we can do about it if our customer has let their contact info go stale and can't get renewal notifications, or if those notifications are going into some corporate blackhole in the wake of a move or re-organization.

So last night two names lept out at me. They were the .net and the .org domains that one of our customers seemed to have let lapse. The customer is large. Trades on the Nasdaq with a multi-billion dollar market-cap large. A name most of us would recognize instantly and somebody whom I thought probably doesn't want to let the .net and .org versions of their name slip into the abyss.

I hastily renewed the names before the registry flushed them and fired off an email to my contact there. Sure enough, they didn't want those names to go and were relieved to have them pulled back from the edge. Now they have to take a look at what happened on their end to let something like this get past them.

Sometime ago we put together Critical Management Steps for Corporate Domain Name Assets and I think this is information we may take for granted here at easyDNS because we're immersed in this industry, but it is a must read for corporate IT departments. Hopefully it's old news for most of them but in some cases it seems not.

easyDNS Blog - Help and Support

smtp.easydns.com and smtp2.easydns.com now rejecting mail from clients with no reverse lookups or bogus reverse lookups

Companies: formulate a coherent management plan for your domains