Mailing List Archive

----- Original Message -----
From: "Scott Kitterman" <scott@kitterman.com>
To: <spf-discuss@v2.listbox.com>
Sent: Saturday, January 24, 2009 3:29 PM
Subject: Re: Re[2]: [spf-discuss] back to Reclassifying Sender ID and SPF as
Historic - was: New SPF Council


> On Sat, 24 Jan 2009 09:29:32 +0100 "Alex van den Bogaerdt"
> <alex@ergens.op.het.net> wrote:
> ...
>>What is essential is that SPF policies in TXT records go away, or at least
>>become obsolete. Checking for both RR's is a waste, keeping TXT and not
> SPF
>>is not good either (TXT records are used for other purposes). That leaves
>>keeping SPF records and stop using SPF policies in TXT records.
> ...
>
> Checking both RRs is a waste is right. When we did RFC 4408, the general
> consenus was that type SPF would not get significant traction.

at that point in time: yes.

> So far
> that's holding up well. I don't see why this will change no matter what
> we
> write in an RFC.
>
> So far I've seen rehashes of the same discussions we had 3 or 4 years ago
> about theoretical goodnes of a dedicated RR type. No one has yet
> addressed
> the question of how to do the transition. Vague assertions aren't going
> to
> get it.

I have addressed the issue. Briefly perhaps, but it is certainly not true
that it hasn't been addressed.

Using TXT is sometimes troublesome. This is even mentioned in the RFC. It is
my believe that the SPF RR was asked for to overcome this problem. I
(reluctantly) agreed that when the drafts were published, it was too soon to
require the use of SPF records instead of TXT records.

That was then. Now is now.

There is a resource record type, bind (and probably other DNS software as
well?) supports it, its handling is the same as you do with TXT records.
Provided that the software can handle it, domains can easily transition to
using SPF records when they need to. They need to be motivated to do so,
which is IMHO reached by declaring the use of TXT as obsolete

> This message to the IETF is not a kind invitation move SPF onto the
> standards track. It's an attempt to kill SPF and Sender ID both.

I disagree. The last paragraph basically asks us to resolve the conflict and
update the specifications -> spf should continue, but not in 4408.

> I feel very strongly that we need to limit ourselves to fixing protocol
> bugs right now. The only one I'm aware of is the treatment of all DNS
> errors as temporary when some aren't.

I consider dealing with both TXT and SPF RR's a bug.

> Let's deal with protocol enhancements later.

Agreed. But ditching TXT is not such an enhancement IMHO.




-------------------------------------------
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:32 24/01/2009 Saturday, Alex van den Bogaerdt wrote:
>----- Original Message ----- From: "Scott Kitterman" <scott@kitterman.com>
>To: <spf-discuss@v2.listbox.com>
>Sent: Saturday, January 24, 2009 3:29 PM
>Subject: Re: Re[2]: [spf-discuss] back to Reclassifying Sender ID and SPF as Historic - was: New SPF Council
>
>
>>On Sat, 24 Jan 2009 09:29:32 +0100 "Alex van den Bogaerdt"
>><alex@ergens.op.het.net> wrote:
>>...
>>>What is essential is that SPF policies in TXT records go away, or at least
>>>become obsolete. Checking for both RR's is a waste, keeping TXT and not
>>SPF
>>>is not good either (TXT records are used for other purposes). That leaves
>>>keeping SPF records and stop using SPF policies in TXT records.
>>...
>>
>>Checking both RRs is a waste is right. When we did RFC 4408, the general
>>consenus was that type SPF would not get significant traction.
>
>at that point in time: yes.

and still today to a large extent


>> So far
>>that's holding up well. I don't see why this will change no matter what we
>>write in an RFC.
>>
>>So far I've seen rehashes of the same discussions we had 3 or 4 years ago
>>about theoretical goodnes of a dedicated RR type. No one has yet addressed
>>the question of how to do the transition. Vague assertions aren't going to
>>get it.
>
>I have addressed the issue. Briefly perhaps, but it is certainly not true that it hasn't been addressed.
>
>Using TXT is sometimes troublesome. This is even mentioned in the RFC. It is my believe that the SPF RR was asked for to overcome this problem. I (reluctantly) agreed that when the drafts were published, it was too soon to require the use of SPF records instead of TXT records.
>
>That was then. Now is now.
>
>There is a resource record type, bind (and probably other DNS software as well?) supports it, its handling is the same as you do with TXT records. Provided that the software can handle it, domains can easily transition to using SPF records when they need to. They need to be motivated to do so, which is IMHO reached by declaring the use of TXT as obsolete

but only supported in bind 9.4 and above
still unfortunately rare in the wild {none of my hosting or secondary {remotely provided by others} dns servers support it as yet

but the point is moot as long as clients try SPF first and only TXT when SPF fails
it will be easy for dns providers to retire TXT for SPF when they see no more lookups for TXT

hell it should be possible for many to retire TXT when their own server starts providing SPF

only reason for providing both is
A broken/old clients
B broken/old caching dns servers

both will disappear in time {but only in time not through saying it must be so}


>>This message to the IETF is not a kind invitation move SPF onto the
>>standards track. It's an attempt to kill SPF and Sender ID both.
>
>I disagree. The last paragraph basically asks us to resolve the conflict and update the specifications -> spf should continue, but not in 4408.

i think we should be attempting to come up with an spf successor/replacement
that at client and provider level should separate {as in distinguishable} but largely backward compatible
so that clients and providers can migrate easily {limited differences in syntax and thus limited re-writing}
and both clients an providers can continue to support existing format also {in absence of newer format}


>>I feel very strongly that we need to limit ourselves to fixing protocol
>>bugs right now. The only one I'm aware of is the treatment of all DNS
>>errors as temporary when some aren't.
>
>I consider dealing with both TXT and SPF RR's a bug.
>
>>Let's deal with protocol enhancements later.
>
>Agreed. But ditching TXT is not such an enhancement IMHO.

I think this is exactly when we should deal with protocol enhancements
such as the suggested extra return code for dns errors of a non temporary nature {i saw it mentioned didn't see it detailed}
extra return code for never-exists {as opposed to fails spf-validity check}
and adding to helo and mfrom realms the pra realm to supercede sender-id for those that want this feature included
{for those not wanting to use it it can also be easily excluded from that providers spf record}





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



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

Dropping the previous text to try a different approach ....

To update RFC 4408 we have to do two things:

1. Resolve the conflict with Sender ID. My proposal for this is to say
DKIM already covers the problem SenderID was meant to solve and is
standards track. Make the Sender ID specs historic and declare it dead.

2. Bugfix the current protocol. I think this can be limited to moving
some DNS Rcodes to permerror and adjusting the type SPF/TXT discussion.

Anything else, IMO, is compatible with the installed base and can be done
in a separate draft or breaks the installed based and I'm against it.

For SPF/TXT, how about something like:

SPF records of type TXT will be deprecated in the future. Senders SHOULD
publish records of type SPF. Receivers SHOULD check for type SPF. Use of
type TXT records MAY continue, but will be deprecated and are not
futureproof.

Keep in mind the IETF has a three step process to full standards, so there
are two more shots at this. We put the deprecation warning in now,
deprecate them the next time, and then drop them for full standard.

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

Scott,

At 12:16 PM 1/24/2009, you wrote:
>Dropping the previous text to try a different approach ....
>
>To update RFC 4408 we have to do two things:
>
>1. Resolve the conflict with Sender ID. My proposal for this is to say
>DKIM already covers the problem SenderID was meant to solve and is
>standards track. Make the Sender ID specs historic and declare it dead.

Agreed. Although anecdotal, I have been using a mixed DKIM and SPF
environment here and in my experience this works just fine.

>2. Bugfix the current protocol. I think this can be limited to moving
>some DNS Rcodes to permerror and adjusting the type SPF/TXT discussion.
>
>Anything else, IMO, is compatible with the installed base and can be done
>in a separate draft or breaks the installed based and I'm against it.
>
>For SPF/TXT, how about something like:
>
>SPF records of type TXT will be deprecated in the future. Senders SHOULD
>publish records of type SPF. Receivers SHOULD check for type SPF. Use of
>type TXT records MAY continue, but will be deprecated and are not
>futureproof.

I would modify slightly, "Receivers MUST first check for type SPF and
failing a response Receivers SHOULD then check for type TXT."

I think that this serves to make clear that SPF has not abandoned TXT
records, but that they are a secondary priority for the current
protocol specification. It becomes another flag to demonstrate that
the protocol has matured and is moving forward by considering the TXT
RR as specifically included to account for the earlier days when
99/SPF DNS RRs did not exist.

In doing this, I think the spec underscores an objective to announce
that SPF TXT RR records are subject to becoming fully depreciated
through an organic process. That process being driven by the
adopters who publish SPF entries in their host files, dropping those
records in favor of the native 99/SPF RR, over however much time
required for that happening.

>Keep in mind the IETF has a three step process to full standards, so there
>are two more shots at this. We put the deprecation warning in now,
>deprecate them the next time, and then drop them for full standard.
>
>Scott K

Best,

Alan Maitland



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

It is hard to overstate the value and consequent inertia of the SPF
records already "in the field". This is not going to change quickly,
and the standard _must_ reinforce, not diminish, the value of the
existing "base of records".

Anything in the standard that seeks to "force" changes in this base
will do damage to SPF adoption.

We have almost zero leverage with the admins and software vendors
that would have to make changes.

I agree with what is below. Get on the standards track. Fix what is
broken. Change only what must be changed - no more. I would go
one step further, and remove things that are controversial or where
utility is not clearly demonstrated. Smaller, simpler standards are
easier to get adopted.

-dgl-

>Dropping the previous text to try a different approach ....
>
>To update RFC 4408 we have to do two things:
>
>1. Resolve the conflict with Sender ID. My proposal for this is to say
>DKIM already covers the problem SenderID was meant to solve and is
>standards track. Make the Sender ID specs historic and declare it dead.
>
>2. Bugfix the current protocol. I think this can be limited to moving
>some DNS Rcodes to permerror and adjusting the type SPF/TXT discussion.
>
>Anything else, IMO, is compatible with the installed base and can be done
>in a separate draft or breaks the installed based and I'm against it.
>
>For SPF/TXT, how about something like:
>
>SPF records of type TXT will be deprecated in the future. Senders SHOULD
>publish records of type SPF. Receivers SHOULD check for type SPF. Use of
>type TXT records MAY continue, but will be deprecated and are not
>futureproof.
>
>Keep in mind the IETF has a three step process to full standards, so there
>are two more shots at this. We put the deprecation warning in now,
>deprecate them the next time, and then drop them for full standard.
>
>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



-------------------------------------------
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 23 January 2009 21:35:22 -0500 Scott Kitterman <scott@kitterman.com>
wrote:

> On Fri, 23 Jan 2009 18:29:53 -0600 Don Lee
> <spfdiscuss@caution.icompute.com> wrote:
>> From my POV, we should push for the SPF RR, but recognize that the TXT
>> records are going to be required in any usable implementations for
>> a very long time.
>
> What makes you think "very long time" will be less than forever?
>
> Until a receiver can check just type SPF and not type TXT, there's a
> substantial disadvantage for receivers to check both. Until receivers
> check type SPF there's no motivation to go to the added trouble to
> publish two sets of records.
>
> Until someone figures out how to break this catch 22, type SPF deployment
> will stay where it is, nil.
>
> Scott K

What's required to persuade people to check SPF as well as TXT records is
for one or more significant email senders (or a lot of smaller ones) to
take a leadership role and publish only the SPF records. That leader could
be one of the large email service providers, or it could be a government
organisation.

But that probably won't happen until software exists to enable it. Any
tools for publication should provide SPF records by default and TXT records
as an option. Similarly, libraries for validating records should check SPF
by default, and TXT as an option.

The RFCs should be drafted accordingly. Nothing will be made non-compliant
as a result, but new tools, and new versions of existing tools, created by
people reading the RFC will encourage drift away from TXT and towards SPF.

So, I think this draft should say "SHOULD publish/check SPF" and "MAY
publish/check TXT" records.

--
Ian Eiloart
IT Services, University of Sussex
x3148


-------------------------------------------
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 11 January 2009 20:47, Scott Kitterman <scott@kitterman.com> wrote:

> It looks like we'll need a mechanism to establish an official SPF project
> position on this.  I think we need to elect a new SPF Council.

More than two years ago -- I'm curious if any of my old SPF list accounts still
works (webmasters bounced, and I need it to get a new OpenSPF password ;-)

Six months ago the IESG finally decided what to do with our "errata" page,
and they propse to update the RFC. I've asked if that possibly means "on
standards track", because that would be nice... :-)

Frank

Compare <http://www.rfc-editor.org/errata_search.php?rfc=4408&eid=994>


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110126133653:500DCCB8-297B-11E0-96AD-6D68F559ED1D
Powered by Listbox: http://www.listbox.com

On Wed, Jan 21, 2009 at 12:31 PM, Scott Kitterman <scott@kitterman.com> wrote:
> On Wed, 21 Jan 2009 17:58:21 +0100 "Alex van den Bogaerdt"
> <alex@ergens.op.het.net> wrote:
>> I feel that we
>>should continue with the protocol as designed, using the momentum we now
>>have.
>>
>
> Plus about a billion here.  We must not do anything that invalidates the
> current records.
>
> Scott K
>

There is an opportunity to move SPF to standards track.

Normally there would be an IETF working group with 2 moderators
assigned. This would either be an existing group or a group created
for the purpose. I'm not sure what the process would be if this were
attempted on spf-discuss outside of the working group process. I could
ask someone like Barry Lieba (IETF-DKIM working group) if he could
share some thoughts about the process with the list.

I agree with Scott and others that care should be taken to protect
existing records.

I am intrigued by the idea of using _spf for v3. It is at least worth
considering.

My next thought is that if there is an intent to go for standards
track, there should at least be some sort of review of implementation
levels for various methods and modifiers for usage. If (and I am not
saying there is) there are things not being used in any meaningful way
or are generally implemented in ways that are broken, this would be
the time to clean things up.

As far as adding new features/funcionality, I would be reticent unless
there were compelling reasons.

Mike


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110126140123:C6C3DB06-297E-11E0-98D7-B341E22C412F
Powered by Listbox: http://www.listbox.com

On Wednesday, January 26, 2011 01:36:44 pm Frank Ellermann wrote:
> On 11 January 2009 20:47, Scott Kitterman <scott@kitterman.com> wrote:
> > It looks like we'll need a mechanism to establish an official SPF project
> > position on this. I think we need to elect a new SPF Council.
>
> More than two years ago -- I'm curious if any of my old SPF list accounts
> still works (webmasters bounced, and I need it to get a new OpenSPF
> password ;-)
>
> Six months ago the IESG finally decided what to do with our "errata" page,
> and they propse to update the RFC. I've asked if that possibly means "on
> standards track", because that would be nice... :-)
>
> Frank
>
> Compare <http://www.rfc-editor.org/errata_search.php?rfc=4408&eid=994>

It would be great if we can make some progress on this. Glad to see you
again Frank.

Scott K


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/1311532-17d8a1ba
Modify Your Subscription: https://www.listbox.com/member/?member_id=1311532&id_secret=1311532-f2ea6ed9
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=1311532&id_secret=1311532-bdbb122a&post_id=20110126142810:67C01E68-2982-11E0-AFE1-8179F9143C7D
Powered by Listbox: http://www.listbox.com