Mail PTR Records

[Peter Farrow]

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.

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

P.


Matt Kettler wrote:
> Nathan Olson wrote:
>> It looks like require_rdns works at the check_relay level,
>> which is at connection time, so you are correct.  If the
>> connection proceeds to HELO/EHLO, then refusal based on
>> lack of a PTR record is forbidden.
>
> I'd say that even that isn't forbidden. You must not prohibit email 
> based on DNS lookup validation of the HELO/EHLO content (unless the 
> content is syntactically invalid, as this would cause your server to 
> violate RFCs when generating Received: headers quoting it. See RFC 
> 1123 section 5.2.5).
>
> However, AFAIK, there's nothing saying you can't block for other 
> reasons at the end of the HELO/EHLO command. They've only prohibited 
> DNS lookup validation as a reason, not the HELO/EHLO transaction as a 
> point in time.
>
> Ideally you should handle all blocking at the earliest possible stage, 
> as this conserves resources and saves time. But AFAIK, that's a 
> should, not a must.
>
>
>> I was incorrect.