Skip to main content

The Delivered-To Message Header Field
draft-duklev-deliveredto-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Viktor Dukhovni , John R. Levine
Last updated 2021-08-16
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-duklev-deliveredto-00
Network Working Group                                        V. Dukhovni
Internet-Draft                                              Bloomberg LP
Intended status: Informational                                 J. Levine
Expires: 17 February 2022                                  Standcore LLC
                                                          16 August 2021

                 The Delivered-To Message Header Field
                      draft-duklev-deliveredto-00

Abstract

   This document describes the existing usage of the Delivered-To header
   field in e-mail messages.

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 17 February 2022.

Copyright Notice

   Copyright (c) 2021 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.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Dukhovni & Levine       Expires 17 February 2022                [Page 1]
Internet-Draft                 deliveredto                   August 2021

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Header Syntax . . . . . . . . . . . . . . . . . . . . . . . .   2
     2.1.  Loop Breaking . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Related Headers . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   3
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   3
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   3
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Introduction

   The Delivered-To message header was introduced by the [qmail] mail
   package in 1998, and adopted shortly afterward by [Postfix] and
   [Courier].  Mail Delivery Agents (MDA) [RFC5598] use the header to
   detect and break delivery loops.

2.  Header Syntax

   The syntax of the Delivered-To header is similar to other mail
   message headers.  In the ABNF below, addr-spec is imported from
   [RFC5322].

   delivered-to = "Delivered-To:" addr-spec CRLF

   The contents of the header is an opaque string that is an MDA-
   specific representation of the mailbox to which a message was
   delivered.  The string need not be, and often is not, an address to
   which mail can be sent using SMTP.

   The domain part of the addr-spec is typically a mail domain managed
   by the MDA adding the header, so the header contents do not collide
   with headers created by other MDAs.

2.1.  Loop Breaking

   Some MDAs use the Delivered-To header to break delivery loops using
   the following method.

   When an MDA is about to deliver a message, it creates a Delivered-To
   header that represents the target of the delivery, and then scans the
   existing headers in the message to see if an identical Delivered-To
   header is already present.  If so, the message is in a loop, and the
   delivery fails.  If not, the MDA prepends the header to the message
   and proceeds with the delivery.

Dukhovni & Levine       Expires 17 February 2022                [Page 2]
Internet-Draft                 deliveredto                   August 2021

   Delivered-To headers are typically prepended to the message,
   similarly to the way trace headers are prepended, but the loop
   breaking algorithm does not depend on the order of the headers, only
   whether an identical header is already present.

3.  Related Headers

   Some MDAs add a different header that records the actual RCPT TO
   address in an SMTP or submission session that handled the message.
   This header is typically called Envelope-To or X-Original-To, but
   varies from one MDA to another.

4.  IANA Considerations

   IANA is requested to add the following entry to the Permanent Message
   Header Field Names registry:

    +==============+==========+==========+===============+===========+
    | Header Field | Template | Protocol | Status        | Reference |
    | Name         |          |          |               |           |
    +==============+==========+==========+===============+===========+
    | Delivered-To | (blank)  | mail     | informational | [this     |
    |              |          |          |               | document] |
    +--------------+----------+----------+---------------+-----------+

                                 Table 1

5.  Security Considerations

   Depending on the way that an MDA creates the Delivered-To header, it
   may be possible to guess internal details of the delivery process
   from the contents of the header.  To avoid this, some MDAs may
   obscure the Delivered-To contents by hashing or otherwise
   transforming the part of contents to the left of the @-sign to make
   it harder to reverse engineer.

   Malicious senders have occasionally sent messages with a Delivered-To
   header that deliberately matches the one to be added by an MDA, to
   provoke a bounce from that MDA to the envelope sender of the message,
   causing what is known as "blowback spam."  Mitigations are the same
   as for any undeliverable mail that may have a forged envelope sender
   address.

6.  Acknowledgments

   We thank Sam Varshavchik for his reviews and useful suggestions.

7.  Informative References

Dukhovni & Levine       Expires 17 February 2022                [Page 3]
Internet-Draft                 deliveredto                   August 2021

   [Courier]  Varshavchik, S., "Courier Mail Server", 2000,
              <https://courier-mta.org>.

   [Postfix]  Venema, W., "Postfix", 1999, <http://www.postfix.org>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC5598]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July 2009,
              <https://www.rfc-editor.org/info/rfc5598>.

   [qmail]    Bernstein, D.J., "qmail", 1998,
              <https://cr.yp.to/qmail.html>.

Authors' Addresses

   Viktor Dukhovni
   Bloomberg LP

   Email: ietf-dane@dukhovni.org

   John Levine
   Standcore LLC

   Email: standards@standcore.com

Dukhovni & Levine       Expires 17 February 2022                [Page 4]