Justin Frankel - main feed

dear people who run mail servers
April 15, 2008

Can you please configure your mail servers to check the reverse-DNS on incoming mail? For example, if an email comes from "soandso@somedomain.com", please, for the love of God, check the MX record for "somedomain.com" and make sure it matches the server trying to deliver you mail?

For some reason people like to spam faking some of our addresses, so we get a bazillion "delivery error" messages. UGH.

11 Comments:

Posted by Scott on Tue 15 Apr 2008 at 15:38 from 76.184.119.x

This is bad advice. I'm sure you already know this, but the MX is the host that receives the mail for a domain. It is not necessarily the outbound SMTP server for that domain. At my company and many others, the tasks of inbound and outbound mail are separated on different servers. If you require mail to be sent from the MX server, you'll be missing a lot of mail.

Posted by Justin on Tue 15 Apr 2008 at 17:09 from 68.193.238.x

OK, how about just checking to make sure the sending host has a valid reverse/forward DNS match? :)

-Justin

Posted by Justin on Tue 15 Apr 2008 at 17:09 from 68.193.238.x

...and perhaps, have that be part of the sending domain?

Posted by Scott on Tue 15 Apr 2008 at 19:47 from 76.184.119.x

The first idea is good. And a good idea.

Having the dns be part of the sending domain won't work. My company has literally hundreds of domains all going through the same relatively small group of servers. The email provided as a part of Google Apps, which lets you send/receive on your own domain, uses google.com hostnames for MX and outbound.

Posted by david harrison on Tue 15 Apr 2008 at 19:55 from 139.130.240.x

We actually ran into a problem when an ISP here in Australia started doing this - bouncing email that was sent from one of our mail servers that didn't have an R-DNS record.

We didn't control the DNS records for the domain in question, and getting them changed was a huge PITA. So customers of this one ISP were basically unable to get mail from us (so they couldn't sign up for our website services, basically, because there was an email validation step).

I have a vague recollection that when we looked into it we found that this behavior wasn't part of the related RFCs - could be wrong there though.

We get an assload of those delivery error messages too, so much so that we've actually stopped OUR servers from sending out those delivery failures - delivering to non-existant/fake addresses our mail servers now just results in those messages getting silently dropped. Not great for users who can't remember our email addresses/make a typo though.

Posted by Justin on Tue 15 Apr 2008 at 21:17 from 68.193.238.x

yeah I realized my second point was not possible after I posted (duh).. and the first most people do check anyway, but it seems people are spamming from valid hosts now.

Perhaps on our mail server, we need to drop incoming "undeliverable" messages that come from servers where the original didn't originate from our mail server (i.e. if the Received field in the copied message doesnt have anything at all from us, then we can drop it)..

thoughts?

Posted by Justin on Fri 18 Apr 2008 at 22:19 from 68.193.238.x

Came up with a pretty good procmail recipe to deal with this, actually.

If the From header contains the requisite postmaster@, Mail Delivery, etc etc,

AND

The body (NOT the headers) contains a Received: line,

AND

The body (NOT the headers) does not contain a Received: line that references your actual outgoing mail server.

..if anybody wants a copy of the recipe I suppose I can post it ;)

Posted by Craig on Mon 21 Apr 2008 at 01:47 from 80.177.87.x

I assume you have valid spf records for the domain? That's done a fair amount to stop my domains getting bounces, mostly since hotmail et al all support it (exchange does too iirc).

Posted by Justin on Mon 21 Apr 2008 at 22:52 from 64.81.54.x

ahh, SPF, how I've not used theee.. that should help, woot. thx.

Posted by Scott on Wed 28 May 2008 at 09:45 from 70.245.118.x

spamdyke works great...intercepts the bad stuff before your smtp server even gets hold of the connection. You can configure it for valid reverse dns checking and all sorts of other basic tests, including specific whitelisting and blacklisting by email, domain, or IP. My inbound spam volume dropped like a rock when I put it in front of qmail...and I was using Spamassassin + ClamAV already...

Posted by Juan P on Thu 05 Jun 2008 at 07:17 from 80.58.205.x

Just to notice that your justinfrankel.com domain has expired !!

Now erase this post

Add comment:

Name:
Human?:	(no or yes, patented anti crap stuff here)
Comment: