| Internet-Draft | Email Agreement | January 2023 |
| Vesely (ed) | Expires 9 July 2023 | [Page] |
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.¶
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 (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.¶
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.¶
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.¶
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:¶
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...¶
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.¶
TBD.¶
TBD.¶