Re: More sorbs blacklisting [signed]
On Tue, 20 Jun 2006 18:28:43 +0100, Paul Cupis <paul@cupis.co.uk>
wrote:
>> I understand that checking for the existence of a reverse mapping may be
>> a clever thing, but the reason for forward/reverse matching is not
>> obvious to me: Imagine a user who only has one public IP at his
>> "all-in-one" mail-web-server. His reverse is www.mydomain.tld to make
>> people with traceroute happy, but his mx is mx1.mydomain.tld. To get
>> through your spamfilter, the reverse has to be changed to
>> mx1.mydomain.tld - that looks not nice in the traceroute ...
>Not if the check is that the reverse DNS for the MX has a matching A record.
> MX mx1.example.com
> A mx1.example.com -> 192.168.12.13
> PTR 192.68.12.13 -> www.example.com
> A www.example.com -> 192.168.12.13 ---> VALID
>If the reverse for the MX's IP did not have a matching A record, that
>would be an error and be blocked.
I should clarify what "strict DNS checks (matching forward/reverse)"
means to me. My sendmail rules are:
># Reject improper DNS
>R$* $: $1 $| < $&{client_resolve} >
>R$* $| <TEMP> $#error $@ 5.7.1 $: 550 Mail from unknown host " " $&{client_addr} " " delivery refused
>R$* $| <FAIL> $#error $@ 5.7.1 $: 550 Mail from unknown host " " $&{client_name} " " delivery refused
>R$* $| <FORGED> $#error $@ 5.7.1 $: 550 Mail from improper host " " $&{client_name} " " delivery refused
>R$* $| $* $: $1
>
The <FORGED> line is relevant to forward vs. reverse DNS matching. I
think the way sendmail implements this, Paul's example above will pass
through just fine (untested).
Reply to: