Message Disposition Notification
draft-ietf-appsawg-mdn-3798bis-16

[Ballot comment]
Thanks for the good work to improve the privacy properties here.

= Section 6.2 =

"Disposition mode (Section 3.2.6.1) can leak information about
  recipient's MUA configuration, in particular whether MDNs are
  acknowledged manually or automatically.  If this is a concern, MUAs
  can return "manual-action/MDN-sent-manually" disposition mode in
  generated MDNs."

I see why this is here, but doesn't recommending falsifying these fields put their integrity in question whenever they are set to manual? I mean, why would recipients trust this information if the RFC actually suggests sending a field that lies about an MDN being automatically acknowledged?

= Section 6.2.2 =

"The "Reporting-UA" field (Section 3.2.1) might contain enough
  information to uniquely identify a specific device, usually when
  combined with other characteristics, particularly if the user agent
  sends excessive details about the user's system or extensions.
  However, the source of unique information that is least expected by
  users is proactive negotiation, including the Accept-Language header
  fields."

I think the use of "However" is tripping me up here. Earlier in the document you have good recommendations about how to mitigate the risk of fingerprinting based on the Reporting-UA field. That guidance is valid regardless of whether other header fields might also contribute to fingerprinting or whether users would expect that (frankly, I don't see how user expectations are relevant here, since most users don't understand fingerprinting anyway). I think something along the following lines to replace the last sentence above would be more accurate: "Even when the guidance in Section 3.2.1 is followed to avoid fingerprinting, other sources of unique information may still be present, including the Accept-Language header fields."

[Ballot comment]
Should the Media-Type registration go to the authors of the draft, as specified, or instead to the appsawg & eventually defaulting to the IESG?

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-appsawg-mdn-3798bis-15.txt. If any part of this review is inaccurate, please let us know.

Upon approval of this document, we understand that there are three registry actions to complete.

First, in the message subregistry of the Media Type registry located at:

https://www.iana.org/assignments/media-types/

the registration template for the

message/disposition-notification

media type will be changed to the text in Section 3.1 of the current document.

In addition, the reference will be changed to [ RFC-to-be ].

Second, the following registries in the Message Disposition Notification (MDN) Parameters located at:

https://www.iana.org/assignments/mdn/

will each have their references changed from RFC3798 to [ RFC-to-be ]:

MDN-Disposition-modifier-names
MDN-Disposition-notification-option-names
MDN-Extension-field-names

We understand that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, "Barry Leiba" , appsawg-chairs@ietf.org, art@ietf.org, superuser@gmail.com, draft-ietf-appsawg-mdn-3798bis@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Message Disposition Notification) to Internet Standard


The IESG has received a request from the ART Area General Applications
Working Group WG (appsawg) to consider the following document:
- 'Message Disposition Notification'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-11-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo defines a MIME content-type that may be used by a mail user
  agent (MUA) or electronic mail gateway to report the disposition of a
  message after it has been successfully delivered to a recipient.
  This content-type is intended to be machine-processable.  Additional
  message header fields are also defined to permit Message Disposition
  Notifications (MDNs) to be requested by the sender of a message.  The
  purpose is to extend Internet Mail to support functionality often
  found in other messaging systems, such as X.400 and the proprietary
  "LAN-based" systems, and often referred to as "read receipts,"
  "acknowledgements", or "receipt notifications."  The intention is to
  do this while respecting privacy concerns, which have often been
  expressed when such functions have been discussed in the past.

  Because many messages are sent between the Internet and other
  messaging systems (such as X.400 or the proprietary "LAN-based"
  systems), the MDN protocol is designed to be useful in a multi-
  protocol messaging environment.  To this end, the protocol described
  in this memo provides for the carriage of "foreign" addresses, in
  addition to those normally used in Internet Mail.  Additional
  attributes may also be defined to support "tunneling" of foreign
  notifications through Internet Mail.

  This document obsoletes RFC 3798, moving it to Internet Standard.  It
  also updates RFC 2046 (message/partial Media Type handling) and RFC
  3461 (Original-Recipient header field generation requirement).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-appsawg-mdn-3798bis/ballot/


No IPR declarations have been submitted directly on this I-D.

The document contains these normative downward reference to a Proposed Standard:

    rfc3503: Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP) (Proposed Standard - Legacy stream)

Additionally, the document contains these normative downward references to Draft Standards:

    rfc5321: Simple Mail Transfer Protocol (Draft Standard - IETF stream)
    rfc3461: Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs) (Draft Standard - IETF stream)
    rfc3464: An Extensible Message Format for Delivery Status Notifications (Draft Standard - IETF stream)
    rfc2047: MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text (Draft Standard - IETF stream)
    rfc2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (Draft Standard - IETF stream)

See RFC 3967 for additional information. Note that some of these references may already be listed in the acceptable Downref Registry.

Hi,

Here is my AD evaluation of draft-ietf-appsawg-mdn-3798bis-11. I think we need to discuss at least some of this prior to this going to IETF last call.

Process:

- The shepherd report describes lackluster working group participation. Is the shepherd comfortable that this has had sufficient review?

-1, paragraph 4: This says the memo has pre5378Trust200902 boilerplate. It doesn't seem to actually have it. Have the 3798 authors agreed to release?

- The shepherd report recommends listing errata that was addressed in Appendix A. I agree that would be helpful. Can that happen before we go to last call?

Substantive:

- 2.1, paragraph 8:
Does this assume that it's reasonable for such consent to be global? That is, do we assume recipient will want the same MDN policy for every sender?

Why does the default to not send MDNs depend on whether the consent comes via a preference setting? If you ask the user to decide for each MDN, should the default choice be "No"?

-2.1, last paragraph: Seems like this deserves a MUST

-2.2: Would it make sense to offer some more guidance about registering "X-..." attributes? I suspect we would rather people not name substantially new attributes that way, and that such registrations should really be used for existing "X-..." attributes that have fallen into common use? (And also that any such registration needs to use care not to conflict with commonly used existing X- attributes? (If any exist?)

-6.2, paragraph 5:
Seems like we could use a stronger statement not to send information that had been encrypted in the original message as clear-text in an MDN. Would a MUST NOT be reasonable here?


Editorial and nits:

- idnits returns some warnings, please check. I think most are spurious, but some may not be.

-2.1, paragraph 7: s/laverage/leverage

-2.1, paragraph 11:
Since RFC 5322 has the authoritative text about case sensitigy, consider making the related MUST and SHOULD descriptive rather than normative. (e.g. "The comparison is case-sensitive...." and "The local-part comparison is done after..."

-2.1, last paragraph: This paragraph switches to 2nd person imperative from the previous 3rd person. Is there a reason? The change for just this one paragraph is a bit jarring.

- 3.2.6.3, disposition-modifier-extension: s/"MUST not"/"MUST NOT"

-4, step starting with "(Recipient's ) MUA discovers:

s/MDN has been generated/MDN has already been generated

- Appendix A: Is this expected to stay in the final RFC?

1. Summary

Murray Kucherawy is the document shepherd.  Barry Leiba is the (outgoing) responsible Area Director.

This is an update to an existing Standards Track document.  The Abstract:

  This memo defines a MIME content-type that may be used by a mail user
  agent (MUA) or electronic mail gateway to report the disposition of a
  message after it has been successfully delivered to a recipient.
  This content-type is intended to be machine-processable.  Additional
  message header fields are also defined to permit Message Disposition
  Notifications (MDNs) to be requested by the sender of a message.  The
  purpose is to extend Internet Mail to support functionality often
  found in other messaging systems, such as X.400 and the proprietary
  "LAN-based" systems, and often referred to as "read receipts,"
  "acknowledgements", or "receipt notifications."  The intention is to
  do this while respecting privacy concerns, which have often been
  expressed when such functions have been discussed in the past.

  Because many messages are sent between the Internet and other
  messaging systems (such as X.400 or the proprietary "LAN-based"
  systems), the MDN protocol is designed to be useful in a multi-
  protocol messaging environment.  To this end, the protocol described
  in this memo provides for the carriage of "foreign" addresses, in
  addition to those normally used in Internet Mail.  Additional
  attributes may also be defined to support "tunneling" of foreign
  notifications through Internet Mail.

2. Review and Consensus

The document received general "Yes, this should happen" support at WG meetings, but unfortunately very little came in the way of active review.  The working group appears to have trusted that the authors were doing good work and knew what they were doing and, if there were any problems found, they were not reported.  MAAWG was also solicited for comments, but none were received (that I know of).  In any case, there was no objection to its adoption by and publication through APPSAWG.

There were no significant points of controversy or other difficulty.

No directorate reviews were solicited, and none seem to be appropriate.

3. Intellectual Property

Of particular note is the following in Section 1:

  This memo is currently marked with the 'pre5378Trust200902' IPR
  statements until a release has been obtained from all previous
  authors and editors of this text.

The IESG may want to wait for this to be resolved before Last Call.  This writeup is done with it still in the document; I can edit it later if that condition changes.

4. Other Points

There are no downward references needing special attention during Last Call.

The IANA Considerations were reviewed and look good.  The only point of note here is MUSTard in the section; there seem to be varying opinions among IESG members over the years as to whether this is appropriate.

The first word of Appendix A is spelled incorrectly.

The IESG might want to suggest that existing errata against RFC3798 be highlighted in Appendix A explicitly, by number, assuming they were addressed.  Previous IESGs have found this useful with my own documents.

1. Summary

Murray Kucherawy is the document shepherd.  Barry Leiba is the (outgoing) responsible Area Director.

This is an update to an existing Standards Track document.  The Abstract:

  This memo defines a MIME content-type that may be used by a mail user
  agent (MUA) or electronic mail gateway to report the disposition of a
  message after it has been successfully delivered to a recipient.
  This content-type is intended to be machine-processable.  Additional
  message header fields are also defined to permit Message Disposition
  Notifications (MDNs) to be requested by the sender of a message.  The
  purpose is to extend Internet Mail to support functionality often
  found in other messaging systems, such as X.400 and the proprietary
  "LAN-based" systems, and often referred to as "read receipts,"
  "acknowledgements", or "receipt notifications."  The intention is to
  do this while respecting privacy concerns, which have often been
  expressed when such functions have been discussed in the past.

  Because many messages are sent between the Internet and other
  messaging systems (such as X.400 or the proprietary "LAN-based"
  systems), the MDN protocol is designed to be useful in a multi-
  protocol messaging environment.  To this end, the protocol described
  in this memo provides for the carriage of "foreign" addresses, in
  addition to those normally used in Internet Mail.  Additional
  attributes may also be defined to support "tunneling" of foreign
  notifications through Internet Mail.

2. Review and Consensus

The document received general "Yes, this should happen" support at WG meetings, but unfortunately very little came in the way of active review.  The working group appears to have trusted that the authors were doing good work and knew what they were doing and, if there were any problems found, they were not reported.  MAAWG was also solicited for comments, but none were received (that I know of).  In any case, there was no objection to its adoption by and publication through APPSAWG.

There were no significant points of controversy or other difficulty.

No directorate reviews were solicited, and none seem to be appropriate.

3. Intellectual Property

Of particular note is the following in Section 1:

  This memo is currently marked with the 'pre5378Trust200902' IPR
  statements until a release has been obtained from all previous
  authors and editors of this text.

The IESG may want to wait for this to be resolved before Last Call.  This writeup is done with it still in the document; I can edit it later if that condition changes.

The authors of this version have not yet affirmed compliance with BCPs 78 and 79.

4. Other Points

There are no downward references needing special attention during Last Call.

The IANA Considerations were reviewed and look good.  The only point of note here is MUSTard in the section; there seem to be varying opinions among IESG members over the years as to whether this is appropriate.

The first word of Appendix A is spelled incorrectly.

The IESG might want to suggest that existing errata against RFC3798 be highlighted in Appendix A explicitly, by number, assuming they were addressed.  Previous IESGs have found this useful with my own documents.