-----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?
Scott Kitterman