The discussion of indirect mail flows should cover both authentication upgrade and authentication downgrade. Below is my effort to address that need. Some of the text is repeated from my previous effort, but the how-it-can-be-done content has been purged.
Doug Foster x.1 DMARC with indirect Mail Flows The purpose of Sender Authentication is to confirm that the purported author of a message, as indicated by the RFC5322.From address, is the actual author. Sender Authentication assumes that an initial connection between the submitting agent and its mail store server was authenticated, so that the SMTP RFC5321.MailFrom address is known to be valid, and the RFC5322.From address is compliant with the security rules of that server. Thereafter, downstream servers only need to assess whether the originating mail store server acted appropriately. Consequently, SPF, DKIM, and DMARC are only concerned with domain validation, not user account validation. DMARC considers both SPF and DMARC results based on the HELO data and signature state when the message is received by the recipient organization. Despite this, the actual evaluation goal is to test the authentication state of the message at origination. When mail flows directly, the origination state and the final state of the message are the same, and DMARC works perfectly. When mail flows indirectly, credentials may be gained or lost, causing the DMARC result to be inconsistent with the DMARC result that would have been received if the test had been performed earlier in the mail flow. Intermediate organizations can be categorized by their role: Outbound gateway organizations function as an extension of the originating domain, while forwarding organizations function as a gateway to the receiving organization. Outbound gateway organizations can cause credential upgrade. Forwarding organizations usually cause credential downgrade. x.1.2 Credential upgrade caused by Outbound Gateways Outbound gateways typically increase the perceived message authentication state. This can occur: · Because the outbound gateway organization is included in the Mail >From domain’s SPF records, or · Because the outbound gateway organization is configured to add a DKIM signature for the client organization. If the outbound gateway organization can be deceived into accepting impersonation messages, then the fraudulent message will appear fully authenticated when processed through the gateway organization and received by the recipient organization. The possibility of credential upgrade is a risk to the recipient organization. Outbound gateway organizations should prevent credential upgrade by authenticating the source of incoming messages, to ensure that they are legitimately from the stated client organization. The tools available for this purpose include: · Server-to-server authentication using login credentials. This is sometimes called “Smart Host relay”. · Communication over a private IP address, possibly using a VPN tunnel. · Trusted IP address, either defined and published publicly as an SPF policy, or using a more restrictive list known only to sender and receiver organizations. Evaluators can hedge the risk of credential upgrade by examining the message header, or by determining the operating controls of specific Outbound Gateway organizations. When the gateway organization is trusted to authenticate all incoming messages, the downstream evaluator does not need to examine the message body for evidence of authentication. When operating practices are unknown, the evidence must be obtained from the message header itself. Outbound Gateway Organizations should ensure that the evidence is present. Authentication using login credentials should be documented using the protocol data in the Received header field and using an ARC Set with an AUTH=PASS term in the ARC-Authentication-Results header field. Authentication using trusted IP should be verifiable by SPF, when applied to the IP address in the Received field which documents handoff from client organization to Outbound Gateway organization. For similar reasons, DKIM signatures should be applied by the originating organization and placed in the Trace fields. A DKIM signature added by the Outbound Gateway organization has a lower trust value because it does not prove that the handoff between client and gateway organizations was authenticated. Other scenarios are possible. An outbound gateway may make changes, intentionally or accidentally, that invalidate prior signatures and the ARC chain. Outbound Gateways should take care to avoid this mistake. x.1.2 Credential downgrade caused by Forwarding Organizations Forwarding always causes loss of SPF authentication for purposes of DMARC. If the MailFrom address is not modified, forwarding causes the SPF test to change away from Pass. If the MailFrom address is rewritten to match the forwarding domain, then the SPF result will be Pass, but alignment with the From domain will be lost. Forwarding may also involve intentional or accidental content changes that invalidate DKIM signatures. When this occurs, messages lose DKIM authentication as well. Forwarding falls into two main groups: · Simple forwarders transmit a general mail stream to a single alternate recipient. DKIM signatures are usually preserved, but not all messages will have DKIM signatures. As a result, a significant portion of the received mail stream will appear to be unauthenticated. · Mailing lists transmit accepted message to a list of subscribers. The list typically adds content to the message subject, message body, or both. Since it is a forwarder, SPF authentication is lost. Because it changes the signed content, DKIM authentication is also lost. Consequently, content-altering mailing list messages appear to lack any authentication. A savvy evaluator will be able to detect both types of forwarders, because they will these characteristics: · The forwarding organization transmits messages for many different >From domains · The forwarding organization is not the message originator for that diversity of domain messages, as evidence by the Received chain. This distinguishes forwarding organizations from Email Service Providers. · The forwarding organization has a high percentage of messages that fail DMARC. Having identified a forwarder, an evaluator must determine the forwarder reputation. The evaluator has no obligation to accept forwarded messages, so the forwarder must have an acceptable reputation as a message source and must also be acceptable as a source of forwarded messages. If the forwarder passes the first hurdle, then the evaluator must adapt local policies to adjust for the acceptable forward. If the forwarder’s operating practices are known, and more specifically, if the forwarder is known and trusted to authenticate all incoming messages, then the downstream evaluator does not need to repeat the evaluation. In the more common situation, the forwarder is assumed to have imperfect authentication of incoming messages, so the evaluator computes a DMARC result based on the SPF state before forwarding and DKIM state before forwarding. This effort can use ARC Set data when present, or other header fields when ARC data is not present. To promote favorable consideration, forwarders should apply an ARC set to forwarded messages.
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
