Mailing List Archive

Personally I'm more interested in getting SPF v 1 standardized and out of
experomental status. I suspect we can work on both in parallel as long as
we are clear to keep them cleanly separated.

The key distinction as I see it is SPF v 1 updates MUST be backwards
compatible, while SPF v 3 has more freedom to innovate.

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Stuart D. Gathman wrote:
> I propose to create a wiki page for features people think they might want
> in SPFv3 - like the Feature list for the Fedora project. Each feature
> would have its own page, with a name, summary, description, justification,
> use cases, etc.

+1

> I keep meaning to write up a new RFC with all the new features, but that
> is more daunting. I think debating the merits of each feature
> independently until there is consensus on the feature list will greatly
> help with creating the next RFC version.

Who has the original XML for v1? Obviously, starting from scratch
requires more work.

> I do have write permission on the Wiki, but I'll create an index page and
> pages for my favorite v3 features (helo and not) in the public portion
> first to try out the idea. Note that "you can do it in v1" is not a
> reason to exclude a feature if the feature does it in a simpler fashion or
> with less DNS bytes and has use cases that are likely to be popular.

I don't have write permissions, except for the community pages.
Keeping the list on the community pages will allow more participation.

> BTW, v3 should use SPF (type 99) RRs exclusively. That is non-optional I
> think. A typical library would check for SPFv3 as SPF, and fall back to
> checking for SPFv1 as TXT. There is still likely to be a chicken and egg
> problem with v3 adoption - but unlike using SPF instead of TXT for the
> same old v1 RRs, there is no downside to putting v3 in SPF RRs only.

I agree; however, that is a feature itself and deserves its own page.


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Scott Kitterman wrote:
> Personally I'm more interested in getting SPF v 1 standardized and out of
> experimental status. I suspect we can work on both in parallel as long as
> we are clear to keep them cleanly separated.
>
> The key distinction as I see it is SPF v 1 updates MUST be backwards
> compatible, while SPF v 3 has more freedom to innovate.

IMHO, v3 MUST be backward compatible.

I don't see the point of changing v1: it is rfc4408. A new version has
to be marked as such. If we introduce any new feature, or slightly
change the meaning of an existing feature, anyone willing to change
existing record can change the version number as well. OTOH, anyone
who interprets existing v1 records, is better off sticking to v1
specification.

I don't think there is much freedom to innovate with v3. SPF checks
will be carried out by old and new software alike, and I don't think
it is a Good Thing that the results vary widely. SPFv3 can just work
on the SPF RR type, recommending that a corresponding TXT record
tagged spfv1 be still maintained. Old rfc4408-software should discard
new SPF RRs starting with "v=spfv3" according to step 1 of section
4.5, and then proceed with "v=spfv1" RRs, probably but not necessarily
of type TXT, if any. New software should try TXT if it finds no SPF
RR, and accept "v=spfv1" for backward compatibility, but there is no
need to consider RRs of type SPF that start with "v=spfv3" (I think
that's what Stuart meant by "exclusively".)

IMHO, we should publish a single new RFC that prescribes a behavior
that is backward "compatible", for some acceptations of "compatible",
with both spfv1 and SenderID. We'll have to check with someone at the
IESG how many changes would be allowed for aiming at standard track,
but we have first of all to consolidate the existing use cases, which
may limit the amount of changes that would make sense to introduce.

I've had a try at publishing that wiki page, using the text above, see
http://www.openspf.org/Community/SPFv3

I haven't been able to create an SPFv3 subfolder. Navigating back from
a feature page to the SPFv3 URL just above is a bit of a nuisance.


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

I wrote:
> I've had a try at publishing that wiki page, using the text above, see
> http://www.openspf.org/Community/SPFv3
>
> I haven't been able to create an SPFv3 subfolder. Navigating back from a
> feature page to the SPFv3 URL just above is a bit of a nuisance.

I wrote a second feature, Feedback loop for softfail. It has an
horrible 'back' link at the top. I wish I had let Stuart do the wiki
as he proposed, which would probably have been better than what I've
done. Should we write a template for it? (I have no idea how that
would work, though.)

About the feature itself, I had already proposed it here
http://www.listbox.com/member/archive/735/2008/01/sort/time_rev/page/10/entry/6:236/



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Fri, 17 Jul 2009 10:35:59 +0200 Alessandro Vesely <vesely@tana.it> wrote:
>Who has the original XML for v1? Obviously, starting from scratch
>requires more work.
>
I've added a link to it on www.openspf.org/Specifications.

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Fri, 17 Jul 2009, Alessandro Vesely wrote:

> Scott Kitterman wrote:
> > Personally I'm more interested in getting SPF v 1 standardized and out of
> > experimental status. I suspect we can work on both in parallel as long as
> > we are clear to keep them cleanly separated.
> >
> > The key distinction as I see it is SPF v 1 updates MUST be backwards
> > compatible, while SPF v 3 has more freedom to innovate.
>
> IMHO, v3 MUST be backward compatible.

V3 is automatically backward compatible by virtue of being tagged with "v=spf3"
(or anything other than "v=spf1").

There are two tasks.

1. The most important, and most boring, is to shepherd SPF1 to a
non-experimental RFC. This involves editing to incorporate errata, and
clarifying things like "please remember to whitelist your forwarders, or at
least your own secondary MXes, when checking SPF, or at least don't reject if
your don't", but otherwise making no changes. (Of course, the RFC shouldn't
dictate receiver policy, and the wording should be more like "if the email is
relayed by an MTA not controlled by the sender, e.g. forwarders and MXes, the
SPF result will not reflect the senders intention".)

2. The second task, which is more fun, but not needed for some time is to
draw up the successor (v3). Of course, the successor will be tagged.
One tricky issue for the v3 RFC to specify is what to do when v1 and v3
are both specified and give different results. (I would say that v3
should always override v1 when present.) When a somewhat stable v3 takes
shape, it can be deployed by enthusiasts without an RFC (but with a draft rfc
on openspf.org). After it is really stable (years), a new RFC can be
submitted.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Stuart D. Gathman wrote:
> 1. The most important, and most boring, is to shepherd SPF1 to a
> non-experimental RFC. This involves editing to incorporate errata, and
> clarifying things like "please remember to whitelist your forwarders, or at
> least your own secondary MXes, when checking SPF, or at least don't reject if
> your don't", but otherwise making no changes.

I wish to thankk Scott for the link to the source. Does the "/svn/" in
the url imply an active repository? If a subversion server is
available it would ease that work.

> (Of course, the RFC shouldn't
> dictate receiver policy, and the wording should be more like "if the email is
> relayed by an MTA not controlled by the sender, e.g. forwarders and MXes, the
> SPF result will not reflect the senders intention".)

That is a general rule for RFCs. However, some roles around questions
of who authorizes who, and authentication vs. accountability, may be
clarified slightly.

> 2. The second task, which is more fun, but not needed for some time is to
> draw up the successor (v3). Of course, the successor will be tagged.
> One tricky issue for the v3 RFC to specify is what to do when v1 and v3
> are both specified and give different results. (I would say that v3
> should always override v1 when present.) When a somewhat stable v3 takes
> shape, it can be deployed by enthusiasts without an RFC (but with a draft rfc
> on openspf.org). After it is really stable (years), a new RFC can be
> submitted.

Do we really want to alter the specs to the point that v1 and v3 yield
different results? I hope we don't. SPF is quite stable and functional
_now_. I'd expect the time required for stability to be proportional
to the number and depth of changes. Hence, in general, the fewer
changes the better.


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

>>2. The second task, which is more fun, but not needed for some time is to draw up the successor (v3). Of course, the successor will be tagged. One tricky issue for the v3 RFC to specify is what to do when v1 and v3 are both specified and give different results. (I would say that v3 should always override v1 when present.) When a somewhat stable v3 takes shape, it can be deployed by enthusiasts without an RFC (but with a draft rfc on openspf.org). After it is really stable (years), a new RFC can be submitted.
>
>Do we really want to alter the specs to the point that v1 and v3 yield different results? I hope we don't. SPF is quite stable and functional _now_. I'd expect the time required for stability to be proportional to the number and depth of changes. Hence, in general, the fewer changes the better.

well I for one would like to see v3 being finer grained
and absorb superceed sender-id functions {so folks like me who don't love sender-id could publish}

v=spf3/helo a -spf
v=spf3/mfrom -spf
v=spf3/pra -spf

for helo id's

and

v=spf3/helo -all
v-spf3/mfrom redirect=%{l}._spf3.%{o}
v-spf3/pra ?all

for the domain itself
so it is never valid for helo
sender-id pra is never failed and the per-user mfrom spf is checked as usual for {enveloped sender}

obviously believers in pra checks could define a separate pra policy to mfrom policy {as even most older SRS-compliant forwarders currently fail pra checks afterward}

as currently its achievable but kludgy and the average spf user dosn't bother with the helo portion at all {and relies on the default pass for no spf}

{i would still love to see a syntax addition that equates too invalid from any source ip ever,
and results in an extra fail-code,
and results in a syntax error if proceeded by any ip returning syntax {mx a ptr ip4 etc},
or a rewrite to the parser that if it finds -all not proceeded by {mx a ptr ip4 etc} it returns the same extra fail-code}

the client re-write might be easier all told




-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Sat, 18 Jul 2009, Alessandro Vesely wrote:

> Do we really want to alter the specs to the point that v1 and v3 yield
> different results? I hope we don't. SPF is quite stable and functional _now_.
> I'd expect the time required for stability to be proportional to the number
> and depth of changes. Hence, in general, the fewer changes the better.

v3 would just add new mechanisms or prefixes that could shorten policies,
and of course move to the SPF RR type. And yes, the changes should be
few. Only a few features will be chosen from all the ideas put forth.

IMO, no attempt should be made to deploy a v3 until v1 has an official
RFC. But now is the time to start listing things we wish we could
fix in v1 for the eventual v3.

One thing we can do for an official v1 RFC, is clarify things
like SPF-V vs SPF-G.

--
Stuart D. Gathman <stuart@bmsi.com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Stuart D. Gathman wrote:
> IMO, no attempt should be made to deploy a v3 until v1 has an official
> RFC.

I'm no expert on standardization practices, but I read on rfc 2026
that "A Proposed Standard specification [...] has resolved known
design choices", and the IESG Note indeed expresses concern about SPF
and SenderID not being conciliable, as though the two approaches
typify the corresponding design choices. My understanding is that we
shall resolve that conflict before we get on the standards track. And
we need "spf3" for that.

At any rate, we'll need an AD to sponsor the process, and she or he
will hopefully also provide advice on what changes would preclude
which maturity level.

> But now is the time to start listing things we wish we could
> fix in v1 for the eventual v3.

+1

> One thing we can do for an official v1 RFC, is clarify things
> like SPF-V vs SPF-G.

We cannot prescribe a policy, but describing valid alternatives should
be just fine.



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Mon, 20 Jul 2009 15:44:36 +0200 Alessandro Vesely <vesely@tana.it> wrote:
>I'm no expert on standardization practices, but I read on rfc 2026
>that "A Proposed Standard specification [...] has resolved known
>design choices", and the IESG Note indeed expresses concern about SPF
>and SenderID not being conciliable, as though the two approaches
>typify the corresponding design choices. My understanding is that we
>shall resolve that conflict before we get on the standards track. And
>we need "spf3" for that.

Not at all (I'm not an expert either, but this is my guess). If you look
at the Sender ID RFCs (particulary, IIRC, the one that defines PRA), there
is an additional note from the IESG about Sender ID. These have not been
resolved.

There has been a proposal to move both the SPF and Sender ID RFCs to
historic status since they are 'superceded' by DKIM. I objected to this
for SPF. No one objected about Sender ID.

I think Sender ID should be transitioned to historic and the conflict
resolved that way. We cannot afford to require all SPF records to be
republished as we move forward.

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Mon, Jul 20, 2009 at 10:14 AM, Scott Kitterman<scott@kitterman.com> wrote:
> On Mon, 20 Jul 2009 15:44:36 +0200 Alessandro Vesely <vesely@tana.it> wrote:
>>I'm no expert on standardization practices, but I read on rfc 2026
>>that "A Proposed Standard specification [...] has resolved known
>>design choices", and the IESG Note indeed expresses concern about SPF
>>and SenderID not being conciliable, as though the two approaches
>>typify the corresponding design choices. My understanding is that we
>>shall resolve that conflict before we get on the standards track. And
>>we need "spf3" for that.
>
> Not at all (I'm not an expert either, but this is my guess).  If you look
> at the Sender ID RFCs (particulary, IIRC, the one that defines PRA), there
> is an additional note from the IESG about Sender ID.  These have not been
> resolved.
>
> There has been a proposal to move both the SPF and Sender ID RFCs to
> historic status since they are 'superceded' by DKIM.  I objected to this
> for SPF.  No one objected about Sender ID.
>
> I think Sender ID should be transitioned to historic and the conflict
> resolved that way.  We cannot afford to require all SPF records to be
> republished as we move forward.
>
> Scott K
>

I would agree with Scott on this. It is not simply about whether we
can afford to require republishing of SPF records. There are specific
issues with SenderID that came up during the experimental period that
justify relegating it to a historic status. SPF has enough of a track
record that it should be retained and moved to a regular track.


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Hi there,


On Mon, 20 Jul 2009, Dotzero wrote:

> ... SPF has enough of a track record that it should be retained and
> moved to a regular track.

+1

--

73,
Ged.


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

At 15:31 20/07/2009 Monday, Dotzero wrote:
>On Mon, Jul 20, 2009 at 10:14 AM, Scott Kitterman<scott@kitterman.com> wrote:
>> On Mon, 20 Jul 2009 15:44:36 +0200 Alessandro Vesely <vesely@tana.it> wrote:
>>>I'm no expert on standardization practices, but I read on rfc 2026
>>>that "A Proposed Standard specification [...] has resolved known
>>>design choices", and the IESG Note indeed expresses concern about SPF
>>>and SenderID not being conciliable, as though the two approaches
>>>typify the corresponding design choices. My understanding is that we
>>>shall resolve that conflict before we get on the standards track. And
>>>we need "spf3" for that.
>>
>> Not at all (I'm not an expert either, but this is my guess). If you look
>> at the Sender ID RFCs (particulary, IIRC, the one that defines PRA), there
>> is an additional note from the IESG about Sender ID. These have not been
>> resolved.
>>
>> There has been a proposal to move both the SPF and Sender ID RFCs to
>> historic status since they are 'superceded' by DKIM. I objected to this
>> for SPF. No one objected about Sender ID.
>>
>> I think Sender ID should be transitioned to historic and the conflict
>> resolved that way. We cannot afford to require all SPF records to be
>> republished as we move forward.
>>
>> Scott K
>>
>
>I would agree with Scott on this. It is not simply about whether we
>can afford to require republishing of SPF records. There are specific
>issues with SenderID that came up during the experimental period that
>justify relegating it to a historic status. SPF has enough of a track
>record that it should be retained and moved to a regular track.

but these issues only arise if the sender only publishes SPF and ignores sender-id
{as sender-id checking clients will mis-use the SPF record in ONLY this case}

if we mandate the use of a {blank is enough} sender-id policy with SPF the issue is no more
ie
for domain have
"v=spf1 redirect:_spf1.domain.tld"
"spf2.0/mfrom redirect:_senderid_mfrom.domain.tld"
"spf2.0/pra +all"

and have _spf1.domain.tld and _senderid_mfrom.domain.tld
return the same spf record
with appropriate "v=spf1 or "spf2.0/mfrom start

thus no crosstalk or conflict and issue resolved

but only if SPF group advises people to mitigate rather than ignore sender-id will it go away till v3



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Mon, Jul 20, 2009 at 11:53 AM, alan<spfdiscuss@alandoherty.net> wrote:
>
> but these issues only arise if the sender only publishes SPF and ignores sender-id
> {as sender-id checking clients will mis-use the SPF record in ONLY this case}
>
> if we mandate the use of a {blank is enough} sender-id policy with SPF the issue is no more
> ie
> for domain have
> "v=spf1 redirect:_spf1.domain.tld"
> "spf2.0/mfrom redirect:_senderid_mfrom.domain.tld"
> "spf2.0/pra +all"
>
> and have _spf1.domain.tld and _senderid_mfrom.domain.tld
> return the same spf record
> with appropriate "v=spf1 or "spf2.0/mfrom start
>
> thus no crosstalk or conflict and issue resolved
>
> but only if SPF group advises people to mitigate rather than ignore sender-id will it go away till v3
>

Alan,

The issues I referred to are brokenness within Sender-ID, not abuse of
SPF1 records. One key brokenness in SID is the paragraph in RFC4407
that sates:

"3. Select all the non-empty Sender headers in the message. If there
are no such headers, continue with step 4. If there is exactly
one such header, proceed to step 5. If there is more than one
such header, proceed to step 6."

Giving precedence to the "Sender" field allows one to game the system
to get a neutral (at minimum) for what are clearly spam/fraudulent
messages.


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Mon, 20 Jul 2009 16:53:58 +0100 alan <spfdiscuss@alandoherty.net> wrote:
>At 15:31 20/07/2009 Monday, Dotzero wrote:
>>On Mon, Jul 20, 2009 at 10:14 AM, Scott Kitterman<scott@kitterman.com>
wrote:
>>> On Mon, 20 Jul 2009 15:44:36 +0200 Alessandro Vesely <vesely@tana.it>
wrote:
>>>>I'm no expert on standardization practices, but I read on rfc 2026
>>>>that "A Proposed Standard specification [...] has resolved known
>>>>design choices", and the IESG Note indeed expresses concern about SPF
>>>>and SenderID not being conciliable, as though the two approaches
>>>>typify the corresponding design choices. My understanding is that we
>>>>shall resolve that conflict before we get on the standards track. And
>>>>we need "spf3" for that.
>>>
>>> Not at all (I'm not an expert either, but this is my guess). If you
look
>>> at the Sender ID RFCs (particulary, IIRC, the one that defines PRA),
there
>>> is an additional note from the IESG about Sender ID. These have not
been
>>> resolved.
>>>
>>> There has been a proposal to move both the SPF and Sender ID RFCs to
>>> historic status since they are 'superceded' by DKIM. I objected to this
>>> for SPF. No one objected about Sender ID.
>>>
>>> I think Sender ID should be transitioned to historic and the conflict
>>> resolved that way. We cannot afford to require all SPF records to be
>>> republished as we move forward.
>>>
>>> Scott K
>>>
>>
>>I would agree with Scott on this. It is not simply about whether we
>>can afford to require republishing of SPF records. There are specific
>>issues with SenderID that came up during the experimental period that
>>justify relegating it to a historic status. SPF has enough of a track
>>record that it should be retained and moved to a regular track.
>
>but these issues only arise if the sender only publishes SPF and ignores
sender-id
>{as sender-id checking clients will mis-use the SPF record in ONLY this
case}
>
>if we mandate the use of a {blank is enough} sender-id policy with SPF the
issue is no more
>ie
>for domain have
>"v=spf1 redirect:_spf1.domain.tld"
>"spf2.0/mfrom redirect:_senderid_mfrom.domain.tld"
>"spf2.0/pra +all"
>
>and have _spf1.domain.tld and _senderid_mfrom.domain.tld
>return the same spf record
>with appropriate "v=spf1 or "spf2.0/mfrom start
>
>thus no crosstalk or conflict and issue resolved
>
>but only if SPF group advises people to mitigate rather than ignore
sender-id will it go away till v3
>
People will always do odd things with SPF records because they believe it's
useful. We can't stop it.

Moving the Sender ID RFCs to historic is sufficient to stop standardized
misuse. The other kind we can't control and shouldn't try.

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

At 17:08 20/07/2009 Monday, Dotzero wrote:
>On Mon, Jul 20, 2009 at 11:53 AM, alan<spfdiscuss@alandoherty.net> wrote:
>>
>> but these issues only arise if the sender only publishes SPF and ignores sender-id
>> {as sender-id checking clients will mis-use the SPF record in ONLY this case}
>>
>> if we mandate the use of a {blank is enough} sender-id policy with SPF the issue is no more
>> ie
>> for domain have
>> "v=spf1 redirect:_spf1.domain.tld"
>> "spf2.0/mfrom redirect:_senderid_mfrom.domain.tld"
>> "spf2.0/pra +all"
>>
>> and have _spf1.domain.tld and _senderid_mfrom.domain.tld
>> return the same spf record
>> with appropriate "v=spf1 or "spf2.0/mfrom start
>>
>> thus no crosstalk or conflict and issue resolved
>>
>> but only if SPF group advises people to mitigate rather than ignore sender-id will it go away till v3
>>
>
>Alan,
>
>The issues I referred to are brokenness within Sender-ID, not abuse of
>SPF1 records. One key brokenness in SID is the paragraph in RFC4407
>that sates:
>
>"3. Select all the non-empty Sender headers in the message. If there
> are no such headers, continue with step 4. If there is exactly
> one such header, proceed to step 5. If there is more than one
> such header, proceed to step 6."
>
>Giving precedence to the "Sender" field allows one to game the system
>to get a neutral (at minimum) for what are clearly spam/fraudulent
>messages.

i wasn't actually responding on the subject of sender-id's brokenness {further than their mis-use of spf1 records}
as for those interested in SPF thats all that counts/matters and impacts users of SPF



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Scott Kitterman wrote:
>> My understanding is that we
>> shall resolve that conflict before we get on the standards track. And
>> we need "spf3" for that.
>
> Not at all (I'm not an expert either, but this is my guess). If you look
> at the Sender ID RFCs (particulary, IIRC, the one that defines PRA), there
> is an additional note from the IESG about Sender ID. These have not been
> resolved.

The four of them look exactly like one another (except for the
"aParticipants"). However, the paragraph about Resent-* headers is for
SenderID only.

> There has been a proposal to move both the SPF and Sender ID RFCs to
> historic status since they are 'superceded' by DKIM. I objected to this
> for SPF. No one objected about Sender ID.

I'm not sure how DKIM supersedes SPF. For example, if I wanted to send
feedback loop reports for failed DKIM verification, I would only
bother SPF-valid senders.

> I think Sender ID should be transitioned to historic and the conflict
> resolved that way. We cannot afford to require all SPF records to be
> republished as we move forward.

I agree republishing shouldn't be a requirement. I also agree SenderID
should be transitioned to historic. However, it is not clear to me if
a new RFC can pretend that SenderID never existed, and avoid to even
mention it, but at the same time ostentatiously point an invisible
finger to the "Category: Historic" field of the relevant SenderID's
RFCs for the readers to take note.

Even hotmail.com's TXT records start with "v=spf1", and I wonder if
they mean they should be interpreted as "spf2.0/mfrom,pra". What
should newcomers publish? How are existing records to be interpreted?
As a new RFC oughts to be part of the solution, it should probably
mention "spf2.0" and what is the correct record selection and
interpretation in the various cases. Shouldn't it?

We may be able to do that without introducing yet another version.
Will it be much simpler that way? And how about the transition to SPF
RRs exclusively? In case the new RFC will be a Proposed or Draft
Standard, we will have to stick to that text for an eventual Full
Standard.



-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Mon, 20 Jul 2009 20:06:45 +0200 Alessandro Vesely <vesely@tana.it> wrote:
>Scott Kitterman wrote:
>>> My understanding is that we
>>> shall resolve that conflict before we get on the standards track. And
>>> we need "spf3" for that.
>>
>> Not at all (I'm not an expert either, but this is my guess). If you
look
>> at the Sender ID RFCs (particulary, IIRC, the one that defines PRA),
there
>> is an additional note from the IESG about Sender ID. These have not
been
>> resolved.
>
>The four of them look exactly like one another (except for the
>"aParticipants"). However, the paragraph about Resent-* headers is for
>SenderID only.

My recollection was the IESG note was slightly different. I'm not in a
position to check right now.

>> There has been a proposal to move both the SPF and Sender ID RFCs to
>> historic status since they are 'superceded' by DKIM. I objected to this
>> for SPF. No one objected about Sender ID.
>
>I'm not sure how DKIM supersedes SPF. For example, if I wanted to send
>feedback loop reports for failed DKIM verification, I would only
>bother SPF-valid senders.

It doesn't. That's why I put it quotes. It does, to some extent,
supercede Sender ID.

>> I think Sender ID should be transitioned to historic and the conflict
>> resolved that way. We cannot afford to require all SPF records to be
>> republished as we move forward.
>
>I agree republishing shouldn't be a requirement. I also agree SenderID
>should be transitioned to historic. However, it is not clear to me if
>a new RFC can pretend that SenderID never existed, and avoid to even
>mention it, but at the same time ostentatiously point an invisible
>finger to the "Category: Historic" field of the relevant SenderID's
>RFCs for the readers to take note.

Sure we can. There's no obligation for standards track documents to
consider old experiments. The SPF project already gives recommendations
wrt Sender ID. There's no need to give it undue emphasis by dealing with
it in an RFC.

>Even hotmail.com's TXT records start with "v=spf1", and I wonder if
>they mean they should be interpreted as "spf2.0/mfrom,pra". What
>should newcomers publish? How are existing records to be interpreted?
>As a new RFC oughts to be part of the solution, it should probably
>mention "spf2.0" and what is the correct record selection and
>interpretation in the various cases. Shouldn't it?

You'd have to ask Hotmail about what they expect their SPF records are meant to mean. RFC 4408
describes what SPF records are and the only use of which I am aware that is suitable for
standardization. No, I don't think we have any obligation to deal with cleaning
up after Microsoft.

>We may be able to do that without introducing yet another version.
>Will it be much simpler that way? And how about the transition to SPF
>RRs exclusively? In case the new RFC will be a Proposed or Draft
>Standard, we will have to stick to that text for an eventual Full
>Standard.
>
Now you are describing something not backward compatible. That should wait
for an eventual SPF v 3.

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Mon, 20 Jul 2009, Dotzero wrote:
> The issues I referred to are brokenness within Sender-ID, not abuse of
> SPF1 records. One key brokenness in SID is the paragraph in RFC4407
> that sates:
>
> "3. Select all the non-empty Sender headers in the message. If there
> are no such headers, continue with step 4. If there is exactly
> one such header, proceed to step 5. If there is more than one
> such header, proceed to step 6."
>
> Giving precedence to the "Sender" field allows one to game the system
> to get a neutral (at minimum) for what are clearly spam/fraudulent
> messages.

Standard SPFv1 has the same problem, in that a message with a blatantly
forged header From: will pass so long as the envelope MAIL FROM is unforged.
Most users won't notice an unusual Return-path: unless they were already
suspicous for other reasons.

(Although SPFv1 is still slightly better than SenderID because protecting
the MAIL FROM: reduces backscatter.)

DK/DKIM solves the problem by focusing on the From:. However, because of
that very feature, it false-positives on mailing lists.


Actually, it would be really cool to have an anti-forgery protocol that uses
cryptography like DK/DKIM, but protects the MAIL FROM like SPFv1. This would
avoid both SPFv1's forwarder FPs, and DK/DKIM's mailinglist FPs, thus
allowing rapid, complete deployment at the receiver end without causing mass
breakage.

My "fm=dkim" proposal, earlier, effectively would create such a protocol,
taking advantage of the fact that DKIM permits signatures other than those
for the From: domain.

---- Michael Deutschmann <michael@talamasca.ocis.net>


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

Scott Kitterman wrote:
>> Even hotmail.com's TXT records start with "v=spf1", and I wonder if
>> they mean they should be interpreted as "spf2.0/mfrom,pra".
>
> You'd have to ask Hotmail about what they expect their SPF records are meant to mean.

They are careful to always send with an SPF-good envelope sender.
Incoming mail that doesn't pass the check goes to Junk folders, marked
with a white cross on red background. In their words:

Windows Live Hotmail treats all messages that fail Sender ID and
phishing tests as fraudulent and warns the user about opening these
messages.

That is the "silently drop" track, leading to unreliability.

> RFC 4408
> describes what SPF records are and the only use of which I am aware that is suitable for
> standardization.

I assume that "use" means obtaining the result, since what to do with
the result is currently in the site-policies limbo. I think SPF use is
superior, in that sense. However, there are mail domains that apply a
different semantics, and some people on this list publish specific
spf2.0 records for them. Do you mean we can discard them because they
are irrelevant?

> No, I don't think we have any obligation to deal with cleaning
> up after Microsoft.

We know M$ moves with the grace of an elephant in a crystal shop, and
I wish they never begrudged the MARID. However, if cleaning up is a
possible way to reach a clean state, we may consider it. One advantage
of v3 is that it introduces such cleaning up nicely. We can tag some
stuff as historic, but forgetting history is never recommendable. For
comparison, rfc5321 still mentions a number of really really obsolete
behaviors.

>> And how about the transition to SPF
>> RRs exclusively? In case the new RFC will be a Proposed or Draft
>> Standard, we will have to stick to that text for an eventual Full
>> Standard.
>>
> Now you are describing something not backward compatible. That should wait
> for an eventual SPF v 3.

http://www.openspf.org/Community/SPFv3-SPF-RR-exclusive describes a
smooth transition. The current stance of requiring equal TXT and SPF
records doesn't make much sense. An alternative would be to drop SPF
records altogether; using TXT RRs labeled _spf.example.com would be
more in tune with what similar protocols do.

A smooth transition to SPFv3 from the record selection described in
rfc 4406 is more problematic: in step 1 they discard all TXT records
if any SPF RRs are found, before even looking at their versions.

I'd guess it would take at least a four years span following the
publication of a new RFC, to get a further SPF update. Possibly much
more. What you reckon?


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com

On Tue, 21 Jul 2009 12:13:52 +0200 Alessandro Vesely <vesely@tana.it> wrote:
>Scott Kitterman wrote:
>>> Even hotmail.com's TXT records start with "v=spf1", and I wonder if
>>> they mean they should be interpreted as "spf2.0/mfrom,pra".
>>
>> You'd have to ask Hotmail about what they expect their SPF records are
meant to mean.
>
>They are careful to always send with an SPF-good envelope sender.
>Incoming mail that doesn't pass the check goes to Junk folders, marked
>with a white cross on red background. In their words:
>
> Windows Live Hotmail treats all messages that fail Sender ID and
> phishing tests as fraudulent and warns the user about opening these
> messages.
>
>That is the "silently drop" track, leading to unreliability.
>
Agreed. For most domains and most mail (80% is a figure I've seen before)
Mail From and From are the same. Even today most domains can avoid
worrying about Sender ID specifics.

People use SPF recoeds for all kinds of purposes. The fact that a
particular free email provider has documented their approach in a series of
experimental RFCs shouldn't affect our efforts.

As a practical matter trying to land clear non-spam in someone's inbox at
Hotmail is sufficiently stochastic even for mail that passes Sender ID that
I doubt it matters much either way.

>> RFC 4408
>> describes what SPF records are and the only use of which I am aware that
is suitable for
>> standardization.
>
>I assume that "use" means obtaining the result, since what to do with
>the result is currently in the site-policies limbo. I think SPF use is
>superior, in that sense. However, there are mail domains that apply a
>different semantics, and some people on this list publish specific
>spf2.0 records for them. Do you mean we can discard them because they
>are irrelevant?

Yes. They are part of a failed experiment. When I've seen statistics,
there just don't seem to be a lot of SPF2.0 records out there.

>> No, I don't think we have any obligation to deal with cleaning
>> up after Microsoft.
>
>We know M$ moves with the grace of an elephant in a crystal shop, and
>I wish they never begrudged the MARID. However, if cleaning up is a
>possible way to reach a clean state, we may consider it. One advantage
>of v3 is that it introduces such cleaning up nicely. We can tag some
>stuff as historic, but forgetting history is never recommendable. For
>comparison, rfc5321 still mentions a number of really really obsolete
>behaviors.

True, but they were at one time standardized.

>>> And how about the transition to SPF
>>> RRs exclusively? In case the new RFC will be a Proposed or Draft
>>> Standard, we will have to stick to that text for an eventual Full
>>> Standard.
>>>
>> Now you are describing something not backward compatible. That should
wait
>> for an eventual SPF v 3.
>
>http://www.openspf.org/Community/SPFv3-SPF-RR-exclusive describes a
>smooth transition. The current stance of requiring equal TXT and SPF
>records doesn't make much sense. An alternative would be to drop SPF
>records altogether; using TXT RRs labeled _spf.example.com would be
>more in tune with what similar protocols do.
>
>A smooth transition to SPFv3 from the record selection described in
>rfc 4406 is more problematic: in step 1 they discard all TXT records
>if any SPF RRs are found, before even looking at their versions.
>
>I'd guess it would take at least a four years span following the
>publication of a new RFC, to get a further SPF update. Possibly much
>more. What you reckon?
>
We've already had it for four years and deployment is nil. I don't expect
that to change.

All schemes like SPF start with a catch 22. No one will check for records
because there are none published. No one will publish records because no
one checks them.

The fact that Meng Wong was able to come up with a way to break that catch
22 in 2003/2004 was almost miraculous. SPF was not the first attempt in
this problem space, it was just the first to succeed. The only other
similar success of which I'm aware is DK/DKIM.

The pyspf library that I help maintain has supported type SPF since roughly
a week after it was assigned. After performance related complaints, type
SPF checking was turned off by default.

My online SPF record checker has checked for it since then. Beyond "What's
that?", I've never gotten any questiond about it.

I maintain several SPF related packages in Ubuntu. Neither C library
supports type SPF. No one has complained. The new (relatively) Perl
library, Mail::SPF, does SPF checking and you can't turn it off. I've had
performance complaints.

Moving to a subdomain, bumping the version string to V3, or switching to
type SPF only all reset the deployment clock and need to break through the
catch 22 I describe above. DK/DKIM are only succeeding because large
entities like Yahoo! and Cisco are investing in them and expending
engineering and 'political' resources to push them.

Unless you've got a solid plan for getting past the deployment catch 22,
then stick with what can be done with version 1. I do think changing to
specify both lookups are not required if a type SPF record exists is a
change that can be done in a backward compatible way. If deployment picks
up, then a future revision could go further.

I do agree an eventual SPF v 3 should be type SPF only.

The SPF project has no corporate backing or budget. I view our deployed
base of SPF records and SPF checking programs as the most valuable assets
of the project and we must be careful not to place them at risk.

Scott K
Whether you move


-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Modify Your Subscription: http://www.listbox.com/member/
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/
Powered by Listbox: http://www.listbox.com