Opened 2 years ago

Last modified 22 months ago

#94 assigned enhancement

Add message identifiers to ARC set (Helo, SMTP, From, Prior IP)

Reported by: dougfoster.emailstandards@… 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

This is an alternative to ticket #79, and probably preferable as it is based on ARC rather than creating a new message header.

A-R (and Received-SPF) are assumed to be produced and created within a single ADMD, with full trust between the producer and the consumer.

  • There is no need for address rewriting, so the producer does not need to document identity information for the consumer, because the consumer has that information automatically.
  • Because of trust, the consumer has no need to re-verify the reported information, and part of the purpose of the A-R header is to avoid the expense of re-verification.
  • The internal path from network perimeter to A-R producer to A-R consumer is part of organizational knowledge, and this knowledge can be applied as needed when implementing policies based on the A-R data.

When A-R became ARC, these assumptions no longer apply. ARC is particularly intended for use with indirect messages, where the message source IP is hidden behind the forwarder IP, the SMTP address is frequently rewritten, and the From address is sometimes rewritten. In the general case, the network path between the forwarder, the ARC producers, and the ARC evaluator will not be known in advance. Instead, the Received header chain will be the primary source of network path data.

This situation creates some distinct requirements for ARC which are not addressed by the current ARC specification.

  • Verification results are only useful if the identity involved is known. The ARC SPF result format is similar to the Received-SPF header specification, where the identifiers are in comment text if supplied, may or may not be commented in a predictable format, and may not be supplied at all.
  • To correctly assess reputation, a full identity is needed, including server, SMTP address, and From address. ARC currently provides identity information only if a test is performed to evaluate a particular identity. Even when results are reported, the identity examined may be truncated to only a domain name. If DMARC is not evaluated, the current state of the From address is not documented. ARC sets have been observed where all DKIM signatures are evaluated, but DMARC results are not reported, so the relevance of the DKIM signatures remains ambiguous.
  • ARC provides no information about the server which performed the evaluation, which leaves the identity tuple fractured. The server chain is documented in the Received headers while the identities are partially documented in the ARC Set. Any manual inspection of message headers will demonstrate that the proper interpretation of an ARC set is closely tied to its position in the Received header chain. ARC Sets need to be integrated with the Received header chain.

Proposal:

These attribute pairs should be added to the ARC specification as required data:

  • SMTP-Address: <email address>;
  • From-Address: <email address>;
  • Server-Helo: <DNS name>

This attribute pair should be added to the ARC specification as a recommended element:

  • Prior-Server-IP: <IP address>

Because some processing flows touch the same server multiple times, IP and HELO together provide the best way to match an ARC set to a received header set. In messages with multiple ARC sets, the signed ARC sequence will serve to validate the unsigned Received header sequence.

Change History (2)

comment:1 Changed 22 months ago by todd.herr@…

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

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

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