Opened 2 years ago

Last modified 20 months ago

#79 assigned enhancement

Forwarding-Info header to correct for data loss during address rewrite and address mailing list problem.

Reported by: fosterd@… Owned by: todd.herr@…
Priority: major Milestone: Deliverable #2 (DMARC improvements to better support indirect email flows)
Component: dmarc-bis Version:
Severity: - Keywords:
Cc:

Description

When a message is sent directly, the receiving system can assume that all servers in the Received chain participate in one Administrative domain involving the source domain and its vendors. As a result, the prior entries in the Received chain do not need to be evaluated.

However, in the case of a forwarded message, multiple administrative domains are involved, and the receiving system should evaluate the trust characteristics of each administrative domain independently. This layered evaluation is not currently possible: the receiving system does not have a reliable method for detecting that a forwarding operation occurred, and the forwarding operation frequently discards identifiers needed to identify the prior administrative domain.

The appropriate solution for this dilemma is for a forwarding server to document that a forwarding operation is being performed, as well as logging those identifiers needed for the receiving system to evaluate the prior administrative domain.

Specifically, I propose a new header to be applied by a forwarding server:

Forwarding-Info:

SourceDomain?=<domain of destination address before the forwarding operation>;
Current-SMTPDomain=<domain of RFC5321 MailFrom? address at forwarding operation>;
Current-MessageDomain?=<domain of RFC5322 From address at forwarding operation>;
LookbackCount?=<number of prior servers in current administrative domain, default=0>

Forwarding-Info is a trace header, which should appear above the Received header created by the forwarding server. The "Current" entries capture the current state of these identifiers, so that the values are not lost completely if the RFC5321.MailFrom? address is rewritten for SPF policy compliance or the RFC5322.From address is rewritten for DMARC policy compliance. The Lookback count is an indicator of the number of prior servers in the forwarding administrative domain, to assist the receiving system in locating the Received entry which represents the boundary between the forwarding administrative domain and the previous administrative domain. When the number of inbound servers is variable, the minimum expected value should be used.

Multiple forwards are possible, so multiple Forwarding-Info headers are possible.

Special Cases

It is theoretically possible that a single message is received by a single server for delivery to two or more internal domains, and that these are then forwarded to a single recipient MX using another multiple-recipient message. In this case, the preferred behavior is to send separate messages with separate Forwarding-Info headers, but an acceptable alternative is to pick one of the forwarding domains to be used in the Forwarding-Info header. Since the purpose of the header is to facilitate identification of the forwarding point and evaluation of the prior administrative domain, the choice of SourceDomain? is not expected be of sufficient importance to use a multi-valued list.

Trust and Security Issues

There are four possible trust scenarios involving forwarding:

  • Trustworthy originator, trustworthy forwarder
  • Untrusted originator, trustworthy forwarder
  • Trustworthy originator, untrusted forwarder
  • Untrusted originator, untrusted forwarder.

The normal action of the receiving system should be evident: If the forwarder is untrusted, the message should be rejected and evaluation of the originator is irrelevant. If the forwarder is not untrusted, then forwarding information can be evaluated to determine if the originator is untrusted, which would also cause the message to be rejected or discarded.

If the receiving system accepts the message after evaluating both originator and forwarding domains, it is no worse off than if it had evaluated the message based on the forwarder characteristics alone. Consequently, even though the Forwarding-Info header is not independently verifiable, using the Forwarding-Info data will introduce no incremental risk to the receiving domain.

Forwarder Filtering Behavior

Forwarding servers have two plausible strategies for processing of incoming messages:

  • Minimize false negatives: Filter aggressively to minimize the possibility that a forwarded message will be unacceptable to the recipient domain. This assumes that some, and possibly many, desired messages will be blocked. This strategy ensures the forwarding domain will have a very positive reputation with recipients, based on messages transmitted. However, the loss of desired messages will be untenable in most contexts.
  • Minimize false positives: Filter minimally to discard the most malicious content, and forward the rest to be dispositioned by the recipient domain or recipient user. This ensures that all desired messages are delivered. However, without Forwarding-Info, unwanted messages will be attributed to the reputation of the forwarding server, which may hinder delivery of other messages, whether forwarded or not. This strategy is assumed to be the one used by most forwarders.

The Forwarding-Info header allows originating domains, rather than the forwarding domain, to bear responsibility for unacceptable messages which the forwarder allows through.

Recipient System Processing

This proposal assumes that recipient systems evaluate messages on three key characteristics:

  • The source server, as indicated by Source IP, Reverse DNS, and HELO/EHLO host name.
  • The source mail domain, as indicated by RFC5321.MailFrom? address.
  • The author domain, as indicated by the RFC5322.From header address.

This proposal provides a framework for the receiving system to intelligently evaluate all of the Received headers in the chain, with particular attention to those Received entries which represent possible boundaries between administrative domains.

At each such boundary, the server identities can be obtained from the Received record, and the source addresses can be obtained from Forwarding-Info headers. Whitelisting based on unverifiable Forwarding-Info data is not recommended, but the additional filtering of unwanted messages should improve the safety of the receiving system while enhancing the perceived reputation of the forwarding system.

Relationship to DMARC

A DKIM-validated signature supports a result of DMARC “pass”, which confirms that the message was actually authored by the RFC5322.From domain. However, since the receiving system may not have reputation information on that domain, the originating server and originating mail domain reputations must also be evaluated before deciding whether the message should be rejected or not. Address rewrite to support SPF and DMARC policy compliance causes information loss, and the purpose of this proposal is to prevent that data loss from being unrecoverable.

Relationship to ARC

ARC provides verifiable information, which works to support the goals of this proposal. When the Forwarding-Info data can be matched to an ARC set entry in a verified ARC chain, a portion of the Forwarding-Info can be considered validated as well.

Nonetheless, ARC is not a full replacement for this proposal, and this proposal is not intended as a replacement for ARC.

  • ARC only captures authentication information, which is based on sender characteristics. So it cannot document the name of the domain which performed a forwarding operation.
  • ARC is not intended to document the forwarding event directly, although forwarding might be inferred from a sophisticated analysis of adjacent ARC sets, when they are present.
  • ARC depends on a series of servers to participate in the ARC chain. Forwarding-Info requires only participation by the forwarding server. Forwarding-Info is used to evaluate the Received chain, which is reliably available on every message.
  • ARC is particularly designed to explain loss of DKIM signature validity due to mailing list edits. Forwarding-Info is designed to document forwarding operations, whether or not content edits have occurred.

Change History (5)

comment:1 Changed 22 months ago by dougfoster.emailstandards@…

  • Milestone set to Deliverable #2 (DMARC improvements to better support indirect email flows)

comment:2 Changed 21 months ago by todd.herr@…

  • Resolution set to out-of-scope
  • Status changed from new to closed

Possibly worth pursuing as a separate effort, but of out of scope for DMARCbis.

comment:3 Changed 21 months ago by todd.herr@…

  • Resolution out-of-scope deleted
  • Status changed from closed to new

comment:4 Changed 20 months ago by todd.herr@…

  • Owner set to todd.herr@…
  • Status changed from new to accepted

comment:5 Changed 20 months ago by todd.herr@…

  • Status changed from accepted to assigned
Note: See TracTickets for help on using tickets.