Subject: Re: [spfbis] #58: Local policy in 4408bis

From: Arthur Thisell <[email-masked]>
Date: Fri, 14 Sep 2012 06:31:00 -0700 (PDT)

> When RFC 4408 was being written there were several determined efforts to make 
> it shorter.  The topics that are covered are there because it was felt that 
> they were important.  Now that we know more, based on more experience, we had 
> additional information that seems important.  This is not surprising either.  

RFC 4408 also has a bunch of things that experience has shown that we don't need.  There is a bunch of advocacy, how-to text and suggested workarounds for problems that had a little bit of traction back in 2005, but have never caught on.

> I think we should not worry a lot about the page count.  Splitting the 
> document in two to reduce the page count doesn't help anything and is, I 
> think, actively harmful to the ultimate customers of this document (not the 
> IESG, the implementers).  In a single document, I can be very fine grained 
> about references and pointers so that (particularly in HTML versions of the 
> document) it is easy to follow non-linear narrative when needed.

I agree that, all things being equal, splitting the document hurts since it forces people to pull together several things and splitting adds fluff/wrapping around the content.  Sometimes splitting can help by removing/categorizing material, but there is always a cost that has to be overcome.

I do think we need to worry about how large the total document is.   People have a hard time digesting a lot of information.   If something important to the spec is on page 5, it is a lot more likely to be read and understood than an equally important item on page 50.  Every word/sentence carries a cost, and just because some point is useful to make, doesn't mean that is is useful enough to justify being included.

In some ways, I think RFC 4408 is already too long, and it shows by how much of the new text added to 4408bis was actually already mentioned in 4408.  That shows that people did not, or were not able to, read and digest all of RFC4408.  If experts like us are not able to do that, how are others going to fare?

I'm not sure if advocacy/how-to stuff is ever appropriate for an RFC, but if it is, that is prime material to be shifted to another document.

---

From: S Moonesamy <[email-masked]>
Date: Fri, 14 Sep 2012 06:52:20 -0700

Hi Arthur,
At 06:31 14-09-2012, Arthur Thisell wrote:
>I'm not sure if advocacy/how-to stuff is ever appropriate for an 
>RFC, but if it is, that is prime material to be shifted to another document.

Which parts of RFC 4408 could be categorized as advocacy/how-to stuff?

Regards,
S. Moonesamy

---

From: Arthur Thisell <[email-masked]>
Date: Fri, 14 Sep 2012 08:19:56 -0700 (PDT)

> Which parts of RFC 4408 could be categorized as

Well, off the top of my head, stuff I have already mentioned on this list.  Section 9.1.1. is all "how to optimize SPF records".  The "protocol status" ahd "history" sections tries to establish SPF as an old and reliable protocol that everyone should adopt.   To be far, I haven't recently completely read 4408bis's section, but that was what was put into 4408's equivalent section.   At least in RFC 4408, a lot of section 9 was "hey, here is how-to deploy SPF rebutting all problems that people will bring up against SPF."  A fair amount of effort was put into disguising how-to/advocacy as protocol specification.

My point is really that while RFC 4408 might have been fairly tightly written, there are probably now opportunities, based on experience, to remove old text, not just add to it.

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 14 Sep 2012 17:39:44 +0200

> Which parts of RFC 4408 could be categorized as advocacy/how-to stuff?

The following are some snippets from 4408bis where receiver behavior
is explicit:

1. *Introduction*
    Furthermore,
 if a claimed identity fails verification, local policy can take
 stronger action against such email, such as rejecting it.

2.2. *The "MAIL FROM" Identity*
  a definitive policy result

2.4. *Checking Authorization*
 Although invalid, malformed, or non-existent domains cause SPF checks
 to return "none" because no SPF record can be found, it has long been
 the policy of many MTAs to reject email from such domains, especially
 in the case of invalid "MAIL FROM".  Rejecting email will prevent one
 method of circumventing of SPF records.

2.5.4. *Fail*
All except the first two lines.

2.5.5. *Softfail*
All except
 The domain owner believes the host is not
 authorized but is not willing to make a strong policy statement.

2.5.6. *Temperror*
All except the first two lines.

2.5.7. *Permerror*
 If the
 message is rejected during the SMTP transaction for this reason, the
 software SHOULD use an SMTP reply code of 550 and, if supported, the
 5.5.2 enhanced status code.

4.4. *Record Lookup*
 This alternative is intended to shorten the queue time of messages
 that cannot be accepted, by returning a permanent negative completion
 reply code to the client, instead of a transient one.

6.2. *exp: Explanation*
  Since the explanation string is intended for an SMTP response

9. *Implications*
 This section outlines the major implications that adoption of this
 document will have on various entities involved in Internet email.
 It is intended to make clear to the reader where this document
 knowingly affects the operation of such entities.

9.2.2. *Forwarding Services and Aliases*
Almost all.

9.3. *Receivers*
Almost all, including subsections.

10.5.1. *Recorded Results*
All, except if reworded.

10.5.2. *External Explanations*
The concept itself.