Authenticated Received Chain

Authenticated Received Chain (ARC) is an email authentication system designed to allow an intermediate mail server like a mailing list or forwarding service to sign an email's original authentication results. This allows a receiving service to validate an email when the email's SPF and DKIM records are rendered invalid by an intermediate server's processing.[1]

ARC is currently a draft standard with the IETF.[2]

Overview

DMARC allows a sender's domain to indicate that their emails are protected by SPF and/or DKIM, and tells a receiving service what to do if neither of those authentication methods passes - such as to reject the message. However, a strict DMARC policy may block legitimate emails sent through a mailing list or forwarder, as the SPF check will fail due to the unapproved sender and the DKIM signature will be invalidated if the message is modified, such as by adding a subject tag or footer.

ARC helps to solve the problem of the SPF and DKIM signatures being invalidated by giving the intermediate server a way to sign the original message's validation results. Even if the SPF and DKIM validation fail, the receiving service can choose to validate the ARC. If the ARC indicates that the original message passed the SPF and DKIM checks and the only modifications were made by intermediaries trusted by that receiving service, the receiving service may choose to ignore the failed SPF, DKIM, or DMARC validation and accept the email anyway. It's up to each receiving service to decide which intermediaries to trust.

Implementation

ARC defines three new mail headers:

  • ARC-Authentication-Results (abbreviated AAR) - A combination of an instance number (i) and the results of the SPF, DKIM, and DMARC validation
  • ARC-Seal (abbreviated AS) - A combination of an instance number (i), a DKIM-like signature of the previous ARC-Seal headers, and the validity of the prior ARC entries.
  • ARC-Message-Signature (abbreviated AMS) - A combination of an instance number (i) and a DKIM-like signature of the entire message except for the ARC-Seal headers

To sign a modification, an intermediate server performs the following steps:

  • Copies the "Authentication-Results" field into a new AAR field (starting with i=1) and prepends it to the message.
  • Calculates the AMS for the message (with the AAR) and prepends it to the message.
  • Calculates the AS for the previous Arc-Seal headers and prepends it to the message.

To validate an ARC, the recipient performs the following steps:

  • Validates the chain of ARC-Seal headers (no missing entries, all ARC-Seal messages state that the prior ARC entries are valid, etc.)
  • Validates the newest ARC-Message-Signature (based on the instance number)

See also

References

  1. ↑ "Authenticated Received Chain Overview" (PDF). Retrieved 2017-06-15.
  2. ↑ "Authenticated Received Chain (ARC) Protocol draft-ietf-dmarc-arc-protocol-03". Retrieved 2017-06-15.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.