--Nico Kadel-Garcia <nkadel(_at_)merl(_dot_)com> wrote:
Well, yes. My concern is that we avoid *insisting* on either a valid ptr,
or that a PTR match an A record that in turn matches the PTR.
Well... as you point out, there are conflicting concerns here.
There is a
potential benefit in blocking forgeries that fake PTR records to point to
a PTR permitted hostname and then lie about what their hostname is.
Yes, this is exactly the problem that FCrDNS (forward confirmed reverse
DNS) is designed to avoid. We don't trust spammers to provide correct
reverse DNS... that is not enough to verify an association with the domain
in question.
That
way lies a nasty, nasty little verification cycle that is inappropriate to
insist be valid. Forward A records matching the PTR records are *not*
required for valid DNS, and should not be required for SPF.
This seems to be conflicting. I'm not sure why it's inappropriate. I
don't think SPF is the first in this area... I already refuse SMTP
connections (at home and at work) for servers that have missing, incorrect,
or not-confirmed rDNS entries.
Anyway, since the use of ptr: mechanism is optional anyway, I think it's
better to have a strict confirmation on the mechanism than to water it down
for everybody. The risk is that it will be less valuable to certain
domains, who don't publish PTR records in a standard way, or don't have
control over their rDNS anyway. I would rather accept that risk. For the
larger sites that *really* need ptr:, having reverse DNS work properly
shouldn't be an issue... but if the mechanism is watered down so as to be
easily forged, those who need it most won't use it, *everyone* will be
forced to drop ptr: and go with ip4:.
In other words, in my opinion, the penalty for large sites who need it to
work, and it doesn't, is greater than the penalty for smaller sites that
can't use a strong ptr: confirmation, but might be able to use a weak one,
they can usually just use ip4: instead.
--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>