-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of David
MacQuigg
Sent: Monday, May 09, 2005 3:38 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] For SPF council review: NOT RECOMMENDED
At 08:06 AM 5/9/2005 -0500, wayne wrote:
In <x4br7kvagz(_dot_)fsf(_at_)footbone(_dot_)schlitt(_dot_)net> wayne
<wayne(_at_)schlitt(_dot_)net> writes:
In
<Pine(_dot_)LNX(_dot_)4(_dot_)62(_dot_)0505090119450(_dot_)26914(_at_)sokol(_dot_)elan(_dot_)net>
"william(at)elan.net" <william(_at_)elan(_dot_)net> writes:
--
Without explicit approval of record owner, checking other identities
against v=spf1 records is NOT RECOMMENDED, because there are cases
(e.g. Section 9.3) that are known to give incorrect results."
--
I like that. Along with the changes suggested by Julian (and others),
it now reads:
Julian and I talked this over on the #spf IRC channel, and came up
with this paragraph:
Without explicit approval of the record owner, checking other
identities against SPF version 1 records is NOT RECOMMENDED
because there are cases that are known to give incorrect
results. For example, most mailing lists rewrite the "MAIL
FROM" identity (see <xref target="mailing-lists"/>), but
some do not change any other identities in the message. The
scenario described in <xref target="forwarding"/>.1.2 is
another example. Documents that define other identities
should define the method for explicit approval.
As an alternative, we discussed defining an additional-scopes= modifier
to say which scopes, besides the implicit MAIL FROM and HELO scopes,
should be approved by the domain owner. In the end, we decided that
kicking the problem of defining "explicit approval" off on others to
be simpler and less constraining.
Comments welcome.
I like this. Seems like it would also nicely handle
SUBMITTER=<domain-name>.
Or it wouldn't. At this point you're talking about something other than SPF
classic.
Let's say Mail From is a FAIL and Submitter is a PASS? What do I do? This
is beyond the scope of SPF Classic.
Keep this in mind for the future, but tell me this (assuming you are talking
about the MS Submitter that is part of the anti-forgery technology formerly
known as Sender ID), how do I deal with Submitter without having to sign the
MS license for PRA? There's the rub.
Scott Kitterman