On Thu, 2004-12-09 at 13:14, Scott Kitterman wrote:
I think all that makes a lot of sense. We ought to do that.
Thanks.
I don't like the opt-out approach either, but I was just trying to be
pragmatic.
Sure, in the sense of "abusers are going to use my SPF record for PRA,
so I better tell them not to". I think that's fine, and I support doing
that, but abusers will, by definition, do whatever they want to
anyway. In the extreme case where EVERYONE publishes PRA-opt-out
records along side their SPF records, I could see SPF record abusers
ignoring the opt-out and just using the SPF record for their PRA checks
anyway.
I'm trying to be pragmatic in the sense of "abusers are going to use my
SPF record for PRA, but I don't want to be blamed for their mistakes,
nor should SPF be blamed for abuses of its data".
Consider these two claims:
"My MUA used your SPF record to authorize/check PRA and your
email keeps getting marked as forged. Fix your SPF record."
"My web browser used your MX record to figure out the IP address
of your website. It doesn't work. Fix your MX record."
I don't see why anyone who was not out to abuse DNS records (or any
standard for that matter) would see these as all that different. That
is
"SPF is to PRA as MX is to HTTP"
and
"SPF is to MAIL FROM as MX is to MTA".
I believe we have seen a couple of cases of e-mails rejected due to PRA
failures against v=spf1 records at the spf-help RT, but it's difficult to be
sure. While we do need to do the standards work you suggest, we also need
to deal with the reality of what's going on.
I view it as being more of a false sense of security. The least
spoofable thing is the source IP, which only the receiving MTA is in a
position to do anything about. Everything else is in the headers, which
are all fudgable by less-than-honest people.
As a side note, I find it odd that some people think that checking SPF
records in the MUA by tracing Received headers is at all better than PRA
_for_the_user_. Email service providers can NOT CHANGE their internal
email routing system without notifying their customers that their MUA
SPF checking configuration might need to be changed (to tell their MUA
what the names of the internal MTAs are and/or how many there are,
and/or how many/which Received headers are "trusted"). This is a
maintenance and customer service nightmare that puts bounces caused by
-all to shame.
I suppose one (stupid) solution would be to publish, in DNS, records
usable by MUAs listing local mail routing configuration so MUAs can
parse mail headers and extract meaningful data to apply PRA checks
against using SPF records. This is stupid because the entire check can
be performed by the border MTA and then no one inside the network needs
to be concerned about it.
Don't forget that one way to avoid Sender-ID PRA failures is to delete your
SPF record. I'd prefer that people pick some other option.
As would I. But I think this may be the goal of some PRA proponents.
But we've covered that in depth.
Andy.