spf-discuss
[Top] [All Lists]

Re: For SPF council review: NOT RECOMMENDED

2005-05-09 12:38:01
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>.

--
Dave
************************************************************     *
* David MacQuigg, PhD      email:  dmquigg-spf at yahoo.com      *  *
* IC Design Engineer            phone:  USA 520-721-4583      *  *  *
* Analog Design Methodologies                                 *  *  *
*                                   9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.              Tucson, Arizona 85710        *
************************************************************ *