Mailing List Archive

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

Hm.. I only have vague ideas about ietf practices. May I ask what are
the purposes of an official position and a council election?

The forwarded message reminds us that it is more than time that we
write another SPF standard. By "we" I vaguely mean this list. Of
course someone should take the burden to actually operate the required
IETF procedures.

Frank and Wayne have submitted relevant RFC errata. Are Wayne and
Meng, the authors of the current RFC, still on this list? Did they say
they are not going to [co-]author a new release? If yes, is that the
origin of the RFC5378-related problem?

> ---------- Forwarded Message ----------
> Subject: Reclassifying Sender ID and SPF as Historic
> Date: Sunday 11 January 2009 12:25
> From: SM <sm@resistor.net>
> To: ietf@ietf.org
> [...]
> Proponents of Sender ID and SPF are encouraged to update their
> specifications to resolve any conflict that was observed. Obviously,
> it's in their best interests to reach a consensus on what changes are
> appropriate instead of trying to publish each document individually
> as any individual effort would likely face opposition from the IETF
> community.

Anyone has any notice about activities to rewrite RFC4406?

IMHO, "spf-discuss" is the proper place for discussions on any new SPF
RFC. If we get no news from SenderID authors, shouldn't we opt to
solve conflicts by using, say, "v=spf3", and aim for the standard 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

On Tue, 13 Jan 2009, Alessandro Vesely wrote:

> Scott Kitterman 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.
>
> The forwarded message reminds us that it is more than time that we write
> another SPF standard. By "we" I vaguely mean this list. Of course someone
> should take the burden to actually operate the required IETF procedures.
>
> Frank and Wayne have submitted relevant RFC errata. Are Wayne and Meng, the
> authors of the current RFC, still on this list? Did they say they are not
> going to [co-]author a new release? If yes, is that the origin of the
> RFC5378-related problem?

Why is it necessary to write a new standard? It works well, and
education on things like handling secondary MXes (and "forwarders")
properly when checking SPF is what is needed.

Or is it just a matter of incorporating the errata?

If we start throwing v=spf3 records out there, then that will begin to
double the amount of DNS TXT/SPF data flying around. There had
better be a good reason beyond adding our favorite features
(like ! prefix for NOT on mechanisms :-) ).

--
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:
> On Tue, 13 Jan 2009, Alessandro Vesely wrote:
>
>> Scott Kitterman 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.
>>
>> The forwarded message reminds us that it is more than time that we write
>> another SPF standard. By "we" I vaguely mean this list. Of course someone
>> should take the burden to actually operate the required IETF procedures.
>>
>> Frank and Wayne have submitted relevant RFC errata. Are Wayne and Meng, the
>> authors of the current RFC, still on this list? Did they say they are not
>> going to [co-]author a new release? If yes, is that the origin of the
>> RFC5378-related problem?
>
> Why is it necessary to write a new standard? It works well, and
> education on things like handling secondary MXes (and "forwarders")
> properly when checking SPF is what is needed.

The current RFC is not a standard, it's only experimental. I don't
think it is possible to promote it to a standard without writing a new
I-D.

> Or is it just a matter of incorporating the errata?

That's the minimum.

> If we start throwing v=spf3 records out there, then that will begin to
> double the amount of DNS TXT/SPF data flying around. There had
> better be a good reason beyond adding our favorite features
> (like ! prefix for NOT on mechanisms :-) ).

I agree v=spf3 will annoy many hostmasters, but I see no other recipe
to unilaterally resolve the observed conflict, namely that rfc4406
attaches the unintended "pra" scope-id to version v=spf1.

However, we might avoid doubling the data. I expand on this in my next
message...


-------------------------------------------
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:52 19/01/2009 Monday, Alessandro Vesely wrote:
><snip>
>
>I agree v=spf3 will annoy many hostmasters, but I see no other recipe
>to unilaterally resolve the observed conflict, namely that rfc4406
>attaches the unintended "pra" scope-id to version v=spf1.
>
>However, we might avoid doubling the data. I expand on this in my next
>message...

I agree with an adendum {my own observations ;) }

for this i'm excluding softfail and neutral as only discussing {to my mind} important edge cases

first off between spf and sender-id there are 3 scopes

1 helo
2 mfrom
3 pra

1-2 spf 2-3 sender-id

for helo records now a simple pass/fail should be the only ever required response
{but as many have both helo and mfrom for the one domain an additional "doesn't exist anywhere" would be nice}

for mfrom in an ideal {everyone runs SRS} world it will only require pass/fail
but as ideal world not here it would be useful to have pass/fail/dosn't-exist

for pra even in an SRS only world many may have to go with neutral, but in theory it also would be
nice to differentiate between fail-policy and address-dosn't exist

this edge case being domains where they use an existing spf of say
example.com txt "v=spfv1 redirect=%{l}._spf1.example.com"
example.com txt "v=spfv2 redirect=%{l}._spf2.example.com"

and then say has spf for each user that exists
example._spf1.example.com txt "v=spfv1 ptr:example.com include:gmail.com -ALL"
; note also allows gmails and example.com to forge helo of "example._spf1.example.com" which is sub-optimal {but unlikely in this case due to _ }

example._spf2.example.com txt "v=spfv2/mfrom ptr:example.com -ALL"
example._spf2.example.com txt "v=spfv2/pra ptr:example.com ?ALL"
;{example dosn't like pra and thus discourages}

and a

*._spf1.example.com txt "v=spfv1 -ALL"
*._spf2.example.com txt "v=spfv2 -ALL"

thus if example@example.com sends an email via a non-SRS forwarder to an isp that dosn't allow its users to whitelist their forwarders {gmx.de springs to mind}
it is indistinguishable from an email with totalybogus@example.com {by return code}

now i propose if we were to combine into an spfv3 we would add the additional limited use #/*/! or any other appropriate character for an extra return code of "absolutly forgery" for use in the edge cases of

*._spf1.example.com txt "v=spfv3 #ALL"

and for ones like

www.example.com txt "v=spfv3 #ALL"

but adopt some of the granularity of multiple txt records in sender-id

so mx10.example.com can have

mx10.example.com txt "v=spfv3/helo A -ALL"
mx10.example.com txt "v=spfv3/mfrom,pra #ALL"

assuming it sends bounces from postmaster@example.com {thus no valid addresses in @mx10... domain}

and example.com can be

example.com txt "v=spfv3/helo #ALL"
example.com txt "v=spfv3/mfrom,pra redirect=%{l}._spf3.example.com"

additionally it doesn't seem to break any sender-id or spf-v1 client i have tested so should be easy to early-deploy
and think the unifying of the 2 will make it faster to roll out to all those currently having to deal with both

obviously use of the # with any exceptions placed previously breaks the point so should cause a syntax error if pre-ceeded by anything other than redirects in the chain




-------------------------------------------
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, 13 Jan 2009 14:57:04 -0500 (EST) "Stuart D. Gathman"
<stuart@bmsi.com> wrote:
>On Tue, 13 Jan 2009, Alessandro Vesely wrote:
>
>> Scott Kitterman 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.
>>
>> The forwarded message reminds us that it is more than time that we write
>> another SPF standard. By "we" I vaguely mean this list. Of course someone
>> should take the burden to actually operate the required IETF procedures.
>>
>> Frank and Wayne have submitted relevant RFC errata. Are Wayne and Meng,
the
>> authors of the current RFC, still on this list? Did they say they are not
>> going to [co-]author a new release? If yes, is that the origin of the
>> RFC5378-related problem?
>
>Why is it necessary to write a new standard? It works well, and
>education on things like handling secondary MXes (and "forwarders")
>properly when checking SPF is what is needed.
>
>Or is it just a matter of incorporating the errata?
>
>If we start throwing v=spf3 records out there, then that will begin to
>double the amount of DNS TXT/SPF data flying around. There had
>better be a good reason beyond adding our favorite features
>(like ! prefix for NOT on mechanisms :-) ).
>

I agree. The one hard bug in the current spec that I think drives us to
needing a new RFC (but not a new record type) is the treatment of all DNS
errors as temperrors. Not all DNS errors are temporary. I've had to not
default to deferring on temperror for this reason.

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

just a quick reply to my own reply
re the whole v=spf3 stuff

several have commented with all the v1 and v2 records in place and now a v3 on top
will add too much byteweight to the response to a query for UDP to handle efficiently {or at all in some cases}

this is a serious issue {was my problem with spf originally as it broke my standard of adding txt and rp records to most hosts
{now just rp pointing to a txt container}

so should we be considering a standard sub-zone for spf going forward?

like _spfvX.domain-to-be-checked

so only v3 records {or future versions in that sub-zone, thus record-byte-weight becomes a non-factor}
additionally NXDOMAIN is a quick no spfvX check {as opposed to grabbing text and parsing for spfvX}
which overtime {when fallback to spfv1 and sender-id depreciates} will make grabbing txt from domains with no spf but other txt records, less time consuming to search.

I'm thinking along the lines of CSA or other marid stuff

just a thinking out loud excersise.....



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

My 2ct, user hat on:

summary:
Make sure MS understands and agrees that v=spf1 is not equivalent to
spf2.0/mfrom,pra.
Publish a new RFC, mostly the same as RFC4408, but with its current issues
repaired. The preferred resource record type is 'SPF', with resource record
type 'TXT' being phased out in some well defined time.



I think the following needs to be done:

1: Work out the issue MS caused. Reusing 'our' records may be fine (I still
think it isn't, layer separation), but doing so in an incompatible manner is
most certainly not. I strongly opt for SPF to deal with the message
transaction (RFC821) and SenderID with the content/headers (RFC822). That
is, if enough people find SenderID worth continuing. I have no insight in
the SenderID experiment, if that experiment is considered a failure then
there's nothing to solve.

Problem observed in the wild: Messages being flagged as forged, despite that
from an SPF perspective everything was okay. One often seen case is a
mailing list which sends the message using its own RFC821 mail from, but
keeps the RFC822 From as is. No problem for SPF, it is a problem for
SenderID, but the domain owner did NOT publish a SenderID record.

Of course MS is welcome to implement SPF, but do so as is written out in the
spec.

2: get rid of TXT. It was nice to experiment with, but now that we have our
own resource record type, it should be used exclusively. During some amount
of time, say a couple of years, the TXT RR could function as a fall back,
but it should be clear that this is going to be phased out.

I strongly urge MS to _NOT_ adopt the SPF RR for their own protocols. This
to avoid future clashes, no matter how well meant.

3: no new features. The transition to true SPF policies in true SPF resource
records is hard enough.

4: I don't see a reason to get rid of features.





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

Alex van den Bogaerdt wrote:
>
> 2: get rid of TXT. It was nice to experiment with, but now that we have
> our own resource record type, it should be used exclusively. During some
> amount of time, say a couple of years, the TXT RR could function as a
> fall back, but it should be clear that this is going to be phased out.

If that's the way to go, perhaps it is better to do it right in the
new RFC. It should aim at the standard track, replacing the
experimental 4408.

Of course, I agree that the new spec shall strive for compatibility
and ease of migration as far as possible. However, we must not fear to
learn lessons from the experimental phase. I think John Leslie
expresses the thoughts of many of the well-disposed SPF users when he
writes:

" SPF has been due for its 2-year review (of Experimental Status)
" for a while now. Hopefully it will get a useful review, and I choose
" to hope it will get enough of an overhaul to become useful.
http://www.irtf.org/pipermail/asrg/2009-January/004525.html


-------------------------------------------
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 would also echo support for the dropping of the TXT RR in favor of
the SPF RR in DNS host files. As SPF moves from an experimental
phase to a standards track, the standard should certainly fully
encourage the adoption and use of the SPF RR created specifically for
its use by the DNS standards participants.

Given the issue discovered in DNS last year, which essentially
required suppliers of DNS server software to address and update their
software, one would think that any serious DNS operators would have
migrated to the new fixed DNS server versions. One would also think
that suppliers of DNS servers would also have added support for SPF
RR as a valid and accepted RR type in current DNS software per the
RFCs governing standards for DNS in their current releases. Thus on
most all DNS servers, one might conclude that there should already be
direct support the SPF RR.

The only other concern I could foresee regards support for the SPF RR
requests from SMTP server software suppliers already supporting
SPF. In order to continue to supporting existing host file records
not updated to the SPF RR, those servers must support a "dual track"
TXT and SPF RR for host files. That said, as part of the new
standard, it should be made clear that the SPF RR must be the first
checked RR followed by the TXT RR.

Once those who maintain SPF TXT records in their host files begin to
observe the trend for SPF RR requests being issued first and then
followed by the TXT RR requests (presuming they do not have an SPF RR
setup in their host files), they will add the SPF RR to avoid the
extra request pattern on their DNS servers.

Thus over time, the need to maintain a TXT record in host files
should naturally diminish without impacting or breaking existing environments.

Best,

Alan Maitland

At 10:10 AM 1/20/2009, you wrote:
>Alex van den Bogaerdt wrote:
>>2: get rid of TXT. It was nice to experiment with, but now that we
>>have our own resource record type, it should be used exclusively.
>>During some amount of time, say a couple of years, the TXT RR could
>>function as a fall back, but it should be clear that this is going
>>to be phased out.
>
>If that's the way to go, perhaps it is better to do it right in the
>new RFC. It should aim at the standard track, replacing the experimental 4408.
>
>Of course, I agree that the new spec shall strive for compatibility
>and ease of migration as far as possible. However, we must not fear
>to learn lessons from the experimental phase. I think John Leslie
>expresses the thoughts of many of the well-disposed SPF users when he writes:
>
>" SPF has been due for its 2-year review (of Experimental Status)
>" for a while now. Hopefully it will get a useful review, and I choose
>" to hope it will get enough of an overhaul to become useful.
>http://www.irtf.org/pipermail/asrg/2009-January/004525.html
>
>
>-------------------------------------------
>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

> Given the issue discovered in DNS last year, which essentially
> required suppliers of DNS server software to address and update
> their software, one would think that any serious DNS operators would
> have migrated to the new fixed DNS server versions. One would also
> think that suppliers of DNS servers would also have added support
> for SPF RR as a valid and accepted RR type in current DNS software
> per the RFCs governing standards for DNS in their current releases.
> Thus on most all DNS servers, one might conclude that there should
> already be direct support the SPF RR.

What's with this "one might" and "one would" high-falutin'? Just do
some research (if you're not afraid to find out you're wrong).

As of Oct 2008, post-Kaminsky, the Measurement Factory survey reported
that under 7% of authoritative servers were running a version of BIND
that supports Type 99 (9.4+).

Approximately 15% more use djb/My/Simple/Power, which at least support
Type 99 in their latest versions (versions for these are not given).

26% of servers are totally unclassified. Given earlier survey results,
I believe there to be at least another 1-3% of MS DNS in there (the
classifiable servers are < 1% MS DNS), and none of those support Type
99.

Anyway, add in half of the unclassified BINDs, plus half of the
totally unknown servers, and even at this surely inflated level,
you're talking about 45% SPF RR support. That isn't "most all DNS
servers" (whatever that means). It's almost "most".

http://dns.measurement-factory.com/surveys/200810.html

I would not argue with your wishful thinking, but that's not what we
should deal with here.

--Sandy



-------------------------------------------
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'll add that ... Kaminsky ... and they updated to the latest versions
isn't my experience.

For the pydns (python-dns) I did an initial implementation of the "Fix" as
a distro developer for Debian/Ubuntu. I took an unreleased TID change
upstream had In svn and did an initial source port randomization
implementation and patched not only the current release but older versions
in Debian Stable and 5 supported Ubuntu releases. The updates went to all
Debian/Ubuntu users using a supported release. While I may not have been
as strictly minimalistic as I should have been and cleaned up a couple of
bugs along the way, I can guarantee no extra SPF RR processing slipped in.

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

Sandy,

At 01:25 PM 1/20/2009, you wrote:
> > Given the issue discovered in DNS last year, which essentially
> > required suppliers of DNS server software to address and update
> > their software, one would think that any serious DNS operators would
> > have migrated to the new fixed DNS server versions. One would also
> > think that suppliers of DNS servers would also have added support
> > for SPF RR as a valid and accepted RR type in current DNS software
> > per the RFCs governing standards for DNS in their current releases.
> > Thus on most all DNS servers, one might conclude that there should
> > already be direct support the SPF RR.
>
>What's with this "one might" and "one would" high-falutin'? Just do
>some research (if you're not afraid to find out you're wrong).

First, everyone has style differences and "launching" on someone for
a style issue is counterproductive. There have been one or two list
members over the years whose style was abrasive for me, but you learn
about the person and either their styles become comfortable or you
ultimately just pay less attention to them.

As I did not have the data at my fingertips to make declarative
statements in my last message, I qualified them.

I am always happy to get pointed to data which either refutes me when
I draw incorrect conclusions or which reinforce them. So, I'm
certainly not afraid to find out I'm wrong, because it just brings up
another discussion to work through to solve the problem where my
premise was incorrect. I also did not want to be perceived as being
insulting or rude in any way to the DNS supplier community, who have
been generous to the SPF project in their support of 99/SPF RRs.

>As of Oct 2008, post-Kaminsky, the Measurement Factory survey reported
>that under 7% of authoritative servers were running a version of BIND
>that supports Type 99 (9.4+).
>
>Approximately 15% more use djb/My/Simple/Power, which at least support
>Type 99 in their latest versions (versions for these are not given).
>
>26% of servers are totally unclassified. Given earlier survey results,
>I believe there to be at least another 1-3% of MS DNS in there (the
>classifiable servers are < 1% MS DNS), and none of those support Type
>99.
>
>Anyway, add in half of the unclassified BINDs, plus half of the
>totally unknown servers, and even at this surely inflated level,
>you're talking about 45% SPF RR support. That isn't "most all DNS
>servers" (whatever that means). It's almost "most".
>
>http://dns.measurement-factory.com/surveys/200810.html

Having looked at your link, it is pretty clear that we (both SPF and
DNS communities) need to do a better job in educating people on the
importance of upgrading their DNS servers to current levels, so as to
be more responsible DNS server operators. As with any system, breaks
happen at weak links.

To be more colloquial and hopefully, Sandy will take this in the
light hearted spirit it is intended; broken a** out of date DNS
software is certainly a big a** honking weak link for the Internet.

Even so, it is another opportunity. Does anyone know if Measurement
Factory would actually part with detailed IP addresses and WHOIS data
on the DNS servers that are arguably mustang? If so, perhaps keeping
a central registry for those IPs might help them to migrate because
in their current state (as they can be corrupted), they are not
trustworthy for answers they provide.

If not, perhaps they would take on the task of getting the word out
about these networks who seem to be running sub par operations.

Often things like this are either related to ignorance of a problem
or lack of time. The first can be fixed with education, the latter
perhaps in pushing a point.

>I would not argue with your wishful thinking, but that's not what we
>should deal with here.

I really don't think it a case of wishful thinking to suggest that
moving the spec to 99/SPF as the primary request type over TXT. It
is the logical path where things will eventually go.

My point was that it should take place now in the SPF spec, because
it encourages the right behavior in implementations and guidance for
those who implement SPF. The folks who implement DNS were kind
enough to establish 99/SPF RRs for this very group, it might be nice
for the SPF standard to keep moving things forward by promoting their use.

Further, it might yet help and encourage those who are seemingly poor
administrators and who have not updated their DNS servers to upgrade
to a more secure version.

>--Sandy

Best,

Alan



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

just a quick reply to my own reply to my own reply
re the whole v=spf3 stuff

>several have commented with all the v1 and v2 records in place and now a v3 on top
>will add too much byteweight to the response to a query for UDP to handle efficiently {or at all in some cases}
>
>this is a serious issue {was my problem with spf originally as it broke my standard of adding txt and rp records to most hosts
>{now just rp pointing to a txt container}
>
>so should we be considering a standard sub-zone for spf going forward?

no its simpler to fix than that
just recommend anyone doing more than 1 form of spf and/or sender-id remembers about the issue and divides his records(s) appropriately
like thus

domain.tld IN SPF "v=spf1 redirect=_spf1.%{o}"
domain.tld IN SPF "v=spf3 redirect=_spf3.%{o}"

domain.tld IN TXT "v=spf1 redirect=_spf1.%{o}"
domain.tld IN TXT "spf2.0/mfrom,pra redirect=_spf2.%{o}"
domain.tld IN TXT "v=spf3 redirect=_spf3.%{o}"

thus delegating/controlling his own sub-zone delegation and one initial lookup gives all that a client needs to determine highest supported version to further query

thus well under the byte weight issue well into later versions if people still want to cater for all backwards compatibility
but honestly think to kill sender-id we need to do the Microsoft thing and embrace-extend-extinguish

so include it in the spec with
v=spf3 == v=spf3/mfrom,helo,pra

but those not wanting to touch sender id then just publish
v=spf3/mfrom,helo

thus killing any pra checks with no record found
or
v=spf3/mfrom,helo "traditional spf record"
v=spf3/pra +all

saying loud you want to positively pass pra checks from any source

or if like me you are pedantic and would like to keep all roles separate
v=spf3/mfrom "traditional spf record"
v=spf3/helo -all {helo as my top level domain I think not!}
v=spf3/pra +all {not drinking the sender-id cool-aid thanks}



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

WebMaster@Commerco.Net wrote:
> At 01:25 PM 1/20/2009, Sandy wrote:
>> Anyway, add in half of the unclassified BINDs, plus half of the
>> totally unknown servers, and even at this surely inflated level,
>> you're talking about 45% SPF RR support. That isn't "most all DNS
>> servers" (whatever that means). It's almost "most".
>> [...]
>> I would not argue with your wishful thinking, but that's not what we
>> should deal with here.
>
> I really don't think it a case of wishful thinking to suggest that
> moving the spec to 99/SPF as the primary request type over TXT. It is
> the logical path where things will eventually go.

The new spec should move to 99/SPF as the _only_ request type. It may
mention compatibility issues with the experimental rfc (to specify
limiting dates would really be wishful thinking, though.)

I'm currently using the stock debian bind, without SPF RR support. So
what? Switching to the new spec will not happen suddenly, and people
will have plenty of time for upgrading. OTOH, to standardize that the
same data should be repeated twice in two distinct RRs is grotesque.

DNS queries might also differ in the new spec. It has been noted that
hostmasters usually don't define SPF records for each host. Although I
agree that better doc/evangelism may help, we should ease SPF adoption
rather than making it more complicated than it needs. I wish the new
specs provide for one or more of

1) recommend using wildcard DNS records, see rfc4592 (nb: 4592>4408),
2) mandate the "zone cut" algorithm in clients, and
3) set a default _spf.<domain> name, where <domain> is the SOA MNAME
of a failed query.


Below, some pointers to interesting old discussions:


26 Apr 2004, Wayne and Meng agree that _not_ having the zone cut
algorithm "is very yucky"
http://www.listbox.com/member/archive/735/2004/04/search/em9uZSBjdXQ/sort/subj/page/1/entry/0:1/4462669/

21 Jun 2004, "match_subdomains=yes" wording
http://www.listbox.com/member/archive/735/2004/06/search/em9uZSBjdXQ/sort/subj/page/1/entry/0:1/5258624/

18 Oct 2004, "zone cut" in the list of requested changes
http://www.listbox.com/member/archive/735/2004/10/search/em9uZSBjdXQ/sort/subj/page/1/entry/10:11/7043237/

07 Nov 2004, worries for the wizard not handling the zone cut
http://www.listbox.com/member/archive/735/2004/11/search/em9uZSBjdXQ/sort/subj/page/1/entry/6:12/7310336/

26 Dec 2004, delegated SPF as redirect
http://www.listbox.com/member/archive/735/2004/12/search/em9uZSBjdXQ/sort/subj/page/1/entry/1:16/7848208/

14 Jan 2005, pros and cons
http://www.listbox.com/member/archive/735/2005/01/search/em9uZSBjdXQ/sort/subj/page/1/entry/9:22/8036442/

23 Feb 2005, zone cut default algorithm should not be used by SPFv1
http://www.listbox.com/member/archive/735/2005/02/search/em9uZSBjdXQ/sort/subj/page/1/entry/0:15/8458725/

24 Feb 2005, "left-to-right stuff"
http://www.listbox.com/member/archive/735/2005/02/search/em9uZSBjdXQ/sort/subj/page/1/entry/4:15/8462290/



-------------------------------------------
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 Wed, 21 Jan 2009, alan wrote:

> >several have commented with all the v1 and v2 records in place and now a v3 on top
> >will add too much byteweight to the response to a query for UDP to handle efficiently {or at all in some cases}
> >
> >this is a serious issue {was my problem with spf originally as it broke my standard of adding txt and rp records to most hosts
> >{now just rp pointing to a txt container}
> >
> >so should we be considering a standard sub-zone for spf going forward?
>
> no its simpler to fix than that
> just recommend anyone doing more than 1 form of spf and/or sender-id remembers about the issue and divides his records(s) appropriately
> like thus
>
> domain.tld IN SPF "v=spf1 redirect=_spf1.%{o}"
> domain.tld IN SPF "v=spf3 redirect=_spf3.%{o}"
>
> domain.tld IN TXT "v=spf1 redirect=_spf1.%{o}"
> domain.tld IN TXT "spf2.0/mfrom,pra redirect=_spf2.%{o}"
> domain.tld IN TXT "v=spf3 redirect=_spf3.%{o}"

That puts all that TXT data into a UDP packet - thus the "byteweight" problem.
One suggesting that *would* help is the standard subdomain:

_spf.domain.tld IN SPF "v=spf3 ..."

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

>> domain.tld IN TXT "v=spf1 redirect=_spf1.%{o}"
>> domain.tld IN TXT "spf2.0/mfrom,pra redirect=_spf2.%{o}"
>> domain.tld IN TXT "v=spf3 redirect=_spf3.%{o}"
>
> That puts all that TXT data into a UDP packet - thus the "byteweight"
> problem.

Correct, especially if there are other TXT records which have nothing to do
with either SPF or SenderID.

> One suggesting that *would* help is the standard subdomain:
>
> _spf.domain.tld IN SPF "v=spf3 ..."

Do we really want to make such changes to the protocol? I feel that we
should continue with the protocol as designed, using the momentum we now
have.



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


-------------------------------------------
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 would not argue with your wishful thinking, but that's not what we
>>should deal with here.
>
>I really don't think it a case of wishful thinking to suggest that moving the spec to 99/SPF as the primary request type over TXT. It is the logical path where things will eventually go.
>
>My point was that it should take place now in the SPF spec, because it encourages the right behavior in implementations and guidance for those who implement SPF. The folks who implement DNS were kind enough to establish 99/SPF RRs for this very group, it might be nice for the SPF standard to keep moving things forward by promoting their use.

The standard needs to declare the long term goals and direction, and what
is "preferred" (i.e. "correct") Putting the new RR in the new spec
is the right thing to do.

That said, keeping the TXT records around is essential. No matter how new
people's DNS servers are, changing thousands (or millions?) of domains will
require work to be done by a very large number of people, and updating their
TXT RR to SPF RR is not likely to be on the top of their lists.

It is simply not going to be completed any time soon.

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.

-dgl-


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


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

It won't be forever. That's being silly.
Eventually, Entropy will prevail, and the heat death of the universe will get
us. We should plan for things on that timescale, though. ;->

-dgl-


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

----- Original Message -----
From: "Don Lee" <spfdiscuss@caution.icompute.com>
To: <spf-discuss@v2.listbox.com>
Sent: Saturday, January 24, 2009 1:29 AM
Subject: Re[2]: [spf-discuss] back to Reclassifying Sender ID and SPF as
Historic - was: New SPF Council


>>>I would not argue with your wishful thinking, but that's not what we
>>>should deal with here.
>>
>>I really don't think it a case of wishful thinking to suggest that moving
>>the spec to 99/SPF as the primary request type over TXT. It is the
>>logical path where things will eventually go.
>>
>>My point was that it should take place now in the SPF spec, because it
>>encourages the right behavior in implementations and guidance for those
>>who implement SPF. The folks who implement DNS were kind enough to
>>establish 99/SPF RRs for this very group, it might be nice for the SPF
>>standard to keep moving things forward by promoting their use.
>
> The standard needs to declare the long term goals and direction, and what
> is "preferred" (i.e. "correct") Putting the new RR in the new spec
> is the right thing to do.

I disagree. A standard declares how stuff is done. It isn't a long term
goal, it isn't a direction where things should go.

The standard should IMHO acknowledge the current install base from the
experiment which was conducted. But that's just it: an experiment, which was
useful, and which should end.

I see two ways forward:

1: do not declare sunset for SPF-in-TXT. Do mention TXT in an 'historic'
section, but do not allow it in the protocol. Let the implementors decide
how long they should support the RFC4408 experiment. Disadvantage: there
will be DNS software which doesn't yet know how to handle the SPF RR.

2: do declare sunset for SPF-in-TXT. Advantage: everybody agrees on what
time frame we're talking about. Disadvantage: if the protocol is slightly
different, both versions need to be discussed.


> That said, keeping the TXT records around is essential. No matter how new
> people's DNS servers are, changing thousands (or millions?) of domains
> will
> require work to be done by a very large number of people, and updating
> their
> TXT RR to SPF RR is not likely to be on the top of their lists.

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.

Yes, this requires work, but it's not like it is a huge task. In many cases
it will be changing 'TXT' in 'SPF', either using an editor or by mouse
clicking a drop down box.

Some people will do so soon. No problem here, provided that they get enough
time.
Some people won't bother, ever. No problem here either. If they're not
interested in SPF anymore, they aren't updating their record in any way, we
shouldn't concern ourselves with them.
Some people will postpone the work as long as they can, as long as they are
allowed to. Give them ten years and they use eleven, give them 100 years and
they won't ever do the job.


> It is simply not going to be completed any time soon.

What is soon?

> 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 is a very long time?

You aren't talking about a couple of years, else you wouln't have needed to
write your message. But what time frame do you have in mind, and please use
numbers in correlation with the word 'years'.



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

Alex van den Bogaerdt wrote:
> The standard should IMHO acknowledge the current install base from the
> experiment which was conducted. But that's just it: an experiment, which
> was useful, and which should end.

That's also my feeling.

> I see two ways forward:
>
> 1: do not declare sunset for SPF-in-TXT. Do mention TXT in an 'historic'
> section, but do not allow it in the protocol. Let the implementors
> decide how long they should support the RFC4408 experiment.
> Disadvantage: there will be DNS software which doesn't yet know how to
> handle the SPF RR.
>
> 2: do declare sunset for SPF-in-TXT. Advantage: everybody agrees on what
> time frame we're talking about. Disadvantage: if the protocol is
> slightly different, both versions need to be discussed.

We need at least one difference, clarifying the mfrom,pra default of
spf2.0. Since that is not part of the historical section, it is
obviously valid in the SPF RR only. This kind of sunset does not
indicate a future date, but it indicates a functionality.

As an example of added functionality, the new spec may add yet another
scope, say vfrom (visible from), which is tougher than pra as it
cannot be circumvented with resent-* headers. Roughly, let's say it
mandates to check any @ in the From header, so that a value of
"support @ paypal.com" <another@malware.net> results in two lookups,
and if any of those has a vfrom the check fails, or something to the
same effect. Only banks and bots would want to declare that. Only SPF
RRs should be looked up for that, as the old spec provides no vfrom.
(However, some implementations SPF-check the From header already.)

>> That said, keeping the TXT records around is essential. No matter how
>> new people's DNS servers are, changing thousands (or millions?) of domains
>> will require work to be done by a very large number of people, and updating
>> their TXT RR to SPF RR is not likely to be on the top of their lists.
>
> 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.

The new functionality, as the one exemplified above, should be
appealing for receivers. If they want it, they have to upgrade their
DNS. And, if the upgrade is related to security, it may enjoy a
quicker upgrade path.

Possibly, most receivers will continue trying TXT lookups after SPF
fails, until the rate of success that they get that way is somewhat
meaningful. When receivers find a TXT record, they apply the old
specs. Changes to the protocol should be conceived so that it is
relatively easy to revamp existing software in order to behave like so.



-------------------------------------------
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, 24 Jan 2009 09:29:32 +0100 "Alex van den Bogaerdt"
<alex@ergens.op.het.net> wrote:
...
>The standard should IMHO acknowledge the current install base from the
>experiment which was conducted. But that's just it: an experiment, which
was
>useful, and which should end.
...

SPF is not an experimental protocol. The "experiment" was an IETF method
to not have to sort out the conflicts between SPF and Sender ID for a few
years in the hope the mess would just go away.

I don't mind going to the IESG with the results of the "experiment", but
let's not be confused ourselves.

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

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

Let's deal with protocol enhancements later.

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