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

[ietf-svn-bot]

owner:[email protected] type_enhancement | by [email protected]

---

This is an alternative to ticket ietf-wg-dmarc/draft-ietf-dmarc-dmarcbis#74, 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: ;
• From-Address: ;
• Server-Helo:
This attribute pair should be added to the ARC specification as a recommended element:
• Prior-Server-IP:

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.

---

Issue migrated from trac:94 at 2022-01-24 16:52:48 +0000

[ietf-svn-bot]

@[email protected] changed status from new to accepted

[ietf-svn-bot]

@[email protected] set owner to [email protected]

[ietf-svn-bot]

@[email protected] changed status from accepted to assigned

[toddherr]

ARC (RFC 8617) is not mentioned in DMARCbis, so it seems this ticket belongs elsewhere?