Hi List,
I'm working on a document about a topic that came out of an open
roundtable discussion at M³AAWG, it is more or less a way for mail
senders to signal that a URI in the List-Unsubscribe Header has
"One-Click" functionality and therefore can be triggered by backend
systems to provide MUA users a better way to unsubscribe from bulk
commercial mail that is reputable enough.
We as an ESP implemented it for our customers so if you are curious
about it, there is a chance that you already getting traffic with this
feature enabled.
I'm writing here because I'm looking for more input about it and if it
interesting enough for ISPs or MUA provider.
It's a public document and I welcome requests with updates...
https://github.com/Lockhead/oneclick/blob/master/draft-herkula-oneclick.txt
For people on the road a copy of the document is attached to this
mail...
Kind regards,
/ Tobias Herkula
--
optivo GmbH
Head of Deliverability & Abuse Management
Wallstraße 16
10179 Berlin
Germany
Tel: +49(0)30-768078-129
Fax: +49(0)30-768078-499
Email: mailto:t.herk...@optivo.com
Website: http://www.optivo.com
Linkedin: http://www.linkedin.com/in/tobiasherkula
Commercial register: HRB 88738 District Court Berlin-Charlottenburg
Executive board: Dr. Rainer Brosch, Thomas Diezmann
Vat reg. no.: DE813696618
optivo A company of Deutsche Post DHL Group
INFORMATIONAL Tobias Herkula
draft-herkula-oneclick.txt optivo GmbH
June 2016
Signaling "One-Click" functionality for HTTPS URIs in email headers
Status of this Memo
This document is not an Internet Standards Track specification; it is
for informational purposes and requests discussion and suggestions
for improvements. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) Tobias Herkula (2016). All rights reserved.
Abstract
This document describes a simplified method for signaling "One-Click"
functionality for HTTPS URIs as they appear in email headers. The
need for this arises out of the fact, that third-party entities
involved in the processing of emails sometimes unintendedly trigger
actions that are subject to the user and shall not be triggered
automatically without an user's intent.
1. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
a. "One-Click": In the context of this document, describes an HTTPS
URI that directly triggers a change in a system that shall only
be applied if the request to that HTTPS URI is done with an
user's intent.
b. "Organizational Domain": Is to be interpreted as described in
[RFC7489#section-3]
c. "Domain Alignment": In the context of this document, means that
two domains share the same organizational domain.
d. "signal-constant": fixed string "=One-Click"
2. Introduction
An email header can contain HTTPS URIs for extended functionality,
for example List-Headers [RFC2369]. In case of the List-Unsubscribe
Header the HTTPS URI is mandated to unsubscribe the recipient of the
email directly from the list. This requirement is often not
implemented because anti-spam solutions request all found external
resources, this is considered unintended malicious behavior. In
consequence senders implement landing pages asking to confirm the
unsubscribe request. This specification tries to solve one part of
this, as it proposes a pattern to detect "One-Click" functionality.
It defines a specific format for the fragment part of a HTTPS URI and
a specific transformation for the receiver. A request to the
transformed HTTPS URI from somebody who adheres to this specification
can be distinguished from other requests and therefore handled
independently.
3. High-Level Goals
o Allow email senders to signal "One-Click" functionality for
specific HTTPS URIs used in email headers.
o Allow MUA owners to implement independent user interface features
for a better user experience.
o Allow MUA users to trigger intended actions in a familiar
environment.
4. Out of Scope
This proposal does not solve problems associated with intended
malicious behavior by users or robots.
5. Implementation
5.1 Sender
A sending entity which is responsible for the content of an email,
that wishes to add an actionable HTTPS URI in the header of an email,
shall add the name of the Header followed by signal-constant, as the
URI fragment. The sending entity also needs to provide the infrastructure
to handle GET and or POST requests to this URI in an appropriate volume.
The "One-Click" action triggered by such URIs must complete in an appropriate
timeframe and should never burden the requester in an inappropriate way.
The sending entity cannot expect that HTTP redirects are followed by the
requester.
Repeated requests to the same URI must be handled like all other requests.
5.2 Receiver
A receiving entity which wants to use a HTTPS URI that signals
"One-Click" functionality, shall take the key-value pair out of the
fragment part of the URI and add it as additional URI key-value
parameter to the corresponding URI before requesting it. The
receiving entity shall not request the HTTPS URI without user consent.
When and how the user consent is obtained is not part of this
specification. The Request must use the HTTP verbs GET or POST, other
verbs are not permitted as especially the HEAD request should never be used
in cases where a state change is triggered. PUT and DELETE would offer
similar functionality but are often not implemented correctly or are not
implemented at all.
The requester should not follow redirects and should interpret all 3xx HTTP
status codes as a success signal.
5.3 Additional Requirements
The email needs at least one valid authentication identifier, in this
version of the specification the only supported identifier type is
DKIM [RFC7489], that provides a domain-level identifier in the
content of the "d=" tag of a validated DKIM-Signature header field.
The corresponding header needs to be included in the "h=" tag of a
valid DKIM-Signature header field.
The domain used in the HTTPS URI shall align to the domain used in the
RFC5322.From field or to the domain in the "d=" tag of the valid
DKIM-Signature header field in which the header is listed in the
"h=" tag.
6. Examples
6.1 Simple
This example signals "One-Click" functionality for the
List-Unsubscribe Header.
List-Unsubscribe: <https://example.com/unsubscribe.html#List-
Unsubscribe=One-Click>
A mailbox provider shall request that HTTPS URI in this form:
https://example.com/unsubscribe.html?List-Unsubscribe=One-Click
6.2 Extended
This link already has parameters.
List-Unsubscribe:
<https://example.com/unsubscribe.html?campaign=123456789#List-
Unsubscribe=One-Click>
A mailbox provider shall request that HTTPS URI in this form:
https://example.com/unsubscribe.html?campaign=123456789&List-
Unsubscribe=One-Click
7. Security Considerations
This document does not introduce new protocol artifacts with security
considerations.
8. Acknowledgements
...
_______________________________________________
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
