Subject: [spfbis] Section 9 of draft-ietf-spfbis-4408bis-06

From: S Moonesamy <[email-masked]>
Date: Fri, 31 Aug 2012 17:06:07 -0700

Hello,

I'll comment about Section 9 of draft-ietf-spfbis-4408bis-06.  RFC 
4408 mentions that:

   'This section outlines the major implications that adoption of this
    document will have on various entities involved in Internet E-Mail.
    It is intended to make clear to the reader where this document
    knowingly affects the operation of such entities.  This section is
    not a "how-to" manual, or a "best practices" document, and it is not
    a comprehensive list of what such entities should do in light of this
    document.

    This section is non-normative.'

The text mentions what the section is about implications of adopting 
the specification.  I read that as what will break in Internet E-Mail 
when SPF is used and how to mitigate that without getting turning the 
section into a how-to manual or a best practices document.

draft-ietf-spfbis-4408bis-06 introduces policy into the 
section.  That is a significant change from RFC 4408.  Appendix C 
lists the following changes:

   Start to rework section 9 with some RFC5598 terms.

   Added mention of RFC 6552 feedback reports in section 9.

   Move advice to non-normative section 9.

   Added text and figures from Alessandro Vesely in section 9.1 to
   better explain DNS resource limits.

   Added new sections on Receiver policy for SPF pass, fail, and
   permerror.

   Added new section 9 discussion on treatment of bounces and the
   significance of HELO records.

Section 9 of draft-ietf-spfbis-4408bis-06 looks like a catch-all for 
material which could not be fitted in the other sections of the 
draft.  I could not find any significant discussion on the SPFBIS 
mailing list about introducing policy into the draft.  The SPFBIS 
charter mentions "addition of clarifying language".  I'll read that 
as what is unclear and requires clarification.

 From RFC 4408 Section 9.1:

   'Domains that wish to be compliant with this specification will need
    to determine the list of hosts that they allow to use their domain
    name in the "HELO" and "MAIL FROM" identities.  It is recognized that
    forming such a list is not just a simple technical exercise, but
    involves policy decisions with both technical and administrative
    considerations.'

and Section 9.1 of the draft:

   'Originating ADMDs (ADministrative Management Domains - [RFC5598]
    Section 2.2.1 and Section 2.3) that wish to be compliant with this
    specification will need to determine the list of relays ([RFC5598]
    Section 2.2.2) that they allow to use their domain name in the "HELO"
    and "MAIL FROM" identities when relaying to other ADMDs.  It is
    recognized that forming such a list is not just a simple technical
    exercise, but involves policy decisions with both technical and
    administrative considerations.'

IETF specifications do not generally mention compliance.  It is 
usually about interoperability.  There isn't any definition for 
"originating ADMDs" in Section 2.2.1 or Section 2.3 of RFC 5598.  The 
heading for the subsection is "sending domains".  If the goal is to 
use RFC 5598, I suggest using it throughout the draft.  It will be a 
significant change as it is much more than "addition of clarifying language".

Section 9.1.1 is about "DNS Resource Considerations".  That section 
looks like a "how-to".  It is against the stated goal.

Section 9.1.2 is about "Administrator's Considerations".  This is a 
new subsection too.   Quoting from that subsection:

   "The record for a domain that sends no mail is:

       www.example.com.   IN TXT  "v=spf1 -all"

    Publishing SPF records for individual hosts is also best practice."

It is stated at the beginning of the section that it is not a best 
practice document.  The example quoted above stretches the notion 
"addition of clarifying language".   My reading of the charter is 
that the scope was to avoid significant changes unless there is a 
problem to solve.  The WG is over-diligent in solving the problems of 
Internet Mail.

   'Validating correct deployment is difficult.  [RFC6652] describes one
    mechanism for soliciting feedback on SPF failures.  Another approach
    that can be helpful to publish records that include a "tracking
    exists:" mechanism.'

This is deployment guidance.

 From Section 9.1.3 of the draft:

   'As explained in Section 1.3.3, [RFC5321] allows the reverse-path to
    be null, which is typical of some Delivery Status Notification
    [RFC3464], commonly called email bounces.  In this case the only
    entity available for performing an SPF check is the "HELO" identity
    defined in Section 1.3.4.  SPF functionality is enhanced by
    administrators ensuring this identity is set correctly and has an
    appropriate SPF record.  It is normal to have the HELO identity set
    to hostname instead of domain.  Zone file generation for significant
    numbers of hosts can be consolidated using the redirect modifier and
    scripted for initial deployment.  Specific deployment advice is given
    above in Section 9.1.2.'

There is a normative reference to RFC 5321.  There is an assumption 
that the reader will have read and understood RFC 5321 before reading 
this document.  The first sentence sounds like what would fit in a 
tutorial about Internet Mail.  The subsection mentions how to enhance 
SPF functionality.  That is beyond of the scope of what the working 
group was chartered to do.

 From Section 9.2 of the draft:

   "Broadly speaking, there are two types of mediating ADMDs that can
    affect SPF deployment of other ADMDs: mailing lists (see [RFC5598]
    Section 5.3) and ReSenders ([RFC5598] Section 5.2)."

The reader is supposed to have read and understood RFC 5598.  This 
paragraph comes out as tutorial material.

 From Section 9.2.1 of the draft:

   "Mailing lists have to be aware of how they re-inject mail that is
    sent to the list.  Mailing lists MUST comply with the requirements in
    [RFC5321], Section 3.10, and [RFC1123], Section 5.3.6, that say that
    the reverse-path MUST be changed to be the mailbox of a person or
    other entity who administers the list."

As a note, the above text is similar to what was in RFC 
4408.  Section 9 is supposed to be non-normative.  There is a (RFC 
2119) requirement in the above paragraph.   It is not clear why there 
is even a requirement to RFC 1123.  This subsection comes out as 
telling mailing list administrators what the RFCs say and that they 
are to blame if they do comply with the RFCs.

Section 9.2.2 mentions that "Forwarding services take mail that is 
received at a mailbox and direct it to some external mailbox".  This 
again sounds like tutorial material.

   'At the time of this writing, the near-universal practice of such
    services is to use the original "MAIL FROM" of a message when
    re-injecting it for delivery to the external mailbox.  [RFC1123]
    and [RFC5321] describe this action as an "alias" rather than a
    "mail list".'

The term used has always been "alias" and not "mail list".  The draft 
then gets into techniques to "fix the problem".

   "This would cause a lookup on an anti-spam DNS blacklist
    (DNSBL) and cause a result of "fail" only for email coming
    from listed sources."

I suggest avoiding anti-spam techniques as that's not the intent of 
the specification.

   "Then, a specialized DNS server can be set up to serve the
    _spf_verify subdomain that validates the local-part."

This text was also in RFC 4408.  Are there any widespread specialized 
DNS servers providing this type of service?

   'Forwarding services can solve the problem by rewriting the
    "MAIL FROM" to be in their own domain.'

It would be easier to avoid the "forwarding problem" than to attempt 
to solve it.

   "Forwarding servers could reject mail that would "fail" SPF if
    forwarded using an SMTP reply code of 551, User not local,
    (see [RFC5321] section 3.4) to communicate the correct target
    address to resend the mail to."

The working group is taking liberties with RFC 5321 with such 
advice.  There will be concerns about privacy of the advice is 
followed.  This text was not in RFC 4408.

   'Tests against other identities, such as the "HELO" identity,
    MAY be used to override a failed test against the "MAIL FROM"
    identity.'

There is a RFC 2119 key word in the above.

Section 9.3 is about receiver policy (new material compared to RFC 
4408.  Quoting RFC 4408:

   'This document defines a protocol by which domain owners may authorize
    hosts to use their domain name in the "MAIL FROM" or "HELO" identity.'

The document moves from Sender Policy Framework to "Receiver Policy 
Framework".  There is no mention of receiver policy in the SPFBIS 
charter.  It is way outside the scope of the charter to discuss about that.

The second milestone mentions a standards track document defining 
SPF.  Section 9 would be highly unusual for a document on that 
track.  My understanding of the charter is that the goal is to pursue 
development of the protocol and not deployment.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 17:54:04 -0700

On Fri, Aug 31, 2012 at 5:06 PM, S Moonesamy <[email-masked]> wrote:
> The text mentions what the section is about implications of adopting the
> specification.  I read that as what will break in Internet E-Mail when SPF
> is used and how to mitigate that without getting turning the section into a
> how-to manual or a best practices document.
>
> draft-ietf-spfbis-4408bis-06 introduces policy into the section.  That is a
> significant change from RFC 4408.  Appendix C lists the following changes:
> [...]

So in general, I think this kind of stuff has to go someplace.  The
experience we've gained in the six years since RFC4408 plus the period
during which SPF was originally developed is useful to document
someplace in an official capacity.  We are not, however, chartered to
do so, either in this document or in a separate one.  That would
require re-chartering.

Perhaps the simplest thing to do is to start an individual submission
to collect this stuff, and move it out of here.  The trick, though, is
that RFC4408bis itself should then refer to it, which will delay its
publication until that document finds a new home or an AD sponsor and
is also published.  (And I can tell you that we're very unlikely to
take it in APPSAWG.)

What the co-chairs will have to decide along these lines is whether
moving Section 9 out to its own document constitutes a change that
fits within the charter.  We can't really have it both ways; RFC4408's
Section 9 is indeed deployment advice, so if it stays in the name of
minimal change, it at least deserves an update pass.

There are, however, parts of the current Section 9 that really need to
stay.  I'm mainly thinking about the section that describes
implications for receivers.  Put yourself in the position of an
operator reading this: "OK, so I got an SPF {fail, pass, *error} on
this message.  Now what?"  I believe this document is incomplete
without an answer to that question.

-MSK

---

From: Hector Santos <[email-masked]>
Date: Fri, 31 Aug 2012 21:18:25 -0400

> without an answer to that question.

This sort of revisiting of SPF theory is really out of place. We 
already know what SPF is, what it does, what it offers, its weak and 
strong points and where it fails. Honestly, we do and we did since day 
one and I guess I can say that because there are millions of domains 
using SPF. As a matter of fact, since day one, its #1 issue was the 
genesis for DKEYS, IIM and DKIM reason to exist (at least marketing 
wise).   We are not inventing anything new.

We know what SPF says for FAIL, PASS, SOFTFAIL, NONE and *ERROR and in 
all honesty, SPF is about a "RECEIVER protocol." Calling it "Receiver 
Policies" is a misnomer. SPF describes what a compliant SPF receiver 
is expected to do with a Domain SPF policy and if they don't follow 
it, it breaks down.  Sure, it is unfortunately weak in throwing the 
book at anyone and thus one can start an argument

          "Well, it really doesn't say that - RFC2119 wise."

but that isn't practical in real life.  People do know whats going on 
and that is why SPF is pretty popular, widely adopted and widely 
supported.

I believe people can provide experiences for some insight, but SPF is 
pretty clear and has been very clear since the beginning on what 
receiver can or can't do.  Lets not reinvent the wheel, intentions - 
the SPF Theory.  We are dangerously close of losing focus of what SPF 
is and IMO, we risk a lost of endorsement for what one may view as 
already over bloated BIS work.

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Fri, 31 Aug 2012 18:23:49 -0700

Hi Murray,
>do so, either in this document or in a separate one.  That would

Yes.

>is also published.  (And I can tell you that we're very unlikely to

I don't know what to suggest.  I won't suggest APPSAWG. :-)

>minimal change, it at least deserves an update pass.

Yes.  I posted the review of this section to get some feedback from 
WG participants.

>without an answer to that question.

That's a good point.

Regards,
S. Moonesamy

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 31 Aug 2012 20:26:34 -0700

> I don't know what to suggest.  I won't suggest APPSAWG. :-)

The APPSAWG co-chair thanks you.  (Seriously, though, there are
several procedural things blocking that path.)

If we do split the work in this way, we technically still hit our
deliverable even if it lands in the RFC Editor queue and stalls there
until the second document finishes via whatever path is chosen for it.
 We just have to accept the unpredictable delay.  The only work then
is to decide what parts of the current Section 9 are required to make
the document whole (those should stay) and which constitute
non-critical implementation advice (those should move).

It's possible that new content from other sections is also a candidate
for such a migration, which would make Arthur happy.

Oh, and you need to find an editor(s).  ;-)

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 01 Sep 2012 00:48:49 -0400

> Oh, and you need to find an editor(s).  ;-)

I think that both removing section 9 and leaving section 9 unchanged are 
inconsistent with our charter.  I think to do the work we're chartered to do 
an updated/corrected section 9 is required.  I think that's substantially what 
we have now.

That aside, I think splitting the document is a silly idea that would be 
editorially difficult to pull off without making things significantly more difficult 
for people trying to understand SPF based on the product of this working 
group.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 31 Aug 2012 22:23:46 -0700

Hello,

My recommendation to the document editor of 
draft-ietf-spfbis-4408bis-06 is to move Section 9 of the draft to an appendix.

draft-ietf-spfbis-4408bis is intended to be published as a Proposed 
Standard (RFC).  I suggest that WG participants send arguments about 
which parts of the new appendix is necessary for the Proposed 
Standard.  The guideline in determining what to do is the SPFBIS 
Charter.  What has been done in other Proposed Standards may be used 
as input for additional guidance.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 01 Sep 2012 01:35:12 -0400

The charter says:

> Changes to the SPF specification will be limited to the correction
> of errors, removal of unused features, addition of any enhancements
> that have already gained widespread support, and addition of
> clarifying language.

Moving section 9 to an appendix is none of those things.

Scott K

---

From: S Moonesamy <[email-masked]>
Date: Fri, 31 Aug 2012 23:12:06 -0700

Hi Scott,
>Moving section 9 to an appendix is none of those things.

Please move the section to an appendix.

The working group can discuss about this issue after completing the 
work on the other sections of the draft.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 01 Sep 2012 02:33:22 -0400

> work on the other sections of the draft.

You've already said you haven't reviewed the entire draft and won't until 
after WGLC.  I don't think you are in a position to know if that's a good idea 
or not.  

I also think you are giving direction that is inconsistent with the WG 
charter.  I've already said that and you've ignored it.  I don't think that is 
appropriate either.

What makes this suddenly essential that it can't wait until it's been 
discussed?

I'm putting my work on the draft on hold until this is resolved.

Scott K