Network Working Group A. Vesely (ed) Internet-Draft 5 January 2023 Intended status: Experimental Expires: 9 July 2023 Mailing List Manager (MLM) Transformations draft-vesely-email-agreement-00 Abstract This draft proposes a way to standardize an agreement between a recipient and a sender, acknowledged by the recipient's MTA. The subject of the agreement expresses the willingness of the recipient to receive an identified, authenticated mail stream. After an MTA acknowledges the agreement, it will unconditionally accept complying messages, even if the recipient is not mentioned in any destination address field. 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 9 July 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Vesely (ed) Expires 9 July 2023 [Page 1] Internet-Draft Email Agreement January 2023 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Mailing Lists . . . . . . . . . . . . . . . . . . . . . . . . 2 3. BCC to self . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. BCC to friend or colleague . . . . . . . . . . . . . . . . . 3 5. Newsletters and Email Marketing . . . . . . . . . . . . . . . 3 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 3 6.1. Normative References . . . . . . . . . . . . . . . . . . 3 6.2. Informative References . . . . . . . . . . . . . . . . . 4 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction The Simlple Mail Transmission Protocol (SMTP) ([RFC5321]) provides for sending messages to whomever world-wide, without prior arrangements. However, when email is forwarded to a different email address, there must have been a specific setup whereby the target address gets written somewhere on the sending machine. For example, we consider mailing lists, where there is some kind of opt-in; BCC, used either to save sent messages on the server or to let a friend or collegue know; newsletters following some gathering of signatures, appeal, or similar activity. Most forwarding activities are formalized on the sender side only. In some cases, they are formalized at the receiving MTA in order to deliver the corresponding messages to specific folders. In order to get rid of abusive forwarding, we just need to standardize the formalizations which are agreed by the recipient. 2. Mailing Lists Confirmed Opt-In is a widespread method to formalize mailing list subscription. Usually, a user fills in a web form with her or his email address. The mailing list manager (MLM) sends an invitation containing a unique token to that address. If the subscriber replies within a given amount of time, via either web or email, thereby proving her or his email address ownership, the subscription is complete. Vesely (ed) Expires 9 July 2023 [Page 2] Internet-Draft Email Agreement January 2023 We propose to extend that method so as to involve the receiving MTA. To support its involvment, an MTA publishes an apposite policy in a well-known URI [RFC5785] on a purposedly defined host. The policy contains the email address of a robot that will send invitations to a given user on MLM request. The MTA invitation, besides confirmation, can deal with delivery details such as the target folder. Upon user confirmation, that MTA itself confirms the subscription to the MLM. The MTA stores the data supplied by the MLM: * The user's subscribed email address or alias, * the List-Id ([RFC2919]), * the signing domain Afterward, the MTA will unconditionally accept, until user revocation, all messages destined to the supplied email address only -that is, no multiple RCPTs in the envelope- provided that a matching List-Id field appears in the h= tag of a verified signature, either DKIM-Signature or ARC-Message-Signature, having the given siging domain as d=. TBC... 3. BCC to self This setting is internal to each mail site. The user has to authenticate before sending a message ([RFC6409]), so all a site has to do is to establish an extension, e.g. user+sent, so that the user can set her MUA appropriately. 4. BCC to friend or colleague TBD. 5. Newsletters and Email Marketing TBD. 6. References 6.1. Normative References [RFC2119] Bradner, S. and RFC Publisher, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Vesely (ed) Expires 9 July 2023 [Page 3] Internet-Draft Email Agreement January 2023 [RFC2919] Chandhok, R., Wenger, G., and RFC Publisher, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, DOI 10.17487/RFC2919, March 2001, . [RFC5785] Nottingham, M., Hammer-Lahav, E., and RFC Publisher, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, . 6.2. Informative References [RFC5321] Klensin, J. and RFC Publisher, "Simple Mail Transfer Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008, . [RFC6409] Gellens, R., Klensin, J., and RFC Publisher, "Message Submission for Mail", STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, . Appendix A. Examples Author's Address Alessandro Vesely v. L. Anelli 13 20122 Milano MI Italy Email: vesely@tana.it Vesely (ed) Expires 9 July 2023 [Page 4]