Mailing Lists and Internationalized Email Addresses
draft-ietf-eai-mailinglist-07

[Ballot discuss]
[UPDATED per discussion with document shepherd and IESG]

Overall this is a clear and carefully-constructed specification. I have a few questions that I'd like answered before recommending it for approval.

1. [addressed via RFC Editor note]

2. [agreed that the context here is IRIs, so the current text is fine]

3. [no interoperability impact here because the List-ID is opaque]

4. [defined in RFC 2909]

5. [addressed by RFC Editor note]

[Ballot discuss]
[UPDATED per discussion with document shepherd and IESG]

Overall this is a clear and carefully-constructed specification. I have a few questions that I'd like answered before recommending it for approval.

1. [addressed via RFC Editor note]

2. [agreed that the context here is IRIs, so the current text is fine]

3. [no interoperability impact here because the List-ID is opaque]

4. [defined in RFC 2909]

5. To expand on Dan Romascanu's COMMENT regarding the security considerations, RFC 4952 does not seem to discuss the use of email addresses for authorization decisions. Given that a mailing list subscription is one kind of authorization decision, it seems possible that an attacker could subscribe to a mailing list using a UTF-8 address whose alt-address matches the (non-UTF-8) address of a victim, thus potentially preventing the victim from subscribing to the list. Similarly, the attacker could send messages from its i18n-address but subscribers that are not UTF8SMTP-aware might attribute the message to the victim's (non-UTF-8) address. Finally, the list itself could use an alt-address that matches the (non-UTF-8) address of another list. Are these attacks possible? If so, are there guidelines regarding these cases in RFC 4952 but I'm simply missing them? Does this spec need to have some text about the potential mismatch between a UTF-8 address and an alt-address?

I suggest the following text:

  Because use of both a UTF-8 address and an alt-address for
  the same entity introduces a potential ambiguity regarding
  the identity of list subscribers and message senders,
  implementers are advised to carefully handle authorization
  decisions regarding subscriptions, sender filters, and other
  common list administration features.

[Ballot comment]
I support Peter's discuss issue 5 (also appearing in Dan's comment) regarding the security
considerations.  The attacks Peter lists seem to fall outside the scope of 4952's security
considerations, and should be addressed in this document.

[Ballot discuss]
Overall this is a clear and carefully-constructed specification. I have a few questions that I'd like answered before recommending it for approval.

1. Section 5 states: "These mailing list header fields contain URLs." However, that is not true of List-ID.

2. This statement might be confusing to readers:

    ... discussion on whether internationalized domain
    names should be percent-encoded or puny-coded, is
    ongoing; see [IRI-bis]

Does it make sense to reference the IDNAbis work here, since it is concluded and directly covers the topic of internationalized domain names (as opposed to the less direct discussion in IRI-bis)? Will interoperability suffer if this specification does not make a recommendation regarding percent-encoded vs. puny-coded IDNs?

3. The paragraph about List-ID at the end of Section 5 does not make a recommendation. For example, it could say: "Therefore, the value of the List-ID header field SHOULD NOT contain ASCII encodings of non-ASCII values." Did the WG have consensus to avoid making a recommendation here?

4. Also, the paragraph about List-ID at the end of Section 5 does not mention whether it is reasonable to include non-ASCII values that have not been encoded into ASCII. Was this also the intent of the WG?

5. To expand on Dan Romascanu's COMMENT regarding the security considerations, RFC 4952 does not seem to discuss the use of email addresses for authorization decisions. Given that a mailing list subscription is one kind of authorization decision, it seems possible that an attacker could subscribe to a mailing list using a UTF-8 address whose alt-address matches the (non-UTF-8) address of a victim, thus potentially preventing the victim from subscribing to the list. Similarly, the attacker could send messages from its i18n-address but subscribers that are not UTF8SMTP-aware might attribute the message to the victim's (non-UTF-8) address. Finally, the list itself could use an alt-address that matches the (non-UTF-8) address of another list. Are these attacks possible? If so, are there guidelines regarding these cases in RFC 4952 but I'm simply missing them? Does this spec need to have some text about the potential mismatch between a UTF-8 address and an alt-address?

[Ballot discuss]
1. Section 5 states: "These mailing list header fields contain URLs." However, that is not true of List-ID.

2. This statement might be confusing to readers:

    ... discussion on whether internationalized domain
    names should be percent-encoded or puny-coded, is
    ongoing; see [IRI-bis].

Does it make sense to reference the IDNAbis work here, since it is concluded and directly covers the topic of internationalized domain names (as opposed to the less direct discussion in IRI-bis)? Will interoperability suffer if this specification does not make a recommendation regarding percent-encoded vs. puny-coded IDNs?

3. The paragraph about List-ID at the end of Section 5 does not make a recommendation. For example, it could say: "Therefore, the value of the List-ID header field SHOULD NOT contain ASCII encodings of non-ASCII values." Did the WG have consensus to avoid making a recommendation here?

4. Also, the paragraph about List-ID at the end of Section 5 does not mention whether it is reasonable to include non-ASCII values that have not been encoded into ASCII. Was this also the intent of the WG?

[Ballot comment]
In the OPS-DIR review Mehmet Ersue made the observation that the Security Consideration section refers to RFC 4952, and that no further security considerations are raised by this document. However, the security consideration section in 4952 seems to deal with various threats resulting from the expansion of the charaters sets in messages and specifically in addresses and headers, but does not deal at all with mail lists. I am wondering if there are not specific threats related to mail lists. Did the security reviewer and ADs see and agree that there is no potential problem here?

Document title: draft-ietf-eai-mailinglist-07.txt

Document shepherd: Pete Resnick

Shepherd review: I have personally reviewed this document and believe it is ready for forwarding to the IESG for publication as an Experimental protocol.

Working Group review: This document has gotten significant review in the EAI working group, both on the mailing list and in discussion at IETF meetings. Because of the nature of this document, there are virtually no key IETFers who have not participated, at least in small measure, in EAI WG discussions. The document has been reviewed by folks who have been working on IETF email protocols for many years as well as current implementers. I have no concerns about the level of review of this document.

WG Consensus: There is solid WG for this document. At least 7 WG members (of a small WG) gave direct feedback on the document, and there was reasonable discussion in face-to-face meetings. The document primarily makes recommendations for mailing list behavior, so the issues were not terribly controversial.

No appeal or discontent is apparent or imminent.

ID nits has been checked. The IPR boilerplate is an older one, but still acceptable as far as I know.

References are now appropriately split between normative and non-normative.

There is an IANA Considerations section that, correctly, indicates that there are none.

There are no formal language (e.g., ABNF) sections.

Document announcement writeup:

Technical Summary
    This document describes considerations for mailing lists with the introduction of internationalized email addresses in RFC 5335 and makes some specific recommendations on how mailing lists should act in various situations.

Working Group Summary
    The EAI Working Group produced this document and it is the result of solid consensus in the WG for these recommendations.

Document Quality
    Experimental implementations of this document are currently underway, though not completed.

IANA comments:

Note to author:
You use the term "i18mail." What is "internationalizatiomail"[sic]?
If you meant "internationalizationmail," the term would be "i19mail" (or
possibly "i18nmail").

As described in the IANA Considerations section, we understand this
document to have NO IANA Actions.