Skip to main content

Signaling One-Click Functionality for List Email Headers
draft-levine-herkula-oneclick-10

Revision differences

Document history

Date Rev. By Action
2017-01-20
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2017-01-13
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2017-01-10
10 (System) RFC Editor state changed to RFC-EDITOR from IANA
2017-01-09
10 (System) RFC Editor state changed to IANA from EDIT
2016-12-09
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2016-12-08
10 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2016-12-08
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2016-12-08
10 Tero Kivinen Closed request for Telechat review by SECDIR with state 'No Response'
2016-12-05
10 (System) RFC Editor state changed to EDIT
2016-12-05
10 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2016-12-05
10 (System) Announcement was received by RFC Editor
2016-12-05
10 (System) IANA Action state changed to In Progress
2016-12-05
10 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent::Point Raised - writeup needed
2016-12-05
10 Cindy Morgan IESG has approved the document
2016-12-05
10 Cindy Morgan Closed "Approve" ballot
2016-12-01
10 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2016-12-01
10 John Levine New version available: draft-levine-herkula-oneclick-10.txt
2016-12-01
10 (System) New version approved
2016-12-01
10 (System) Request for posting confirmation emailed to previous authors: "John Levine" , "Tobias Herkula"
2016-12-01
10 John Levine Uploaded new revision
2016-12-01
09 Cindy Morgan IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from Waiting for Writeup
2016-12-01
09 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2016-11-30
09 Ben Campbell [Ballot comment]
Thanks for addressing my comments
2016-11-30
09 Ben Campbell Ballot comment text updated for Ben Campbell
2016-11-30
09 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2016-11-30
09 Alexey Melnikov
[Ballot comment]
Regarding JSON versa other formats question that came up during IETF LC: I believe this is an implementation preference and not everyone wants …
[Ballot comment]
Regarding JSON versa other formats question that came up during IETF LC: I believe this is an implementation preference and not everyone wants to have a JSON parser on the server side.

Similarly about what is exactly returned in the form-data.
2016-11-30
09 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2016-11-30
09 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2016-11-30
09 Alissa Cooper
[Ballot comment]
I agree with Stephen that either the SHOULD NOT send cookies, etc. bit should be changed to MUST NOT or the exceptional circumstances …
[Ballot comment]
I agree with Stephen that either the SHOULD NOT send cookies, etc. bit should be changed to MUST NOT or the exceptional circumstances under which it's ok to send them need to be listed. I don't get what those exceptions would be.
2016-11-30
09 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2016-11-29
09 Alexey Melnikov RFC Editor Note was changed
2016-11-29
09 Alexey Melnikov RFC Editor Note for ballot was generated
2016-11-29
09 Alexey Melnikov RFC Editor Note for ballot was generated
2016-11-28
09 John Levine New version available: draft-levine-herkula-oneclick-09.txt
2016-11-28
09 (System) New version approved
2016-11-28
09 (System) Request for posting confirmation emailed to previous authors: "John Levine" , "Tobias Herkula"
2016-11-28
09 John Levine Uploaded new revision
2016-11-07
08 Stephen Farrell
[Ballot comment]

Thanks for the changes from -07 to -08 which are good
enough to resolve my discuss points.

I note you say that cookies …
[Ballot comment]

Thanks for the changes from -07 to -08 which are good
enough to resolve my discuss points.

I note you say that cookies etc SHOULD NOT be sent,
whereas I'd argue for MUST NOT. If you want to leave
that at SHOULD NOT then please do add the logic for
when/why it is ok to send state information (which I
guess is to handle some kind of intranet/internal list
use cases is it?)

-- OLD DISCUSS BELOW

I have two discuss points, both much more of interest if
this spec is implemented within an MUA, which is not the
use-case that the authors are (very reasonably) mainly
interested in handling.

(1) This needs to say to never send client state (cookies
etc.) esp for the case the client is an MUA.

(2) The ability to cause the POST to match such a broad
range of web forms seems wrong. Surely there's no need for
that? Can't you limit the set of post data that are
allowed to be emitted in some way to get rid of that
aspect? I can't imagine such flexibility is really needed
for just this.

-- OLD COMMENTS BELOW

- I'm not clear whether or not changes discussed in the
secdir review [1] are all reflected in the current draft.

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06783.html

- I think it might be useful to more clearly state where
you really intend for this to be implemented, which iiuc
is within a webmail server.

- Intro: Why no mention of http schemed URLs? Wouldn't it
be a good idea to at least say these SHOULD/MUST NOT be
used?

- Section 4: The 2nd para there means that the http client
MUST NOT send the POST message unless the DKIM
signature is valid.  If that's correct (and I hope it is)
then might it be good to be more explicit about that? The
current wording doesn't tie the signature validation so
clearly to the action being (dis)allowed I think. (If
someone has implemented this based on just the I-D and
gotten this correct, then a change is probably not
needed.) I wonder if implementations will easily be able
to still check the DKIM signature status when sending the
http POST message, but I'll believe you if you tell me
that's ok.
2016-11-07
08 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2016-10-30
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2016-10-30
08 John Levine New version available: draft-levine-herkula-oneclick-08.txt
2016-10-30
08 (System) New version approved
2016-10-30
08 (System) Request for posting confirmation emailed to previous authors: "John Levine" , "Tobias Herkula"
2016-10-30
08 John Levine Uploaded new revision
2016-10-27
07 Alexey Melnikov Telechat date has been changed to 2016-12-01 from 2016-10-27
2016-10-27
07 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2016-10-27
07 Fernando Gont Request for Last Call review by GENART Completed: Not Ready. Reviewer: Fernando Gont.
2016-10-26
07 Joel Jaeggli [Ballot comment]
Victor Kuarsingh  performed the opsdir review
2016-10-26
07 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-10-26
07 Ben Campbell
[Ballot comment]
I agree with Stephen's discuss points.

Is there a potential for this mechanism to be used to verify that spam mail found a …
[Ballot comment]
I agree with Stephen's discuss points.

Is there a potential for this mechanism to be used to verify that spam mail found a real email address? (Realizing of course that there are already a zillion mechanisms for that.)
2016-10-26
07 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2016-10-26
07 Kathleen Moriarty [Ballot comment]
I support Stephen's discuss points and also did not find any changes that resulted from the SecDir review.

Thanks.
2016-10-26
07 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2016-10-26
07 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2016-10-26
07 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2016-10-26
07 Stephen Farrell
[Ballot discuss]

I have two discuss points, both much more of interest if
this spec is implemented within an MUA, which is not the
use-case …
[Ballot discuss]

I have two discuss points, both much more of interest if
this spec is implemented within an MUA, which is not the
use-case that the authors are (very reasonably) mainly
interested in handling.

(1) This needs to say to never send client state (cookies
etc.) esp for the case the client is an MUA.

(2) The ability to cause the POST to match such a broad
range of web forms seems wrong. Surely there's no need for
that? Can't you limit the set of post data that are
allowed to be emitted in some way to get rid of that
aspect? I can't imagine such flexibility is really needed
for just this.
2016-10-26
07 Stephen Farrell
[Ballot comment]

- I'm not clear whether or not changes discussed in the
secdir review [1] are all reflected in the current draft.

  [1] …
[Ballot comment]

- I'm not clear whether or not changes discussed in the
secdir review [1] are all reflected in the current draft.

  [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06783.html

- I think it might be useful to more clearly state where
you really intend for this to be implemented, which iiuc
is within a webmail server.

- Intro: Why no mention of http schemed URLs? Wouldn't it
be a good idea to at least say these SHOULD/MUST NOT be
used?

- Section 4: The 2nd para there means that the http client
MUST NOT send the POST message unless the DKIM
signature is valid.  If that's correct (and I hope it is)
then might it be good to be more explicit about that? The
current wording doesn't tie the signature validation so
clearly to the action being (dis)allowed I think. (If
someone has implemented this based on just the I-D and
gotten this correct, then a change is probably not
needed.) I wonder if implementations will easily be able
to still check the DKIM signature status when sending the
http POST message, but I'll believe you if you tell me
that's ok.
2016-10-26
07 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2016-10-25
07 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2016-10-25
07 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2016-10-25
07 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2016-10-25
07 Alexey Melnikov
[Ballot comment]
Regarding JSON versa other formats question that came up during IETF LC: I believe this is an implementation preference and not everyone wants …
[Ballot comment]
Regarding JSON versa other formats question that came up during IETF LC: I believe this is an implementation preference and not everyone wants to have a JSON parser on the server side.

I might defer this document to early December, as editors are planning some (hopefully minor) changes to the document. But people might as well review this now, so that John can talk to people in Seoul, if any DISCUSS needs discussing face-to-face.
2016-10-25
07 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2016-10-24
07 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2016-10-22
07 Alexey Melnikov Ballot has been issued
2016-10-22
07 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2016-10-22
07 Alexey Melnikov Created "Approve" ballot
2016-10-22
07 Alexey Melnikov Ballot writeup was changed
2016-10-14
07 Tero Kivinen Request for Telechat review by SECDIR is assigned to Ben Laurie
2016-10-14
07 Tero Kivinen Request for Telechat review by SECDIR is assigned to Ben Laurie
2016-10-12
07 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Victor Kuarsingh.
2016-10-10
07 Alexey Melnikov Placed on agenda for telechat - 2016-10-27
2016-10-10
07 (System) IESG state changed to Waiting for Writeup from In Last Call
2016-10-07
07 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2016-10-07
07 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-levine-herkula-oneclick-04.txt. If any part of this review is inaccurate, please let …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-levine-herkula-oneclick-04.txt. If any part of this review is inaccurate, please let us know.

Upon approval of this document, we understand that we have only one action to complete:

In the Permanent Message Header Field Names subregistry of the Message Headers registry located at:

https://www.iana.org/assignments/message-headers/

a single new field name is to be registered as follows:

Header Field Name: List-Unsubscribe-Post
Template:
Protocol: mail
Status: standard
Reference: [ [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

We understand that this is the only action 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
2016-09-28
07 Tobias Herkula New version approved
2016-09-28
07 Tobias Herkula New version available: draft-levine-herkula-oneclick-07.txt
2016-09-28
07 Tobias Herkula Request for posting confirmation emailed to previous authors: ben@nostrum.com, "Tobias Herkula" , alissa@cooperw.in, "John R. Levine" , aamelnikov@fastmail.fm
2016-09-28
07 (System) Uploaded new revision
2016-09-22
06 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Ben Laurie.
2016-09-21
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2016-09-21
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Victor Kuarsingh
2016-09-20
06 John Levine New version approved
2016-09-20
06 John Levine New version available: draft-levine-herkula-oneclick-06.txt
2016-09-20
06 John Levine Request for posting confirmation emailed to previous authors: art-chairs@ietf.org, "Tobias Herkula" , "John R. Levine"
2016-09-20
06 (System) Uploaded new revision
2016-09-15
05 Jean Mahoney Request for Last Call review by GENART is assigned to Fernando Gont
2016-09-15
05 Jean Mahoney Request for Last Call review by GENART is assigned to Fernando Gont
2016-09-15
05 John Levine New version approved
2016-09-15
05 John Levine New version available: draft-levine-herkula-oneclick-05.txt
2016-09-15
05 John Levine Request for posting confirmation emailed to previous authors: art-chairs@ietf.org, "Tobias Herkula" , "John R. Levine"
2016-09-15
05 (System) Uploaded new revision
2016-09-15
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Ben Laurie
2016-09-15
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Ben Laurie
2016-09-12
04 Amy Vezza IANA Review state changed to IANA - Review Needed
2016-09-12
04 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alexey.melnikov@isode.com, "Paul Kincaid-Smith" , paulkincaidsmith@gmail.com, draft-levine-herkula-oneclick@ietf.org
Reply-To: ietf@ietf.org
Sender: …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alexey.melnikov@isode.com, "Paul Kincaid-Smith" , paulkincaidsmith@gmail.com, draft-levine-herkula-oneclick@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Signalling one-click functionality for list email headers) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Signalling one-click functionality for list email headers'
  as Proposed 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-10-10. 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 document describes a method for signaling a one-click function
  for the list-unsubscribe email header.  The need for this arises out
  of the actuality that mail software sometimes fetches URLs in mail
  headers, and thereby accidentally triggers unsubscriptions in the
  case of the list-unsubscribe header.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-levine-herkula-oneclick/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-levine-herkula-oneclick/ballot/


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




2016-09-12
04 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2016-09-12
04 Alexey Melnikov
My AD review:

General comment: I would have liked to see ABNF of the new header field
defined in this document, as it is customary …
My AD review:

General comment: I would have liked to see ABNF of the new header field
defined in this document, as it is customary for header field
definition.

5.1.  Mail senders

  The One-Click action triggered by this URI SHOULD complete promptly
  and not burden the requester in an inappropriate way.  The sending
  entity cannot expect that HTTP redirects are followed by the
  requester.

I am a bit concerned that this is restricting use of regular HTTP. Is
there a reason not to support redirects?

5.2.  Mail receivers

  A receiving entity which wants to use a List-Unsubscribe HTTP URI

Should the above be HTTPS?

Either way HTTP/HTTPS need Normative References pointing to RFC 7230.

  from an email that also contains a List-Unsubscribe-Post header
  performs an HTTPS POST to the first HTTPS URI in the List-Unsubscribe
  header and send the content of the List-Unsubscribe-Post header as
  the request body.
2016-09-12
04 Alexey Melnikov Last call was requested
2016-09-12
04 Alexey Melnikov Last call announcement was generated
2016-09-12
04 Alexey Melnikov Ballot approval text was generated
2016-09-12
04 Alexey Melnikov Ballot writeup was generated
2016-09-12
04 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation
2016-09-12
04 Alexey Melnikov IESG state changed to AD Evaluation from Publication Requested::External Party
2016-09-12
04 Alexey Melnikov
1. Summary
The Document Shepherd for this document is Paul Kincaid-Smith. The responsible Area Director is Alexey Melnikov.

This document describes a method for signaling …
1. Summary
The Document Shepherd for this document is Paul Kincaid-Smith. The responsible Area Director is Alexey Melnikov.

This document describes a method for signaling a one-click function for the List-Unsubscribe email header. The proposed method will reduce accidental unsubscribes that occur when some mail software fetches URLs in mail headers, thereby accidentally triggering unintended unsubscriptions.

2. Review and Consensus
This document represents the consensus of a M3AAWG.org working group and has incorporated recommendations made on the IETF dispatch list. All technical issues raised have been resolved. I have no concerns about the level of review this document has received.

The following two questions were discussed in detail on the dispatch list. The latter was incorporated into Draft 04.

Question #1: Should JSON be used to structure the arguments to the unsubscribe request?
Answer: To simplify implementation (and thus adoption of this proposed RFC) the unsubscribe arguments will be passed as simple tags and strings (which are set by the bulk sender anyway, and it’s their servers that will process these tags and strings.)
Resolution: Don’t use JSON to pass unsubscribe arguments because it’ll increase the complexity of the server-side implementation required by bulk mail providers.

Question #2: Why does the POST need a content-type of application/x-www-form-urlencoded?
Answer: multipart/form-data is an option
Resolution: Draft 04 adopts the recommendation a content-type of multipart/form-data

At least one major webmail provider intends to implement the List-Unsubscribe-Post mechanism described in this document in 2016, and expressed support on the IETF dispatch list.

3. Intellectual Property
Each author has confirmed conformance with BCPs 78 and 79.

4. Other Points
There are no “downward references” in this document. All normative RFCs referenced are either established standards or are on the standards track.
2016-09-12
04 Alexey Melnikov Notification list changed to "Paul Kincaid-Smith" <paulkincaidsmith@gmail.com>
2016-09-12
04 Alexey Melnikov Document shepherd changed to Paul Kincaid-Smith
2016-08-29
04 Alexey Melnikov Waiting for shepherding write-up before proceeding with publication.
2016-08-29
04 Alexey Melnikov IESG state changed to Publication Requested::External Party from AD is watching
2016-08-29
04 Alexey Melnikov Changed consensus to Yes from Unknown
2016-08-23
04 John Levine New version available: draft-levine-herkula-oneclick-04.txt
2016-08-09
03 Tobias Herkula New version available: draft-levine-herkula-oneclick-03.txt
2016-08-04
02 Alexey Melnikov Assigned to Applications and Real-Time Area
2016-08-04
02 Alexey Melnikov Intended Status changed to Proposed Standard
2016-08-04
02 Alexey Melnikov IESG process started in state AD is watching
2016-08-04
02 Alexey Melnikov Stream changed to IETF from None
2016-07-22
02 John Levine New version available: draft-levine-herkula-oneclick-02.txt
2016-07-19
01 Tobias Herkula New version available: draft-levine-herkula-oneclick-01.txt
2016-07-08
00 Tobias Herkula New version available: draft-levine-herkula-oneclick-00.txt