Subject: [spfbis] WGLC: draft-ietf-spfbis-4408bis-14

From: Douglas Otis <[email-masked]>
Date: Thu, 16 May 2013 18:08:27 -0700

Dear SPFbis WG,

An I-D has been submitted offering a review of the SPFbis draft.

http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-00

Sorry for the delay in preparing this document.  There was a fair amount of botnet activity requiring a fair amount of attention.

Regards,
Douglas Otis

---

From: S Moonesamy <[email-masked]>
Date: Thu, 16 May 2013 19:45:13 -0700

At 18:08 16-05-2013, Douglas Otis wrote:
>Sorry for the delay in preparing this document.  There was a fair 
>amount of botnet activity requiring a fair amount of attention.

There are still some previous reviews to address.  I am waiting for 
that to be done.  I suggest that the working group does not discuss 
about draft-otis-spfbis-macros-nixed-00 for now.  Please note that 
the comments in draft-otis-spfbis-macros-nixed-00 are not being ignored.

Regards,
S. Moonesamy (as SFBIS WG co-chair)

---

From: S Moonesamy <[email-masked]>
Date: Tue, 28 May 2013 13:16:06 -0700

Hello,

Douglas Otis submitted draft-otis-spfbis-macros-nixed-00 [1] as WGLC 
comments about draft-ietf-spfbis-4408bis-14.  Could the SPFBIS WG 
please read the draft-otis-spfbis-macros-nixed-00 and comment about it?

Regards,
S. Moonesamy (as SPFBIS WG co-chair)

1. http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-00

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 May 2013 14:15:59 -0700

On Tue, May 28, 2013 at 1:16 PM, S Moonesamy <[email-masked]> wrote:

> comments about draft-ietf-spfbis-4408bis-14.  Could the SPFBIS WG please
> read the draft-otis-spfbis-macros-nixed-00 and comment about it?
>
>
I have reviewed the draft, as requested.  My responses:

Nixing macros based on non-use has already been debated at length, to the
point of a low-level appeal, and it's been decided that they're staying.
There's no action for the WG here based on that argument.

Beyond that, I disagree that macros "diminish" SPF's utility in any way;
their mere presence in the protocol doesn't render it less useful, as one
may simply not use them and still get useful results.

I would argue that DMARC, which makes use of SPF in a specific way, should
not influence SPF itself at this point as DMARC has no particular status
with the IETF yet.

The dropping of type 99 RRTYPE support was made for more reasons than just
"sparse use", so I don't find that part of Doug's arguments compelling.  I
think we reached consensus on that debate long ago, and it's been beaten to
death recently once again on the main IETF list.

The local-part macro attack has been discussed to death.  There's no new
information presented here that I can see.

Saying RFC6686 "failed to provide a breakdown on macro use" is to imply
that it should have.  Analysis of macro use was not part of the goal set of
that document, so it's strange to identify this as a failure.  However, I
still have those data available should there be some demonstrated purpose
for mining the data further.  Or, Doug can do his own survey and see what
he finds.

The document mentions use of macros given the advent of EAI, but I believe
the current spfbis document already deals with this in the same way DKIM
did.  Someone more expert in EAI than I am might want to confirm we've done
our due diligence there.

Overall, I don't think this draft introduces any new material such that the
WG needs to revisit anything since WGLC closed.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 May 2013 03:43:11 +0200

On 5/28/2013 11:15 PM, Murray S. Kucherawy wrote:
>
> Overall, I don't think this draft introduces any new material such that
> the WG needs to revisit anything since WGLC closed.

+1

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 28 May 2013 22:52:53 -0400

> > the WG needs to revisit anything since WGLC closed.
I've reviewed the document and the revision and I concur.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 May 2013 21:46:21 -0700

On May 28, 2013, at 2:15 PM, Murray S. Kucherawy <[email-masked]> wrote:

> Douglas Otis submitted draft-otis-spfbis-macros-nixed-00 [1] as WGLC comments about draft-ietf-spfbis-4408bis-14.  Could the SPFBIS WG please read the draft-otis-spfbis-macros-nixed-00 and comment about it?
> 
> 
> Nixing macros based on non-use has already been debated at length, to the point of a low-level appeal, and it's been decided that they're staying.  There's no action for the WG here based on that argument.

Dear Murray,

A pertinent point regarding the decision that receivers must process macros is whether it represents a reasonable demand.  SPF records containing macros can not cache results and will always necessitate reprocessing.  If macro processing is skipped, any expectation of preserving interchange is lost.  In other words, it is broken by design by asking too much from receivers.
   
> Beyond that, I disagree that macros "diminish" SPF's utility in any way; their mere presence in the protocol doesn't render it less useful, as one may simply not use them and still get useful results.

When the main purported use is to determine a domain's outbound IP addresses, macros preclude this prevalent use offering the greatest utility, bar none.

> I would argue that DMARC, which makes use of SPF in a specific way, should not influence SPF itself at this point as DMARC has no particular status with the IETF yet.

DMARC does not differ in how many hoped to make use of SPF.  Desired use is very much at odds with stated SPF processing which is likely to require subsequent reprocessing, with increased burdens and layer violations.   

> The dropping of type 99 RRTYPE support was made for more reasons than just "sparse use", so I don't find that part of Doug's arguments compelling.  I think we reached consensus on that debate long ago, and it's been beaten to death recently once again on the main IETF list.

Mark Andrews made good points about increasing use of SPF 99 not shown in your survey.  The general goal should be to ensure unknown RR types are accommodated.  Unfortunately, some vendors still don't.

> The local-part macro attack has been discussed to death.  There's no new information presented here that I can see.
> 
> Saying RFC6686 "failed to provide a breakdown on macro use" is to imply that it should have.  Analysis of macro use was not part of the goal set of that document, so it's strange to identify this as a failure.  However, I still have those data available should there be some demonstrated purpose for mining the data further.  Or, Doug can do his own survey and see what he finds.

IMHO, it was wrong (a failing) to limit a review of SPF to answer only whether the PRA mode was being used.  This review should have also focused on both macro publication and macro processing.  Whether it is local-part macro or any other macro, cached results are not useful and much of the SPF utility for defining a domain's outbound address space is lost.  Since there is only 0.053% of domains using macros, it becomes an easy trade-off some providers make.  They even have stated ignoring SPF records containing macros do not result in complaints.

> The document mentions use of macros given the advent of EAI, but I believe the current spfbis document already deals with this in the same way DKIM did.  Someone more expert in EAI than I am might want to confirm we've done our due diligence there.

It can no longer be assumed domains will be encoded as A-labels. In addition, it can not be assumed the local-part will be ASCII.  Such changes can place spf libraries at risk.  In a quick review, it seems some unused features in the libraries might permit induced buffer overruns.  Adding in additional conversion libraries introduces more risk which might compromise SMTP servers.  Nothing justifies these types of risks to support something that is practically unused.  

> Overall, I don't think this draft introduces any new material such that the WG needs to revisit anything since WGLC closed.

The macros nixed draft was just updated to better clarify these concerns.

http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 28 May 2013 23:52:54 -0700

> http://tools.ietf.org/html/draft-otis-spfbis-macros-nixed-01
For the record, I've reviewed the revision and your reply, and I have
nothing to add.

-MSK

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 May 2013 16:28:54 +0200

> For the record, I've reviewed the revision and your reply, and I have

This topic is not merely dead and buried.  It's fully decomposed. 
There's nothing left but dirt.  We should let it rest, less we have some 
agricultural aspirations.

d/

---

From: John Leslie <[email-masked]>
Date: Wed, 29 May 2013 10:36:35 -0400

NB: I tend to take Doug seriously, and feel he deserves more that "We
ignored him before: it's safe to ignore him again."

Douglas Otis <[email-masked]> wrote:
>> Nixing macros based on non-use has already been debated at length,
>> to the point of a low-level appeal, and it's been decided that
>> they're staying.  There's no action for the WG here based on that
>> argument.

   I am not willing to advocate their removal, but I think they deserve
to move a goodly way on the path to deprecation.

   They are indeed used (rarely), and are useful for some purposes not
particularly central to SPF. Forbidding their use in this SPFbis would
be going too far IMHO.

   Nonetheless, they remain a path to magnification of DoS. IMHO, folks
_will_ turn off SPF macro expansion when it becomes a common tactic for
DoS. (It's particularly nasty in that the initial request is free: a
simple TXT record in DNS for some quite unrelated domain can set off
at least ten seemingly-random DNS queries.)

   I quite agree it hasn't happened yet, and it doesn't seem likely to
happen in the next year or two. Nonetheless, it's there for the taking,
and it could become popular on rather short notice.

> A pertinent point regarding the decision that receivers must process
> macros is whether it represents a reasonable demand.

   "MUST process" strikes me as less than reasonable. The benefit to
the receiver which processes them is minuscule. The benefit to the
domain which publishes them can mostly be accomplished in a cheaper
way, and for the bulk of the other cases statistical sampling would
accomplish essentially as much: processing them for one case out of
a hundred would serve _very_ nicely.

> SPF records containing macros can not cache results and will always
> necessitate reprocessing.

   (I don't understand Doug's point here either.)

> If macro processing is skipped, any expectation of preserving
> interchange is lost. In other words, it is broken by design by
> asking too much from receivers.

   I do agree it asks too much of receivers.

>> Beyond that, I disagree that macros "diminish" SPF's utility in
>> any way; their mere presence in the protocol doesn't render it
>> less useful, as one may simply not use them and still get useful
>> results.

   Which is observed in the wild...

> When the main purported use is to determine a domain's outbound
> IP addresses, macros preclude this prevalent use offering the
> greatest utility, bar none.

   (I don't understand that sentence either.)

>> I would argue that DMARC, which makes use of SPF in a specific way,
>> should not influence SPF itself at this point as DMARC has no
>> particular status with the IETF yet.

   DMARC is heading toward an IETF status, though it seems premature
to react to it at this time.

> DMARC does not differ in how many hoped to make use of SPF.
> Desired use is very much at odds with stated SPF processing which
> is likely to require subsequent reprocessing, with increased burdens
> and layer violations.   
> 
>> The dropping of type 99 RRTYPE support was made for more reasons
>> than just "sparse use"...

   I'll not take that bait!

>> The local-part macro attack has been discussed to death.

   Well, to exhaustion anyway...

>> There's no new information presented here that I can see.

   I must admit I saw nothing to change my mind on that; but before
Doug's recent posts I already strongly believed that SPF macros deserve
a path towards deprecation.

>> Saying RFC6686 "failed to provide a breakdown on macro use" is to
>> imply that it should have...

   I have no opinion on that.

> IMHO, it was wrong (a failing) to limit a review of SPF to answer only
> whether the PRA mode was being used...

   No opinion on that either...

>> The document mentions use of macros given the advent of EAI, but I
>> believe the current spfbis document already deals with this in the
>> same way DKIM did...

   EAI is a minefield for DNS -- but is no worse for SPF.

> It can no longer be assumed domains will be encoded as A-labels...

   Alas, true; but again no worse for SPF than most other uses.

--
John Leslie <[email-masked]>

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 May 2013 16:42:35 +0200

> to move a goodly way on the path to deprecation.

John,

I think you've missed the rather basic IETF process point that has been 
explained at least twice in the latest round.  That is, we've already 
fully and painfully dealt with this topic.

It's not an open issue.  Therefore discussing it it wasting yours and 
our time.

Even our chairs have been motivated to note this fact explicitly.

d/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 May 2013 09:22:58 -0700

> ignored him before: it's safe to ignore him again."

I'm at a loss to understand how replying to his draft with a review of it
constitutes ignoring him.

> to move a goodly way on the path to deprecation.

Could you please explain what procedural path you propose we follow to do
so?  You were, I believe, paying attention when their removal or even
deprecation was proposed, argued, ruled out-of-charter, appealed, and put
down.  I would think at that point that the topic was de facto no longer
valid for this WG.  So, short of appealing the charter itself (which I
would argue is far, far past the point of being a reasonable course of
action), we would only be re-covering a well beaten path destined for the
same result.

> and it could become popular on rather short notice.

At best, you could propose text to add to the bis draft that discusses this
(if it's not already) and see if it can get working group consensus to stay
in.  It would've been nice to do this prior to WGLC or its completion, of
course, and it's up to the co-charis to decide whether to admit it all at
this point.

However, I suggest that rendering this entire portion of the protocol
"optional" will monkey with interoperability, so I would argue against such
a change.

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Wed, 29 May 2013 12:58:17 -0700

> particularly central to SPF. Forbidding their use in this SPFbis would

Dear John,

The WG had little problem deprecating SPF Resource Records, which actually enjoyed greater and growing use.  Clearly, this WG is not vested in preserving DNS.

However, efforts expended in creating a DNS based macro language and associated compilers makes it difficult for those vested in SPF macros to admit failure.  Such reluctance is understandable.  Several of the macro mechanisms have been given a "do not use" designation.  Unfortunately, such advice does not go far enough since it offers receivers no protection who are then expected to compile and resolve scripts from unknown sources.  Since macros are actually more likely to interfere with acceptance, their use has become negligible where even publishing macros will not ensure interchange.

> at least ten seemingly-random DNS queries.)

Correction: SPF can set off 100 seemingly random DNS queries. DoS may seem a minor concern compared to protecting server's resources from non-cachable DNS related overhead.  As such, some folks have already turned-off SPF macros.  The DoS issue may become more apparent when DNSsec is deployed to support DANE enabled StartTLS for SMTP while coping with IPv6.  

SPF does not support RFC6532 internationalized email, nor does suggesting RFC5890 in the specification properly deal with many possible security issues.  The SPF macro compiler will be dealing with non-ASCII strings that may occur within local-part parameters never intended to be DNS compliant, in addition to non-A-Label DNS.  It only requires a single buffer overrun to compromise an SMTP server.  It seems negligent to run SPF scripts outside of a sandbox when making substantial changes to basic SPF macro compiler inputs.  

> a hundred would serve _very_ nicely.

Agreed, and it only requires a few large providers to also reach this conclusion for macros to then break interchange...

>   (I don't understand Doug's point here either.)

When inputs into the SPF process include message elements beyond related domains,  re-executing the entire SPF process is the only compliant method.  If the SPF process were limited to just the related domain, then results could be cached by domain.  SPF macros may introduce label and local-part components that remove possible 1:1 domain/result relationships.   A 1:1 domain/result  relationship is restored when SPF macros are ignored.  Ignoring these macros convey many benefits to receivers and was asserted by AOL at the onset of SPF.

>   (I don't understand that sentence either.)

The greatest utility expressed by providers for SPF (which may list MX or hostname resources or simply offer CIDR notation) is to determine a domain's outbound address space.  Comparing this list against reputation services quickly ascertains potential problems.

When macros are used, ascertaining a domain's outbound address space can not be determined without also processing SPF macros in conjunction with message derived elements acting as inputs.  Use of macros can easily destroy this utility by introducing indeterminate unknowns, such as the IP addresses of the client, or some portion of the local-part. These elements may depend on indeterminately placed exists() resources.

> to react to it at this time.

A processing priority conflict will require revisiting SPF processing with different inputs more than once.  An inability to cache results against domains places greater emphasis on a need to immediately deprecate macros.  Now is the time for macro deprecation in all its aspects.

> a path towards deprecation.

Agreed.  The path offered by the WG does not protect receivers or ensure interchange primarily due to survey oversights, IMHO. 

>   I have no opinion on that.

Perhaps I should have said omitted any consideration of macro use, although oddly the same survey concluded that SPF RR types should be deprecated, without also noting an even greater disparity in macro publication.

>   EAI is a minefield for DNS -- but is no worse for SPF.

How will a new reference to RFC5890 ensure security is retained?  How will SPF macro compilers handle new inputs?  

>   Alas, true; but again no worse for SPF than most other uses.

The impact might be something fairly minor.  An encoding that expands differently in some library sub-component that then allows an SMTP server to be compromised.  How will this play with existing libraries, and how will this operate in conjunction with new changes?  Is it really safe to assume there will not be any problem?

As a side note, the macros-nixed I-D was made available earlier, but SM wanted to delay its review until after the WG concluded its revision process.  After all, there was every reason to believe the related concerns would be casually dismissed by the WG.  I'll make a few more changes to address some of the expressed confusion.

Any input or criticism either on or off the list is most welcome.  Thank you.

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 May 2013 16:21:45 -0400

I'm not sure whether I'm wearing any hat here.  

On Wed, May 29, 2013 at 12:58:17PM -0700, Douglas Otis wrote:
> 
> The WG had little problem deprecating SPF Resource Records, which
> actually enjoyed greater and growing use.  Clearly, this WG is not
> vested in preserving DNS.
> 
> However, efforts expended in creating a DNS based macro language and
> associated compilers makes it difficult for those vested in SPF
> macros to admit failure.  Such reluctance is understandable.

This analogy is, in my personal opinion, invidious.  

The reason the WG decided to deprecate the SPF RRTYPE is because RFC
4408 has an actual interoperability problem in it.  You may recall
that SM and I originally ruled that deprecation of the SPF RRTYPE was
_out_ of scope, on the grounds that it was "used".  Our interpretation
of "used" was that, if there was any evidence of deployment on the
network, then the feature was not unused, and therefore it was beyond
the scope of the WG's charter to deprecate the feature.  I think the
charter is crystal clear about this matter.  This decision was
appealed to the AD, who agreed with us (though not about the crystal clarity).

The only reason we decided that we had to do something with TYPE 99
was simply that there turned out to be an interoperability problem.
We had to do something backward-incompatible _no matter what_, so we
determined at that point that we should deprecate the least-used
RRTYPE.

In order to deprecate macros the same way, we would need some argument
as to why it would be acceptable to violate our charter in that way.
Otherwise, since there are some people using macros, they are still
used so we have to maintain them.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 May 2013 22:25:16 +0200

> This analogy is, in my personal opinion, invidious.

the thread is invidious, not just the analogy.

d/

---

From: S Moonesamy <[email-masked]>
Date: Wed, 29 May 2013 13:50:58 -0700

Hi Doug,
At 12:58 29-05-2013, Douglas Otis wrote:
>As a side note, the macros-nixed I-D was made available earlier, but 
>SM wanted to delay its review until after the WG concluded its 
>revision process.  After all, there was every reason to believe the 
>related concerns would be casually dismissed by the WG.  I'll make a 
>few more changes to address some of the expressed confusion.

I'll comment as an individual.  A summary of the WGLC for 
draft-ietf-spfbis-4408bis-14 was posted on April 24.  That is the 
date the WGLC ended.  The directorate/review team reviews arrived 
after that.  A reminder about addressing those reviews and the 
comments received during the WGLC was posted on April 30.  A message 
about draft-otis-spfbis-macros-nixed-00  was posted to the SPFBIS 
mailing list on May 16.  I was tracking the existing comments.  There 
are limits to what I can do. :-)

It is up to the SPFBIS working group to carefully consider the 
comments in draft-otis-spfbis-macros-nixed-01.  I don't think that it 
is a good idea to dismiss any concerns casually.  If you believe that 
the concerns you raised were not addressed correctly, please let me 
know so that I can bring it to the attention of the Area Director.

Regards,
S. Moonesamy

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 May 2013 07:26:01 +1000

> determined at that point that we should deprecate the least-used

And what has been done does NOT fix the perceived interoperability
problem.  There are lots of sites *using* type 99 some of which
don't publish TXT records despite the SHOULD.

The group is expecting those sites to suddenly replace those records
with TXT record.

There is no plan to get from where we are today back to TXT only.

There will forever be confusion about what record to use because
there will forever be a record called SPF which you do not use for
SPF.

Note even we have to use "type 99" to avoid this confusion.

> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 May 2013 17:42:34 -0400

Moderator hat.

Mark,

> And what has been done does NOT fix the perceived interoperability

If you're going to start a completely irrelevant thread to the thing
we are talking about, do you think you might at least change the
subject line?

The RRTYPE discussion has been closed in this WG; we made a decision
some time ago.  You have not presented any new arguments, as nearly as
I can tell, for revisiting that decision, so I don't think it is
reasonable to reopen the discussion.  But if you plan to do so, please
at least don't drag that red herring through the path of a different,
already contentious, discussion.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 May 2013 08:08:22 +1000

> already contentious, discussion.

The working group has created two new unaddressed issue by going the TXT
only.

* how to get people who fielded only SPF records to move to TXT records
* how to deal with the confusion of a SPF record that isn't to be used
  for SPF.

Neither of those issues are currently addressed.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 May 2013 16:56:23 -0700

> Neither of those issues are currently addressed.
To the first point: If we go in the opposite direction and deprecate use of
TXT for SPF, the community of people that needs to update is vastly
larger.  How is that the better solution?

I don't understand what you mean by the second thing.

-MSK

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 May 2013 10:39:05 +1000

In message <[email-masked]>
> larger.  How is that the better solution?

I hesitate to answer this because I will be told to shutup again.

Firstly no one has asked anyone to deprecate the use of TXT for SPF
but if one wanted too one could direct nameserver vendors to log
messages, refuse to load the zone or synthesis a SPF record if a
SPF/TXT record was found without a SPF/SPF record.  Code has shipped
in nameservers that logs such a message.  It logs a message when the
"SHOULD publish both" of RFC 4408 is not being met.

As for numbers the survey was taken *very* early in a transition
from TXT to SPF.  SPF record have doubled as a percentage since the
initial survey was taken.

SPF is a experimental type in RFC 4408 which definitely has some
impact on whether support for parsing SPF record was added to
nameservers.

> I don't understand what you mean by the second thing.

You have a DNS record with a mnemonic of SPF that is not to be used
for SPF.  What does the instruction "Put a SPF record in the DNS"
mean?  Will it result in a type 99 record being added?  How will
such errors be prevented?

> -MSK
> 
> --485b395e7de70c954704dde421e1
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr">On Wed, May 29, 2013 at 3:08 PM, Mark Andrews <span dir=3D=
> "ltr">&lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]<=
> /a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quo=
> te"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
> der-left:1px solid rgb(204,204,204);padding-left:1ex">
> The working group has created two new unaddressed issue by going the TXT<br=
> >
> only.<br>
> <br>
> * how to get people who fielded only SPF records to move to TXT records<br>
> * how to deal with the confusion of a SPF record that isn&#39;t to be used<=
> br>
> =A0 for SPF.<br>
> <br>
> Neither of those issues are currently addressed.<br>
> <div class=3D"im HOEnZb"><br></div></blockquote></div><br></div><div class=
> =3D"gmail_extra">To the first point: If we go in the opposite direction and=
>  deprecate use of TXT for SPF, the community of people that needs to update=
>  is vastly larger.=A0 How is that the better solution?<br>
> <br></div><div class=3D"gmail_extra">I don&#39;t understand what you mean b=
> y the second thing.<br><br></div><div class=3D"gmail_extra">-MSK<br></div><=
> /div>
> 
> --485b395e7de70c954704dde421e1--
> 
> --===============2300023921508032151==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============2300023921508032151==--

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 May 2013 21:15:41 -0400

No hat.

> such errors be prevented?

Wouldn't it be good of name servers to detect someone attempting to
serve a deprecated RRTYPE, and warn them of this?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 May 2013 11:30:17 +1000

> serve a deprecated RRTYPE, and warn them of this?

Yes.

Note, I don't see how this is different to warning about a missing
SPF record which I'm sure if I go rummage about in the archives I
will find as being rejected as a part of the solution to the perceived
interoperability problem except you would never want to turn it
off.

Mark

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 29 May 2013 22:41:48 -0700

> initial survey was taken.
RFC4408 was published in 2006, and SPF had been in extra-IETF development
for a while before that.  RFC6686 was published less than a year ago.  I
don't see how you can characterize that as "early".

-MSK

---

From: Mark Andrews <[email-masked]>
Date: Thu, 30 May 2013 16:43:41 +1000

In message <[email-masked]>
> don't see how you can characterize that as "early".

In a project that I would expect to take 15+ years years to complete
yes it was early.  For a project where the SPF propronent took until
2008 to issue new library code that made type 99 lookups.  Nameserver
vendors incorporated SPF support faster than the SPF propronent.
Then it required MTA vendors/package maintainers to use the new
code.  There wasn't even one hardware replacement cycle allowed
for.  It takes OS vendors years to integrate new nameserver code
into their releases.

TXT to SPF transition was never going to be quick.  It has/had a
timescale similar to A to MX only domain adoption.  As far as I
could see the transition was roughly where I exected it to be.  If
the SPF working group had wanted a faster transition they should
have set development milestones and requested that nameservers
vendors log missing type 99 records etc.

Changing things in the DNS takes a lot of time.  This is something
DNS developers know and accept.

Mark

---

From: Douglas Otis <[email-masked]>
Date: Thu, 30 May 2013 09:16:16 -0700

> we are talking about, do you think you might at least change the

Dear Mr. Sullivan,

Reviewing past decisions within a thread labeled WGLC... seems most appropriate.

Regards,
Douglas Otis

---

From: Stuart D Gathman <[email-masked]>
Date: Thu, 30 May 2013 12:54:58 -0400

+1

4408bis makes a provision to endorse caching negative and error results 
for up to 24 hours.  *That* (not throwing away the SPF record) is the 
solution to the broken nameserver problem.  When you query SPF, and the 
request times out due to broken firewalls, broken nameserver, or 
whatever, then cache the result.

If anything, it is time to remove the dual publishing (both TXT and 
SPF), and the administration/consistency problems that causes.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 30 May 2013 13:21:02 -0400

Stuart D Gathman <[email-masked]> wrote:

>> In message
><[email-masked]>

Took out what I think you're referring to due to negative WGLC comments.  See -15.

>SPF), and the administration/consistency problems that causes.

The current draft does that. 

Scott K

---

From: Stuart Gathman <[email-masked]>
Date: Sat, 01 Jun 2013 00:49:45 -0400

Long ago, Nostradamus foresaw that on 05/30/2013 01:21 PM, Scott
> The current draft does that. 
It says MUST publish TXT - so if you publish SPF you must publish both. 

It could allow caching negative results for type SPF queries only.

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 01 Jun 2013 00:55:48 -0400

On Saturday, June 01, 2013 12:49:45 AM Stuart Gathman wrote:
> > Took out what I think you're referring to due to negative WGLC comments. 
> > See -15.> 

Since the current draft removes type SPF, there's no dual publishing needed.

Scott K