Internet DRAFT - draft-vesely-email-agreement
draft-vesely-email-agreement
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,
<https://www.rfc-editor.org/info/rfc2119>.
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, <https://www.rfc-editor.org/info/rfc2919>.
[RFC5785] Nottingham, M., Hammer-Lahav, E., and RFC Publisher,
"Defining Well-Known Uniform Resource Identifiers (URIs)",
RFC 5785, DOI 10.17487/RFC5785, April 2010,
<https://www.rfc-editor.org/info/rfc5785>.
6.2. Informative References
[RFC5321] Klensin, J. and RFC Publisher, "Simple Mail Transfer
Protocol", RFC 5321, DOI 10.17487/RFC5321, October 2008,
<https://www.rfc-editor.org/info/rfc5321>.
[RFC6409] Gellens, R., Klensin, J., and RFC Publisher, "Message
Submission for Mail", STD 72, RFC 6409,
DOI 10.17487/RFC6409, November 2011,
<https://www.rfc-editor.org/info/rfc6409>.
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]
