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

From: Arthur Thisell <[email-masked]>
Date: Sat, 1 Sep 2012 08:31:09 -0700 (PDT)

I never much liked section 9, it seemed to be too much of a how-to/advocacy/anti-FUD section.  RFC 4408 is, IMHO, better than earlier drafts of SPF, but times have changed.  SPF has not, as some critics claimed, destroyed email and the DNS and we no longer need to refute such claims in the draft.  The number of people demanding "I'll never adopt SPF until I can handle <edge-case>" has given way with people just using a simpler subset of SPF.  We no longer need to have a section of "yes, you can handle <edge-case> by this!" in the spec.

That said, I'm not sure the charter really allows ripping it out.

> From RFC 4408 Section 9.1:
>
>  'Domains that wish to be compliant with this specification will need
>
> IETF specifications do not generally mention compliance.

During the drafting of early SPF specs, there were a lot of people complaining that they would be forced to adopt SPF.  Wording such as this was mostly to make it clear that SPF was optional.  We probably should have said "wish to adopt" or some such thing.   I don't think there is as much FUD/confusion now, so we can probably drop the weasel words entirely.

> From Section 9.2.1 of the draft:
>
>  "Mailing lists have to be aware 
>
> It is not clear why there is even a requirement to RFC 1123.

I'm not sure what is not clear about it.  Section 5.3.6 of RFC 1123 talks about what mailing lists must do and the difference between an "alias" and a "list".

> The term used has always been "alias" and not "mail list".

I'm confused by this.  For example, section 3.9 of RFC 5321 is titled "mailing lists and aliases" and discusses the difference between these two models.

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

I don't know about today.  At the time that this was written, two people had come forward to say they were doing this.  I suspect that there never were many.  Similar things can be said about the example of a rate-limiting DNS server.  Yeah, at least one existed at one time, but it is an edge-case that people have not seen a great need to deal with.

---

From: S Moonesamy <[email-masked]>
Date: Sat, 01 Sep 2012 10:42:53 -0700

At 08:31 01-09-2012, Arthur Thisell wrote:
>I'm not sure what is not clear about it.  Section 5.3.6 of RFC 1123 
>talks about what mailing lists must do and the difference between an 
>"alias" and a "list".

RFC 5321 mentions that it updates RFC 1123 replacing the mail 
transport materials.  As the text from Section 5.3.6 of RFC 1123 is 
in RFC 5321 I consider it as replaced.  The RFC 1123 reference in 
that part of Section 9 is not needed.

>I'm confused by this.  For example, section 3.9 of RFC 5321 is 
>titled "mailing lists and aliases" and discusses the difference 
>between these two models.

I'll quote the subsection for context:

'9.2.2.  Forwarding Services and Aliases

   Forwarding services take mail that is received at a mailbox and
   direct it to some external mailbox.  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".  This means the external mailbox's MTA
   sees all such mail in a connection from a host of the forwarding
   service, and so the "MAIL FROM" identity will not, in general, pass
   authorization.'

The subsection discusses about forwarding services and aliases.  The 
previous subsection (9.2.1) is about "Mailing Lists".   My 
understanding is that a forwarding service is not a mailing list.  I 
would drop the "rather than" part of the sentence to keep it simple and clear.

On an unrelated note, RFC 5598 describes the enhanced Internet Mail 
architecture, reflecting the current service.  RFC 5321 is a 
specification of the basic protocol for Internet electronic mail 
transport.  The reader goes through three discussions about aliases.

Regards,
S. Moonesamy

---

From: Dave Crocker <[email-masked]>
Date: Sat, 01 Sep 2012 10:59:24 -0700

> transport.  The reader goes through three discussions about aliases.

I am, understandably, completely biased.

However I'd urge that the current spec merely make a normative reference
to RFC 5598, importing the terms and concepts that are relevant to
SPFbis, rather than re-defining things.

RFC5598 was motivated by the observation that the industry lacked much
cohesiveness about email terminology and architectural detail.  Anything
that moves us towards the cohesiveness would be an improvement, IMO, and
citing a common architecture/terminology document does move in that
direction.

d/

-- 
 Dave Crocker
 Brandenburg InternetWorking
 bbiw.net

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 03 Sep 2012 01:42:21 -0400

> transport.  The reader goes through three discussions about aliases.

Yes, but 5598 is an informational document.  For things like mailing lists 
that are well described in 5321, I think it's better to use the standard 
definition.

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 03 Sep 2012 01:43:47 -0400

> citing a common architecture/terminology document does move in that

I did make an effort in this direction already.  If you've got specific 
recommendations about further improvements, I'd be interested in them for once 
work has resumed on the draft.

Scott K