Adding a Wrong Recipient URL for Handling Misdirected Emails
draft-dweekly-wrong-recipient-05

Network Working Group                                          D. Weekly
Internet-Draft                                          17 February 2024
Intended status: Standards Track                                        
Expires: 20 August 2024

      Adding a Wrong Recipient URL for Handling Misdirected Emails
                    draft-dweekly-wrong-recipient-05

Abstract

   This document describes a mechanism for an email recipient to
   indicate to a sender that they are not the intended recipient.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at
   https://dweekly.github.io/ietf-wrong-recipient/draft-dweekly-wrong-
   recipient.html.  Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-dweekly-wrong-recipient/.

   Source for this draft and an issue tracker can be found at
   https://github.com/dweekly/ietf-wrong-recipient.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 20 August 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Weekly                   Expires 20 August 2024                 [Page 1]
Internet-Draft               Wrong Recipient               February 2024

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Proposal  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   4.  High-Level Goals  . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Out of Scope  . . . . . . . . . . . . . . . . . . . . . . . .   4
   6.  Implementation  . . . . . . . . . . . . . . . . . . . . . . .   4
     6.1.  Mail Senders When Sending . . . . . . . . . . . . . . . .   4
     6.2.  Mail Recipients . . . . . . . . . . . . . . . . . . . . .   4
     6.3.  Mail Senders After Wrong Sender Notification  . . . . . .   5
   7.  Additional Requirements . . . . . . . . . . . . . . . . . . .   5
   8.  Header Syntax . . . . . . . . . . . . . . . . . . . . . . . .   5
   9.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     9.1.  Signed HTTPS URI  . . . . . . . . . . . . . . . . . . . .   6
     9.2.  UUID HTTPS URI  . . . . . . . . . . . . . . . . . . . . .   6
     9.3.  Combined mailto: and HTTPS URIs . . . . . . . . . . . . .   6
   10. Security Considerations . . . . . . . . . . . . . . . . . . .   7
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     12.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     12.2.  Informative References . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   9

1.  Introduction

   Many users with common names and/or short email addresses receive
   transactional emails from service providers intended for others.
   These emails can't be unsubscribed (as they are transactional) but
   neither are they spam.  These emails commonly are from a noreply@
   email address; there is no standards-based mechanism to report a
   "wrong recipient" to the sender.  Doing so is in the interest of all
   three involved parties: the inadvertent recipient (who does not want
   the email), the sender (who wants to be able to reach their customer
   and who does not want the liability of transmitting PII to a third
   party), and the intended recipient.

Weekly                   Expires 20 August 2024                 [Page 2]
Internet-Draft               Wrong Recipient               February 2024

   This document proposes a structured mechanism for the reporting of
   such misdirected email via either HTTPS POST or email inbox, directly
   mirroring the List-Unsubscribe and List-Unsubscribe-Post mechanisms
   of [RFC2369] and [RFC8058] respectively.

2.  Proposal

   There ought be a mechanism whereby a service can indicate it has an
   endpoint to indicate a "wrong recipient" of an email.  If this header
   field is present in an email message, the user can select an option
   to indicate that they are not the intended recipient.

   Similar to one-click unsubscription [RFC8058], the mail service can
   perform this action in the background as an HTTPS POST to the
   provided URL without requiring the user's further attention to the
   matter.  A mailto: URI may also be included for non-HTTP MUAs, akin
   to List-Unsubscribe from [RFC2369].

   Since it's possible the user may have a separate valid account with
   the sending service, it may be important that the sender be able to
   tie _which_ email was sent to the wrong recipient.  For this reason,
   the sender may also include an opaque blob in the header field to
   specify the account ID referenced in the email; this is included in
   the POST.

   Note that this kind of misdelivery shouldn't be possible if a service
   has previously verified the user's email address for the account.

3.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

4.  High-Level Goals

   Allow a recipient to stop receiving emails intended for someone else.

   Allow a service to discover when they have the wrong email for a
   user.

Weekly                   Expires 20 August 2024                 [Page 3]
Internet-Draft               Wrong Recipient               February 2024

5.  Out of Scope

   This document does not propose a mechanism for automatically
   discovering whether a given user is the correct recipient of an
   email, though it is possible to use some of the signals in an email,
   such as the intended recipient name, to infer a possible mismatch
   between actual and intended recipients.

6.  Implementation

6.1.  Mail Senders When Sending

   Mail Senders that wish to be notified when a misdelivery has occurred
   SHOULD include a Wrong-Recipient header field with an HTTPS URI to
   which the recipient's mail client can POST and/or a mailto: URI to
   which an email should be sent.  If this header field is included, the
   mail sender MUST ensure these endpoints are valid for a period of at
   least one year after sending.

   The sender MUST encode a mapping to the underlying account identifier
   in the URI in order to allow the service to know which of their
   accounts has an incorrect email.

   The URI SHOULD include an opaque identifier or another hard-to-forge
   component in addition to, or instead of, the plaintext recipient
   email address and user ID in order to prevent a malicious party from
   exercising the endpoint on a victim's behalf.  Possible examples
   include using a signature parameter to the URI or UUID with a sender-
   local database lookup to retrieve the email and user ID referenced.

6.2.  Mail Recipients

   When a mail client receives an email that includes a Wrong-Recipient
   header field, an option SHOULD be exposed in the user interface that
   allows a recipient to indicate that the mail was intended for another
   user, if and only if the email is reasonably assured to not be spam.

   If the user selects this option, the mail client MUST perform an
   HTTPS POST to the first https URI in the Wrong-Recipient header
   field, or send an empty message to the first referenced mailto:
   address.

   To minimize XSRF attacks, the POST request MUST NOT include cookies,
   HTTP authorization, or any other context information.  The "wrong
   recipient" reporting operation is logically unrelated to any previous
   web activity, and context information could inappropriately link the
   report to previous activity.

Weekly                   Expires 20 August 2024                 [Page 4]
Internet-Draft               Wrong Recipient               February 2024

   The POST body MUST include only "Wrong-Recipient=true".

   If the response is a HTTP 500 type error indicating server issue, the
   client MAY retry.  If the HTTP response to the POST is a 200, the
   client MUST NOT retry.  No feedback to the user as to the success or
   failure of this operation is proposed or required.

6.3.  Mail Senders After Wrong Sender Notification

   When a misdelivery has been indicated by a POST to the HTTPS URI or
   email to the given mailto: URI, the sender MUST make a reasonable
   effort to cease emails to the indicated email address for that user
   account.

   The POST endpoint MUST NOT issue an HTTP redirect and SHOULD return a
   200 OK status; the content body will be ignored.

   Any GET request to the same URI MUST NOT be treated as an indication
   of a wrong recipient notification, since anti-spam software may
   attempt a GET request to URIs mentioned in mail headers without
   receiving user consent.  Senders MAY return an error 405 Method Not
   Allowed in response to a GET request to the URI.  The sender MAY
   elect to present a page at this URI responsive to a GET request that
   presents the user with a form that allows them to submit the POST.

   The sender SHOULD make a best effort to attempt to discern a correct
   email address for the user account, such as by using a different
   known email address for that user, postal mail, text message, phone
   call, app push, or presenting a notification in the user interface of
   the service.  How the sender should accomplish this task is not part
   of this specification.

7.  Additional Requirements

   The email needs at least one valid authentication identifier.  In
   this version of the specification the only supported identifier type
   is DKIM [RFC6376], that provides a domain-level identifier in the
   content of the "d=" tag of a validated DKIM-Signature header field.

   The Wrong-Recipient header field needs to be included in the "h=" tag
   of a valid DKIM-Signature header field.

8.  Header Syntax

   The following ABNF imports fields and WSP from [RFC5322] and URI from
   [RFC3986].  An https URI, mailto URI, or one of each are permitted.
   Other URI protocols MUST NOT be used.

Weekly                   Expires 20 August 2024                 [Page 5]
Internet-Draft               Wrong Recipient               February 2024

   fields =/ wrong-recipient

   wrong-recipient = "Wrong-Recipient:" 0*1WSP "<" URI ">"
       *(0*1WSP "," 0*1WSP "<" URI ">") 0*WSP

9.  Examples

9.1.  Signed HTTPS URI

   Header in Email:

   Wrong-Recipient: <https://example.com/wrong-recipient?
       uid=12345&email=user@example.org&sig=a29c83d>

   Resulting POST request

POST /wrong-recipient?uid=12345&email=user@example.org&sig=a29c83d HTTP/1.1
Host: example.com
Content-Length: 20

Wrong-Recipient=true

9.2.  UUID HTTPS URI

   Header in Email:

   Wrong-Recipient: <https://example.com/wrong-recipient?
       uuid=c002bd9a-e015-468f-8621-9baf6fca12aa>

   Resulting POST request

POST /wrong-recipient?uuid=c002bd9a-e015-468f-8621-9baf6fca12aa HTTP/1.1
Host: example.com
Content-Length: 20

Wrong-Recipient=true

9.3.  Combined mailto: and HTTPS URIs

   Header in Email:

   Wrong-Recipient:
       <https://example.com/wrong-recipient?
           uuid=c002bd9a-e015-468f-8621-9baf6fca12aa>,
       <mailto:wrong-recipient.c002bd9a-e015-468f-8621-9baf6fca12aa
           @example.org>

Weekly                   Expires 20 August 2024                 [Page 6]
Internet-Draft               Wrong Recipient               February 2024

10.  Security Considerations

   The Wrong-Recipient header field may contain the recipient address,
   but that is already exposed in other header fields like To:.

   The user ID of the recipient with the sending service may be exposed
   by the Wrong-Recipient URI, which may not be desired but a sender can
   instead use an opaque blob to perform a mapping to a user ID on their
   end without leaking any information to outside parties, such as the
   UUID examples given above.

   A bad actor with access to the user's email could maliciously
   indicate the recipient was a Wrong Recipient with any services that
   used this protocol, causing mail delivery and potentially account
   access difficulties for the user.

   The Wrong-Sender POST provides a strong hint to the mailer that the
   address to which the message was sent was valid, and could in
   principle be used as a way to test whether an email address is valid.
   It also may expose the recipient's location and ISP via IP address.
   However, unlike passive methods like embedding tracking pixels, the
   mechanism proposed here takes an active user action.  Nonetheless,
   MUAs ought only expose this Wrong Recipient option if relatively
   confident that the email is not spam.

   A sender with a guessable URI structure and no use of either signed
   parameters or a UUID would open themselves up to a malicious party
   POST'ing email credentials for victims, potentially causing
   difficulty.  Senders should be strongly encouraged to use a signature
   or opaque blob as suggested.  No algorithm for creating such a
   signature or opaque blob is included in this standard since only the
   sender needs to validate the correctness of the hard-to-forge URL.

11.  IANA Considerations

   IANA has registered a new entry to the "Provisional Message Header
   Field Names" registry, to be made permanent if this proposal becomes
   a standard.

   Header field name: Wrong-Recipient
   Protocol: mail
   Status: Provisional
   Author/Change controller: IETF
   Specification document(s): *** This document ***
   Related information: none

12.  References

Weekly                   Expires 20 August 2024                 [Page 7]
Internet-Draft               Wrong Recipient               February 2024

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <https://www.rfc-editor.org/rfc/rfc3986>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/rfc/rfc5322>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

12.2.  Informative References

   [RFC2369]  Neufeld, G. and J. Baer, "The Use of URLs as Meta-Syntax
              for Core Mail List Commands and their Transport through
              Message Header Fields", RFC 2369, DOI 10.17487/RFC2369,
              July 1998, <https://www.rfc-editor.org/rfc/rfc2369>.

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/rfc/rfc6376>.

   [RFC8058]  Levine, J. and T. Herkula, "Signaling One-Click
              Functionality for List Email Headers", RFC 8058,
              DOI 10.17487/RFC8058, January 2017,
              <https://www.rfc-editor.org/rfc/rfc8058>.

Acknowledgments

   Many thanks to John Levine for helping shepherd this document as well
   as Oliver Deighton and Murray Kucherawy for their kind and actionable
   feedback on the language and first draft of the proposal.  Thanks to
   Eliot Lear for helping guide the draft to the right hands for review.
   A detailed review by Jim Fenton was much appreciated and caught a
   number of key issues.  Many thanks to the members of IETF ART for
   vigorous discussion thereof.

Weekly                   Expires 20 August 2024                 [Page 8]
Internet-Draft               Wrong Recipient               February 2024

Author's Address

   David Weekly
   Redwood City, CA
   United States of America
   Email: david@weekly.org

Weekly                   Expires 20 August 2024                 [Page 9]