Dear Authors,
      







** Apologize for lateness, email stuck in my outbox from weekend
      **





      I have reviewed this document as part of the Operational
      directorate's ongoing effort to review all IETF documents being
      processed by the IESG.  These comments were written with the
      intent of improving the operational aspects of the IETF drafts.
      Comments that are not addressed in last call may be included in AD
      reviews during the IESG review.  Document editors and WG chairs
      should treat these comments just like any other last call
      comments.
      





      Document Reviewed - Signalling one-click functionality for list
      email headers


      Link to Document - 

https://tools.ietf.org/html/draft-levine-herkula-oneclick-07











      Summary:
      





      This document provides a signalling method and model that provides
      facilities for a "one-click" list-unsubscribe.  The reasoning
      behind this advancement is due to the need for an efficient option
      for list-unsubscribe and operational behaviours observed in the
      field (such as mail software fetching URLs in mail header fields).




The document provides information on header requirements, syntax
      and use.




Text updates (suggestions / recommendations) are provided below
      the general feedback.
      










General Comments and Feedback:
      







The document provides the needed header information to provide
      the one-click facilities.  No specific recommendations are made as
      part of this review on changes to the updated header information. 
      However, although security considerations were listed within the
      document, there are a few open questions as to how the authors
      expect this new functionality to coexist with clients and mail
      systems that are not aware of the new one-click function/headers. 
      The document is not quite clear on how the backwards compatibility
      would work (and/or it's to obvious in the body text).




It's possible this information may be know by the typical reader
      of this document, however, it would be advisable that such
      information be specifically captured and highlighted (backwards
      compatibility and co-existence).  Given this is a standards track
      document, the information can be limited to expected protocol,
      client and mail system implementation behaviors.







Other comments and feedback are minor and listed in the section
      below.  To make it easier to know where the in-line review is
      associated with, I have also attached a high-lighted PDF version
      of the -07 draft (for quick reference).











      Textual Review, questions and feedback:
      







Abstract - ok





      Introduction - three suggestions





      P2:





      BEFORE: Many mail systems allow


      recipients to report mail as spam or junk, and mail from senders
      with


      a lot of junk reports often has poor deliverability.





      SUGGESTED: Many mail systems allow recipients to report mail as
      spam or junk, and senders whom are associated with


      a higher volume of junk reports will often experience poor ongoing
      deliverability as a result.





      BEFORE: ...since the recipients alternative to a difficult


      unsubscription process is to report mail from the sender as junk


      until it goes away.





      SUGGESTED: ... since the recipient’s alternative to a difficult
      unsubscription process


      is to report mail from the sender as junk until new mail delivery
      ceases.





      SUGGESTION: Define key terms used such as MUA (Mail User Agent). 








      Section 2 - ok








      Section 3.1 - comments below





      P1: 





      BEFORE: "An mail sender that wishes to enable one-click
      unsubscribes places..." 





      SUGGESTED " A mail sender that wishes to enable a one-click
      unsubscription places ... "





      P3:





      BEFORE: "The server handling the


      unsubscription SHOULD verify that the hard to forge component is


      valid"





      SUGGESTED: "The server handling the unsubscription SHOULD verify
      that the opaque identifier component is valid"





      P4:





      TEXT to verify : "The mail


      sender MUST NOT return an HTTPS redirect, since redirected POST


      actions have historically not worked reliably" - is this a well
      known statement/condition which is unrefutable?





      OPTION: Can use language such as "... since redirected POST
      actions are considered unreliable".








      Section 3.2 - comments below





      P1:





      BEFORE: "A mail receiver that wants do a one-click unsubscription
      performs an


      HTTPS POST to the HTTPS URI...."





      SUGGESTION" "A mail receiver that wishes to conduct a one-click
      unsubsription ..."





      P3: 





      OPS RELATED FEEDBACK: "When and how the user consent is obtained
      is


      not part of this specification.". - would suggesting a few options
      to gain user consent useful here?  








      Section 4 - ok.





      Section 5 - comments below





      OPS RELATED FEEDBACK: You may want to put a box, or change the
      font type for the specification text to make it clear.





      Section 6 - ok.





      Section 7 - ok.





      Section 8 - 





      P3: 





      BEFORE: "Since the mailer’s server that receives the POST request
      cannot in


      general tell where the request coming from,..."





      SUGGESTED: " Since the mailer's server that receives the POST
      request cannot, in general, identify 


      where the request is coming from,.."











      regards,










Victor K























































Attachment:


draft-levine-herkula-oneclick-07-highlight_vk.pdf




Description:

 Adobe PDF document