Email extension for specifying the next hop path for delivery
draft-gondwana-email-mailpath-01
Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Author | Bron Gondwana | ||
Last updated | 2023-04-12 (Latest revision 2022-10-10) | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Much work has been put into adding authentication methods (DKIM, ARC), source verification (SPF) and policy support (DMARC) to email flows, however all these specifications have focused on looking backwards through email flow only, and only add new headers to messages, causing them all to be susceptible to replay or re-use. In particular, in early 2022, a type of attack called "DKIM Replay" was widely seen, where correctly DKIM-signed messages were sent to a different envelope sender. The "To" address would not be aligned, but such messages can also be the result of legitimate mailflow, so these messages were delivered to end-recipient mailboxes, and caused reputation issues for the signers of the original message.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)