Martin A. Brooks wrote:
> W B Hacker wrote:
>> It is a puzzle to me, Martin, that the <domain>.<tld> you use for your
>> email address & origination purports to be that of a mail
>> handling/filtering service - one that charges a not-insignificant fee, yet.
>>
>
> Try MessageLabs :)
>
>
>> Presuming you have any influence at all over their configuration, why
>> would you want to position yourself as part of the PROBLEM - by
>> suggesting that those who make effective use of rDNS fail/mismatch cease
>> so doing?
>>
>
> By having a perfectly valid reverse DNS record I'm part of the problem? Eh?
>
>
>
>> - instead, why not become part of the SOLUTION - by getting your finger
>> out and entering a PTR RR, ELSE using a smarthost for outbound which
>> DOES have such RR.
>>
>
> They do, that's my entire point.
>
Sorry for the delayed response - been continent-hopping.
- In the OP the rDNS was of the type sometimes referred to as 'generic'
Looking at the headers that accompanied your note of 14 MAR to Phil,
copied to the list:
Your message departed: 10.119.48.100 = an internal IP not expected to
have a public PTR RR
Next traversed: winter.hinterlands.org, which resolves to 82.69.6.203
Unfortunately, 82.69.6.203 reverse-resolves - but not to a 'match', e.g.:
203.6.69.82.in-addr.arpa domain name pointer
82-69-6-203.dsl.in-addr.zen.co.uk.
You may call that a 'valid rDNS', but should not expect it to be *seen
as* 'valid' as far as smtp is concerned because:
a) it doesn't match the domain claiming legitimate use of it, let alone
an mx in said domain - e.g. appears to be a forgery.
b) Exim aside, 'dig' on either winter.hinterlands.org, or
hinterlands.org does not return an actual PTR RR.
And this seems to the 'set' that matters, because the next port of call
- on tahini.csx.cam.ac.uk arrives as:
Received: from 82-69-6-203.dsl.in-addr.zen.co.uk ([82.69.6.203]:60689
helo=winter.hinterlands.org)
Note that Tahini is configured to be more 'generous' than many in
accepting that mismatch at all.
Further - the mx in DNS for your 'antibodymx.net' do not return PTR RR
*either* - nor does the FQDN offered as HELO work as a rFQDN.
Given that *nothing* seems to match, AND that you have been pushing
others to drop, or at least relax, the rules many of us use to at least
award 'demerits' to such traffic, even if not outright block it - you
should expect to be seen as part of the problem, not part of the solution.
I'm not fussed if we ever agree on that. I don't have to be.
But you should at least understand why some sysadmins will no longer
rely solely on an rDNS fail - but have gone ahead and hard-blocked 'all
of the above' (hinterlands.org, antibodymx.org, and zen.co.uk as well as
the associated IP's).
Bill
