v. L. Anelli 13 20122 Milano MI Italy vesely@tana.it

DKIM Mailing List Replay attack ARC 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.

Introduction The Simlple Mail Transmission Protocol (SMTP) () 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.

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. 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 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 (),
• 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...

BCC to self This setting is internal to each mail site. The user has to authenticate before sending a message (), 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.

BCC to friend or colleague TBD.

Newsletters and Email Marketing TBD.

References Normative References Informative References

Examples