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.

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

-Justin

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

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.

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.

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?

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 ;)

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).

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

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...

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

Now erase this post