At 01:51 PM 5/10/2005 -0400, Scott Kitterman wrote:
>-----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: Tuesday, May 10, 2005 1:31 PM
>To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
>Subject: [spf-discuss] SUBMITTER patented ?? was For SPF council review:
>NOT RECOMMENDED
>
>At 11:33 PM 5/9/2005 -0400, Scott Kitterman wrote:
>> >[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of
David MacQuigg
>> >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.
>
>I may be interpreting SUBMITTER wrong, but to me it is an explicit
>declaration of the sender's Identity (the one that matches the sender's
>IP). I would use that Identity and none other. We probably need a
>different keyword here, something like ID= that has no previous
>association
>with a particular method.
>
>>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.
>
>As for using the Identity declared in SUBMITTER=, that shouldn't require
>any license. I think you only need a license if you want to implement the
>PRA algorithm. If you treat the declared Identity as simply a domain name
>to be authenticated against an IP address, you can use SPF or whatever
>method you like.
>
>--
>Dave
Much as I hate to talk about the topic, I'll bite...
Have a look here:
http://download.microsoft.com/download/b/8/c/b8cfc524-06d5-4c09-bc59-12759f3
44cae/senderid_spec4.pdf
Page 5:
4.1 Setting the SUBMITTER Parameter Value
The purpose of the SUBMITTER parameter is to allow the SMTP client to
indicate to the server
the purported responsible address of the message directly in the RFC 2821
protocol.
Therefore, SMTP clients that support the Responsible Submitter extension
MUST include the
SUBMITTER parameter on all messages. This includes messages containing a
null reverse-path
in the MAIL command.
SMTP clients MUST set the SUBMITTER parameter value to the purported
responsible address
of the message as defined in [PRA]. This also applies to messages containing
a null reversepath.
In some circumstances, described in section 7 of [SENDER-ID], SMTP clients
may need to add
RFC 2822 headers to the message in order to ensure that the correct
SUBMITTER parameter
value can be set.
Now... Tell me how to do that without implementing the PRA algorithm?
Wow!! And all these years I've been thinking ...
Wait!! If you read the draft-katz-submitter-00 **emphasis added**
Abstract
... The responsible
submitter is the e-mail address of the **entity most recently
responsible for introducing a message** into the transport stream.
This extension helps receiving e-mail servers efficiently determine
whether the SMTP client is authorized to transmit mail on behalf of
the **responsible submitter's domain**.
So it looks like SUBMITTER domain really is an ID that we can check using
SPF (assuming of course that it provides SPF records).
I must confess, I don't understand the PRA algorithm. I guess they had to
make it complex to qualify as "non-obvious".
I think this confusion over the meaning of SUBMITTER= disqualifies it as a
standard keyword. I'll go back to ID=
--
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 *
************************************************************ *