RE: SUBMITTER patented ??

-----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 2:39 PM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: RE: [spf-discuss] SUBMITTER patented ??


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-bc

59-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


It's really rather all wrapped up in the whole MARID fiasco.  The Microsoft
approach (which they refer to as Sender ID, even though someone else has
trademarked the term) is really off topic for this list.

If you want to know more about how we got where we are, spend some time in
the MXCOMP archive.  Please don't ask us to explain it again....

http://www.imc.org/ietf-mxcomp/index.html

Also, even though the list is still functional, I would recommend posting
there.

Scott Kitterman