Mail PTR Records

[Matt Kettler]

Peter Farrow wrote:
> Since, with almost 100% accuracy spammers sending to my system use a bad 
> helo, I block this as well, interestingly the fall out from this is zero 
> even though it breaks the rules (it is very effective in stopping spam), 
> real email systems actually get this right, the bigger problem is 
> reverse lookup issues.

Actually, depending on what you do, it might not be against the rules. It's 
perfectly within the rules to 5xx email if the helo doesn't conform to <domain> 
syntax (and note a dotted quad IP does fit within that syntax). See RFC 1123 
section 5.2.5 for gory details.

It's only trying to DNS lookup of the EHLO parameter that's explicitly 
prohibited when used as a reason for reject (but you can do it as an 
informational mechanism).


> Quite reputable companies can't get this right...

There are lots of things several quite reputable companies can't get right.

I've seen numerous examples of not getting things right:

-DSN handling (ie: sending DSNs to the return path, not the from)
-reverse DNS (ie: having a PTR record)
-sane blacklisting (ie: not blanket blacklisting 30 million people at a shot 
because you got 3 spam emails.)
-sane retry interval on 4xx errors. (ie: not trying every 10 seconds)
-Sane retry duration (ie: not giving up after 10 minutes of 4xx errors)
-Retrying at all (ie: not treating 4xx as 5xx)
-sane content filtering (at least one major commercial spam filtering service 
will junk your email if it contains the word blacklist.)
-Generating HELO/EHLO in a valid format (as above)
-Generating HELO/EHLO before MAIL FROM, or at all (yes, there are some that will 
try MAIL FROM before HELLO, then retry with only after it fails. At least one 
major US ISP I used wasn't generating any at all for a 1 month period in the 
last 3 years.).

But I digress...