Subject: [spfbis] RFC 4408 issues list

From: S Moonesamy <[email-masked]>
Date: Tue, 14 Feb 2012 10:10:51 -0800

Hello,

We asked that people get their issues together by 18 February.  The 
following issues have been posted to the tracker ( 
http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ):

   1. RFC 4408 Section 2.5.6 - Temporary errors
   2. RFC 4408 Section B.3 - Errata #2250
   3. RFC 4408 - Errata #99
   4. RFC 4408 Section 4.1
   5. RFC 4408 ambiguities
   6. RFC 4408 Section 10.1 - Processing limits needs clarification 
and reorganization
   7. RFC 4408 Downcase result names in spec text and ABNF
   8. RFC 4408 Mixed use of RFC2119 words
   9. RFC 4408 SPF RR type
  10. RFC 4408 replace Received-SPF with RFC5451
  11. RFC 4408 Section 4 check_host() function
  12. RFC 4408 Section 9 - Forwarding and helo identities

Can working group participants please review RFC 4408 and post issues 
by Saturday?

Thank you
Andrew Sillivan & S. Moonesamy, SPFBIS WG co-chairs

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 14 Feb 2012 13:32:10 -0500

> Can working group participants please review RFC 4408 and post issues

I'm probably just being a bit thick today, but what are you asking us to do 
that's different than what we just did?

Confused,

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Tue, 14 Feb 2012 10:50:37 -0800

Hi Scott,
>that's different than what we just did?

It's a reminder.  If you have not posted your issue yet, it would be 
help to the WG chairs if you could post them by Saturday.  If you 
have already posted issues, they should be in the tracker.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Hector Santos <[email-masked]>
Date: Tue, 14 Feb 2012 16:28:02 -0500

Sorry, Saturday is too short for (for me, time wise). SM, SPF-BIS is 
too important for such an aggressive schedule.  With the lack of 
discussion on the issues already cataloged,  I sense there is going to 
a very heavy burden with quick decisions made.

S Moonesamy wrote:
>   6. RFC 4408 Section 10.1 - Processing limits needs clarification and 
> reorganization
> Can working group participants please review RFC 4408 and post issues by 
> Saturday?
> 
> Thank you
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
> 
> 

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: S Moonesamy <[email-masked]>
Date: Tue, 14 Feb 2012 14:13:36 -0800

Hi Hector,
At 13:28 14-02-2012, Hector Santos wrote:
>discussion on the issues already cataloged,  I sense there is going 
>to a very heavy burden with quick decisions made.

Andrew, as SPFBIS WG co-chair, posted a message on February 7 about 
nobody objecting to the deadline ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00353.html 
).  From the above, I gather that you need more time.  What date 
would be convenient for you?

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 14 Feb 2012 17:44:57 -0500

On Tue, Feb 14, 2012 at 02:13:36PM -0800, S Moonesamy wrote:
> >Sorry, Saturday is too short for (for me, time wise).
[…]
> From the above, I gather that you need more time.  What date would
> be convenient for you?

Perhaps we could take another approach.

Hector, as you note, there are already several issues catalogued.  I'd
like to suggest that we begin discussions of some of the
already-enumerated issues while you are still working on your list of
issues.  It seems to me that we can make progress on some issues while
others find new issues.  After all, it's not as though we're closing
the list of issues forever before we start discussing issues: if a new
issue emerges from the discussion, we're not going to rule it out of
order.  Similarly, the point here is to take only a few issues at a
time, so there will still be some in the queue after the 18th.  The
point of the artificial deadline of the 18th was to collect as many
issues as we could in order to prioritize items in discussion.  If
every issue hasn't been exposed by then, it's not the end of the
world; we certainly have some things to chew on already.

So in the absence of a really compelling reason to hold off, SM and I
will pick some issues to start discussion on later this week.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 15 Feb 2012 16:04:20 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of S Moonesamy
> Sent: Tuesday, February 14, 2012 10:11 AM
> To: [email-masked]
> Subject: [spfbis] RFC 4408 issues list
> 

I've posted my issues from my review already, but I'd like to point out that I'll be mentioning this work at the MAAWG conference next week, and we might collect some new participants and/or feedback from that since SPF is near and dear to many that will be attending.  I will forward what I get from that and encourage them to get involved directly, but that may mean some issues are raised after your deadline.  I hope that's okay, or if not would we consider pushing the deadline out a week or two?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 15 Feb 2012 19:11:09 -0500

On Wednesday, February 15, 2012 04:04:20 PM Murray S. Kucherawy wrote:
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of S Moonesamy Sent: Tuesday, February 14, 2012 10:11 AM
> > To: [email-masked]
> I've posted my issues from my review already, but I'd like to point out that
> I'll be mentioning this work at the MAAWG conference next week, and we
> might collect some new participants and/or feedback from that since SPF is
> near and dear to many that will be attending.  I will forward what I get
> from that and encourage them to get involved directly, but that may mean
> some issues are raised after your deadline.  I hope that's okay, or if not
> would we consider pushing the deadline out a week or two?

As Andrew Sullivan already said in another message in this thread, it's not 
like new issues can't be considered later.

RFC 4408 is approaching it's sixth birthday.  I think there's been lots of 
time for people to consider it.  I'd prefer for us to get started and look at 
new issues later if any emerge.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 15 Feb 2012 16:15:01 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Wednesday, February 15, 2012 4:11 PM
> To: [email-masked]
> Subject: Re: [spfbis] RFC 4408 issues list
> 
> As Andrew Sullivan already said in another message in this thread, it's
> not like new issues can't be considered later.

Fair enough; then I guess I'm just mentioning that I might have a bunch of other feedback after next week.  No reason to hold us up.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Feb 2012 10:44:37 -0500

+1.

My thoughts:

- Mixed discipline environment, can't expect the same level of detail 
reviews across the board in the agenda sought. We have IETF level 
review disciplines vs functional, technical interest,

- Need to separate issues into technical important levels, integration 
related. Which ones are discussed first, is a judgment call, but I 
lean towards the ones that deal with what we learned the last 9 years 
of vendor implementations, and that includes:

- Senderid (RFC5222 related) vs Submitter (RFC5321 related that allows 
indirect support for SenderId),

- Addressing the check_host() input and open-ended options,

- Emphasis on security and (DNS) optimization, overhead minimization,

- Reporting methods, directions.

Thanks

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Feb 2012 10:54:02 -0500

Small followup,

and also nipping the bud on obvious issues that have a high potential 
for dispute.  Honestly and I'm record that I do not like the IETF 
Rough Consensus (RC) concept. It was applicable in an era where we 
journeying into the unknown in years past to help with decision 
making. Its a terrible method in today's environment where we have 
untold IETF-MAN-YEARS in technology and how its will most likely work. 
  I can not accept any RC today where there is obvious contention and 
quite often an osmosis element comes into play - ignore other input or 
others just step out thus automatically creating a untrue position. 
Tough call,  understood,  but at the end of the day its about 
fundamental engineering sense that MUST be followed.   Thats me. Thats 
how I am. No bending.

Hector Santos wrote:
> reviews across the board in the agenda sought. We have IETF level review 
> disciplines vs functional, technical interest,
> 
> related. Which ones are discussed first, is a judgment call, but I lean 
> towards the ones that deal with what we learned the last 9 years of 
> vendor implementations, and that includes:
>

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Feb 2012 11:57:06 -0500

Hi Hector,

My chair hat is firmly on.  I haven't consulted with SM on what I say
below, but I'd be astonished if he disagreed with me.

On Thu, Feb 16, 2012 at 10:54:02AM -0500, Hector Santos wrote:

> Honestly and I'm record that I do not like
> the IETF Rough Consensus (RC) concept.
[…]
> followed.   Thats me. Thats how I am. No bending.

I don't mind if you don't like the approach that the IETF uses, but
neither this WG nor this list shall be turned into a platform for
discussion of the IETF process.  There are _plenty_ of places around
the IETF to discuss process.  This WG isn't one of them, and we're
going to use the established IETF processes for the operation of this
WG.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Feb 2012 12:00:01 -0500

On Wed, Feb 15, 2012 at 04:04:20PM -0800, Murray S. Kucherawy wrote:
> I've posted my issues from my review already, but I'd like to point
> out that I'll be mentioning this work at the MAAWG conference next
> week, and we might collect some new participants and/or feedback
> from that since SPF is near and dear to many that will be attending.
> I will forward what I get from that and encourage them to get
> involved directly, but that may mean some issues are raised after
> your deadline.  I hope that's okay, or if not would we consider
> pushing the deadline out a week or two?

Please do draw this work to the attention of MAAWG participants.  We
of course welcome additional participation.  We are going to start
working on particular issues, though, starting next week.  The point
of the deadline was really just an administrative trick: we wanted to
get a bunch of issues listed first so we had some things to
prioritize.  I cannot believe we won't see more issues coming up, and
we of course encourage people to raise those as they think of them.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Thu, 16 Feb 2012 10:24:03 -0800

>below, but I'd be astonished if he disagreed with me.

I agree with what my co-chair said ( 
http://www.ietf.org/mail-archive/web/spfbis/current/msg00386.html ).

I would like to remind all working group participants to read the 
Note Well ( http://www.ietf.org/about/note-well.html ), which I quote:

   "A participant in any IETF activity is deemed to accept all IETF rules of
    process, as documented in Best Current Practices RFCs and IESG Statements."

Please note that that all IETF Contributions are subject to the rules 
of RFC 5378 and RFC 3979 (updated by RFC 4879).

If you need more information, please ask the Working Group chairs.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Douglas Otis <[email-masked]>
Date: Thu, 16 Feb 2012 14:42:08 -0800

Dear S Moonesamy,

RFC4408 needs to set reasonable limits for the number of DNS 
transactions resulting in Name Errors or No Data results.  This 
constrains potential reflected DNS amplification caused by the 111 (or 
222 TXT/SPF RR) possible DNS transactions that might be attempted to 
resolve a complete SPF record set.  1 + 10 + 100 or 2 + 20 + 200 
depending upon use of SPF/TXT resource records in parallel.

The potential level of DDoS gain is also affected by whether other 
identities are to be resolved beyond the typical SMTP Mail From 
parameter, such as those used to resolve Sender-ID or HELO/EHLO 
identities.  1 for initial SPF records.  1 for each of the 10 
mechanisms.  10 for each of the possible host address or PTR resolutions 
by each mechanism.

Section 4.4 Record Lookup

Was:
If all DNS lookups that are made return a server failure (RCODE 2), or 
other error (RCODE other than 0 or 3), or time out, then check_host() 
exits immediately with the result "TempError".

Change to:
When more than 10 DNS transactions return a server failure (RCODE 2), 
time out or provide No Data (ANCOUNT of zero), subsequent DNS 
transactions SHOULD be avoided and conclude with a resolution of 
"TempError".  When 10 DNS transactions return a Name Error (RCODE 3), 
subsequent DNS transactions SHOULD be avoided and conclude with a 
resolution of "None".

When one of the optional resource record types (TXT or SPF) for a 
specific domain provide No DATA (ANCOUNT of zero) but data is returned 
by the other, DNS transactions for this domain SHOULD avoid subsequent 
transactions using the resource record type resulting in No Data.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Feb 2012 18:00:10 -0500

I think this is one part of a possible solution to the existing issue on 
refactoring the processing limits in paragraph 10.1 of RFC 4408 and should be 
added to that issue rather than as a new separate issue.

Scott K

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Feb 2012 18:16:05 -0500

Hi Doug,

Could we split this in two: (1) issue of "possible large number of DNS
queries that could result" and (2) possible mitigations?  That is, I'd
like the issue to be (1) and your suggested answers to be part of the
discussion of how to address the issue.  Ok?

A

On Thu, Feb 16, 2012 at 02:42:08PM -0800, Douglas Otis wrote:
> constrains potential reflected DNS amplification caused by the 111
> (or 222 TXT/SPF RR) possible DNS transactions that might be
> attempted to resolve a complete SPF record set.  1 + 10 + 100 or 2 +
> 20 + 200 depending upon use of SPF/TXT resource records in parallel.
> 
> mechanisms.  10 for each of the possible host address or PTR
> resolutions by each mechanism.
> 
> If all DNS lookups that are made return a server failure (RCODE 2),
> or other error (RCODE other than 0 or 3), or time out, then
> check_host() exits immediately with the result "TempError".
> 
> Change to:
> When more than 10 DNS transactions return a server failure (RCODE
> 2), time out or provide No Data (ANCOUNT of zero), subsequent DNS
> "TempError".  When 10 DNS transactions return a Name Error (RCODE
> 3), subsequent DNS transactions SHOULD be avoided and conclude with
> a resolution of "None".
> 
> specific domain provide No DATA (ANCOUNT of zero) but data is
> returned by the other, DNS transactions for this domain SHOULD avoid
> subsequent transactions using the resource record type resulting in
> No Data.
> 
> Regards,
> Douglas Otis
> 

-- 
Andrew Sullivan
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Feb 2012 18:53:39 -0500

I did not advocate a referendum on the RC process. But I am hoping 
that the WG will recognize using it an instrument to win controversial 
suggestions when they shouldn't be one in the first place will be 
problematic. Especially when you already been told upfront that those 
issue might be.  Thats a MANAGEMENT problem.

---

From: Hector Santos <[email-masked]>
Date: Thu, 16 Feb 2012 19:13:20 -0500

SM, AS:

My point is simple. I have a concern with apparent WG Chairs plans to 
allow controversial issues be introduced and debated that perhaps 
SHOULD NOT have been even allowed to be introduced in the first place. 
   I've seen it used incorrectly in the past to interject and change 
the framework of the protocol and I fear it will used again here for 
SPF using SPFBIF as a vehicle to institute the change.  I'm seen it 
with DKIM and I don't wish to to see it with SPF.

Anything that changes SPF in a non-compatible manner should not be an 
issue to be discussed and working purely on RC is not going to resolve 
the inherent problem it shouldn't have been one the first place.

--

S Moonesamy wrote:
> I would like to remind all working group participants to read the Note 
> Well ( http://www.ietf.org/about/note-well.html ), which I quote:
> 
> Please note that that all IETF Contributions are subject to the rules of 
> RFC 5378 and RFC 3979 (updated by RFC 4879).
>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 16 Feb 2012 16:21:02 -0800

Hi Hector,
At 15:53 16-02-2012, Hector Santos wrote:
>that the WG will recognize using it an instrument to win 
>controversial suggestions when they shouldn't be one in the first 
>place will be problematic. Especially when you already been told 
>upfront that those issue might be.  Thats a MANAGEMENT problem.

May I humbly suggest that we wait for the issues to be discussed 
before drawing any conclusion?  It's only a matter of a few more days 
before the start of the discussions on the issues listed in the tracker.

Thanks,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Thu, 16 Feb 2012 16:53:44 -0800

Hi Hector,
At 16:13 16-02-2012, Hector Santos wrote:
>My point is simple. I have a concern with apparent WG Chairs plans 
>to allow controversial issues be introduced and debated that perhaps 
>SHOULD NOT have been even allowed to be introduced in the first 
>place.   I've seen it used incorrectly in the past to interject

The WG Chairs asked everyone to review RFC 4408 and post their 
comments to this mailing list.  The comments were listed in the 
tracker as issues.

>  and change the framework of the protocol and I fear it will used 
> again here for SPF using SPFBIF as a vehicle to institute the 
> change.  I'm seen it with DKIM and I don't wish to to see it with SPF.

This is the SPFBIS working group.

>Anything that changes SPF in a non-compatible manner should not be 
>an issue to be discussed and working purely on RC is not going to 
>resolve the inherent problem it shouldn't have been one the first place.

BCP 25 defines IETF working group procedures and guidelines.  I would 
prefer not to see IETF rules exercised unless there is no other 
alternative.  I suggest that we wait until tomorrow.  If you still 
have a concern, you can email the WG Chairs privately, or post to the 
mailing list, if you wish.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Douglas Otis <[email-masked]>
Date: Thu, 16 Feb 2012 18:32:15 -0800

> discussion of how to address the issue.  Ok?
Dear Andrew,

I assume you want me to resubmit this as two separate messages.  I'll 
have that first thing tomorrow.  I am still recovering from an Inchon 
flight.

I am also tempted to write something similar regarding the local-part 
macro.  This feature is seldom used, but prevents domain level caching.  
This necessitates repeating the same process simply because it might be 
effected by a local-part macro.  This feature also conflicts with using 
SPF as a utility to define the domain's outbound servers and to assess 
reputations based upon a domain name.

Regards,
Douglas Otis

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Feb 2012 21:41:50 -0500

No, no need for different mails. I'll take this as agreement. 

-- 
Andrew Sullivan 
Please excuse my clumsy thumbs. 

On 2012-02-16, at 21:32, Douglas Otis <[email-masked]> wrote:

> I assume you want me to resubmit this as two separate messages.  I'll have that first thing tomorrow.  I am still recovering from an Inchon flight.
> 
> I am also tempted to write something similar regarding the local-part macro.  This feature is seldom used, but prevents domain level caching.  This necessitates repeating the same process simply because it might be effected by a local-part macro.  This feature also conflicts with using SPF as a utility to define the domain's outbound servers and to assess reputations based upon a domain name.
> 
> Regards,
> Douglas Otis
> 
> 
> 
>> 
>> A
>>

---

From: Douglas Otis <[email-masked]>
Date: Fri, 17 Feb 2012 16:34:11 -0800

Dear S Moonesamy,

Use of local-part macros in SPF record sets necessitates repeating all 
invoked DNS transactions.  DNS caching only limits DNS overhead when no 
local-part macros are used within SPF record sets.  It is not uncommon 
for the use of random local-part names in messages to be sent by 
malefactors.  Such use significantly impacts the utility of SPF without 
burdening the authoritative servers employed by malefactors.  Not only 
will local-part macros increase the gain of a reflected attack, it also 
prevents resolving addresses of a set of servers for a specific domain.  
Permitting local-part assessments will return results based upon entire 
email addresses and not just the email-address domain.  It is common to 
use SPF to resolve the outbound addresses used by a domain to check 
reputation listings against these addresses.  This use assumes a 
specific domain has not defined local-part macros in their record set or 
that it defaults to "postmaster".

SPF local-part macros should not be used as a method to vet valid 
local-part names, as this would permit the use of high speed dictionary 
attacks to discover which are valid.  A domain better protects 
confidentiality of valid local-parts by postponing acceptance or refusal 
to the Data command.   A reasonable practice for recipients to use to 
ensure effective caching and to retain the desired utility is to 
supplant any local-part with that of "postmaster".  Otherwise, when SPF 
processing follows other types of vetting, expansion of the local-part 
would leak its status via DNS requests.

Add:

A method for mitigating a reduction in utility or risks associated with 
local-part macros would be to replace any local-part with that of 
"postmaster".

Regards,
Douglas Otis

---

From: S Moonesamy <[email-masked]>
Date: Fri, 17 Feb 2012 17:03:31 -0800

Hi Doug,
At 16:34 17-02-2012, Douglas Otis wrote:
>Use of local-part macros in SPF record sets necessitates repeating 
>all invoked DNS transactions.  DNS caching only limits DNS overhead 
>when no local-part macros are used

I added this to the tracker (Issue #14).

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: S Moonesamy <[email-masked]>
Date: Mon, 20 Feb 2012 12:27:50 -0800

Hello,

I cannot get the information for Errata #994.  Could someone please 
post them to this mailing list so that they can be tracked as issues?

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 20 Feb 2012 16:10:24 -0500

> post them to this mailing list so that they can be tracked as issues?
RFC4408, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-
Mail, Version 1", April 2006
Source of RFC: IETF - NON WORKING GROUP
Area Assignment: app

Errata ID: 994

Status: Held for Document Update
Type: Technical

Reported By: Frank Ellermann
Date Reported: 2007-11-06
Held for Document Update by: Alexey Melnikov
Date Held: 2010-07-01

See this page for discussion of errata for RFC 4408:
<http://www.openspf.org/RFC_4408/Errata>

Notes:

Alexey: if there is interest in revising the document, then it should be 
updated to incorporate some changes suggested on the above web page. 

(not part of the errata from the IETF web site, but substitute openspf.net 
where it says openspf.org).

Scott K

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 20 Feb 2012 13:28:56 -0800

On 2/16/2012 9:00 AM, Andrew Sullivan wrote:
> Please do draw this work to the attention of MAAWG participants.

While yes, MAAWG needs to hear about current status, folks should be aware that 
the current IETF working group effort was actually triggered by a recent desire 
in MAAWG to get SPF standardized.  It followed a circuitous path and took 
awhile, but that was the impetus that I observed.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 20 Feb 2012 13:39:01 -0800

> Sent: Monday, February 20, 2012 12:28 PM
> To: [email-masked]

For systems reasons, openspf.org has been replaced (for now, at least) by openspf.net.  The URL in that erratum can be accessed at that alternate domain.  Thus, go here: http://www.openspf.net/RFC_4408/Errata.

The page contains links to eight errata that were logged on that web site, but not in the RFC Editor's errata tracking tool.  Do we need to create IETF errata instead?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 20 Feb 2012 16:51:41 -0500

On Monday, February 20, 2012 01:39:01 PM Murray S. Kucherawy wrote:
> > Of S Moonesamy Sent: Monday, February 20, 2012 12:28 PM
> > To: [email-masked]
> For systems reasons, openspf.org has been replaced (for now, at least) by
> openspf.net.  The URL in that erratum can be accessed at that alternate
> domain.  Thus, go here: http://www.openspf.net/RFC_4408/Errata.
> 
> The page contains links to eight errata that were logged on that web site,
> but not in the RFC Editor's errata tracking tool.  Do we need to create
> IETF errata instead?

Please, let's not.  They're all documented issues and that's all we need to 
consider them.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 20 Feb 2012 14:09:23 -0800

> Sent: Monday, February 20, 2012 1:52 PM
> To: [email-masked]
> Please, let's not.  They're all documented issues and that's all we
> need to consider them.

I don't care either way, as long as procedure is followed.  And I don't know if there's anything formal about handling externally-tracked errata.

I just don't want this to come back on us later.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 20 Feb 2012 14:07:28 -0800

>where it says openspf.org).

If anyone would like those changes to be discussed by the working 
group, could the person please post them to this mailing list so that 
I can put them into the tracker?

If a change is already listed ( 
http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ), there is no 
need to raise it again as it will be discussed.

At 13:39 20-02-2012, Murray S. Kucherawy wrote:
>For systems reasons, openspf.org has been replaced (for now, at 
>least) by openspf.net.  The URL in that erratum can be accessed at 
>that alternate domain.  Thus, go here: http://www.openspf.net/RFC_4408/Errata.
>
>The page contains links to eight errata that were logged on that web 
>site, but not in the RFC Editor's errata tracking tool.  Do we need 
>to create IETF errata instead?

No, it's easier to track them as issues as this working group will be 
working on 4408bis.  See my comment above.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 20 Feb 2012 22:01:38 -0500

> need to raise it again as it will be discussed.

I did already mention these errata in http://www.ietf.org/mail-
archive/web/spfbis/current/msg00274.html - but they don't seem to have made it 
into the tracker.

Do you want one mail per item?

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Feb 2012 17:11:27 -0800

Dear Andrew,

Sorry for the delay, but where is addressing excessive No Data or Name 
errors listed in the issues tracker?

The issue of squelching subsequent TXT or SPF record queries is only 
part of an amplification concern.

Should I resubmit these issues separately?

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Feb 2012 18:45:51 -0800

Dear Andrew,

Perhaps further clarification was needed.  Each of 10 SPF mechanisms may 
require 10 separate reflected DNS resolutions where SPF is insensitive 
to the number of No Data responses in multiples of 100 DNS 
transactions.  There is no limit for the number of No Data results, 
which represents a likely method malefactors might use in conjunction 
with local-part macros to implement DNS based attacks.  The gain of this 
attack depends on whether SPF/TXT, HELO/EHLO, Mail From, and PRA checks 
are made for each message.  Network amplification that could result is 
substantial.  This risk can be significantly mitigated by simply 
imposing reasonable No Data limits.

Regards,
Douglas Otis

---

From: S Moonesamy <[email-masked]>
Date: Tue, 21 Feb 2012 19:01:14 -0800

Hi Doug,
At 18:45 21-02-2012, Douglas Otis wrote:
>Perhaps further clarification was needed.  Each of 10 SPF mechanisms 
>may require 10

This is being tracked as Issue #24.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 21 Feb 2012 23:29:17 -0500

On Tuesday, February 21, 2012 06:45:51 PM Douglas Otis wrote:
> This risk can be significantly mitigated by simply 

This or something very similar is implemented in the Mail::SPF Perl module as 
max_void_dns_lookups.  From the Mail::SPF documentation:

An I<integer> denoting the maximum number of "void" DNS look-ups per SPF 
check, i.e. the number of DNS look-ups that were caused by DNS-interactive 
terms and macros (as defined in RFC 4408, 10.1, paragraphs 6 and 7) and that 
are allowed to return an empty answer with RCODE 0 or RCODE 3 (C<NXDOMAIN>) 
before processing is aborted with a C<permerror> result.  If B<undef> is 
specified, there is no stricter limit on the number of void DNS look-ups beyond 
the usual processing limits.  Defaults to B<2>.

Specifically, the DNS look-ups that are subject to this limit are those caused
by the C<a>, C<mx>, C<ptr>, and C<exists> mechanisms and the C<p> macro.

A value of B<2> is likely to prevent effective DoS attacks against third-party
victim domains.  However, a definite limit may cause C<permerror> results even
with certain (overly complex) innocent sender policies where useful results
would normally be returned.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Tue, 21 Feb 2012 21:10:59 -0800

Hello,

This thread is off-topic at the moment.  Please do not comment on 
issues which have not been opened yet.

Thank you,
S. Moonesamy
SPF WG co-chair