This is my analysis of what is possible, based on research that I have been pursuing on this subject for the last few months.
Doug Foster -- 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 is 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. x.1 SPF Authentication with indirect Mail Flows SPF examines the information submitted upon initiation of an unauthenticated SMTP connection by an adjacent server, and therefore the adjacent server is fully responsible for those values. SPF is designed for the situation where a message is submitted directly from the originating organization to the final recipient organization, and the SPF record confirms that the source IP address is an authorized message origination server for that specific domain. When mail flows indirectly, with one or more organizations handling the message between the originating organization and the final recipient organization, SPF reports on the wrong evidence. SPF cannot indicate whether the originating server was an authorized server, exactly because the adjacent server was not the message originator. To confirm that the originating server was authorized, the SPF test must be performed using the parameters that were in place when the message crossed the boundary between the originating organization and the first intermediary organization. Applying this test becomes difficult because of incomplete information, inconsistent information, incorrect information, and the possibility of maliciously incorrect information. To begin the analysis, assume that Received header fields can be successfully parsed and that the data is not maliciously incorrect. x.1.1 Determining the originating organization for SPF The goal of this process is to walk backward through the Received chain to find the first organization to handle the message, after excluding client connections. A detectable organization boundary occurs when the source IP in a Received field is a global IP and the HELO server organization is different from the Received By organization. A locally-tailored copy of the Public Suffix List is recommended for determining whether servers are in the same or different organizations. HELO names can be verified using forward-confirmed DNS, or by a forward-confirmed Reverse-DNS name when both server names are in the same organization. Unverifiable server names will tend to increase the number of perceived organization boundaries within the Received chain. The initial connection between a submitting agent and its mail store may not be documented in the message header as a Received field. If a Received field is present, its role as a client connection should be evidenced by the protocol portion of the Received field, which should either indicate one of the several codes for Authenticated SMTP, or one of the non-SMTP protocols that are used for client connections. If an organization includes trace data for a client connection, without indicating an authentication protocol, evaluators may be misled, causing them to treat the message as unauthenticated and therefore unauthorized. x.1.2 Determining the prior Mail From address for SPF The RFC5321.MailFrom address may change during transit, so the goal of this process is to estimate the value of that address when it exited the originating organization. Prior values for the MailFrom domain can be obtained from these sources, when present: · Some Received fields contain a comment structure of the form “(envelope-from <user@domain>)”. · Some Received fields indicate the current recipient using a “FOR user@domain” clause. If the indicated recipient domain is different from the final RFC5321.MailFrom domain, then the prior recipient was probably used for forwarding, and may have become the new MailFrom address. · Received-SPF, Authentication-Results, or ARC-Authentication-Results fields may contain SPF results that include both MailFrom information and a source IP address. · If the SPF result does not include an IP address, the source IP may be available if the same field includes an IPREV result which includes a source IP address. · In some cases, a MailFrom address will have a local-part encoded in SRS format, and the prior recipient address or addresses can be extracted by reversing the SRS encoding. Note that the reported SPF result is of limited importance to this evaluation. The reported SPF result sill be uninteresting if it is not based on the originating organization exit point, and it should be recomputed by the evaluator after the origination point has been determined. When any of the three authentication results fields contain SPF information, the supplied data should be matched to a Received field to check for internal consistency, and to associate the result with a physical position in the message flow. In many cases, the authentication result will allow a MailFrom address to be assigned to a Received field that does not have an envelope-from comment. When authentication results cannot be matched to a Received field, the result should be ignored. If a single Received header is reported as having multiple different values for the MailFrom domain, evaluators are recommended to send the message to quarantine to investigate the inconsistency. While determining the originating organization and MailFrom domain, the evaluator may detect an identifier which has been previously blocked as unacceptable. When an unacceptable identifier is detected, the message is blocked and further analysis for Sender Authentication purposes becomes unnecessary. The process of searching for the originating organization will prevent known-malicious actors from hiding behind a legitimate forwarder. x.1.3 Interpreting the results by evaluating the Received chain to determine prior SPF result · If the Recipient domain changes without a detected change in the Mail From domain, the message appears to have been auto-forwarded, without SPF rewrite, by the previous Recipient account. The forwarding action occurred between the last appearance of the previous Recipient and the first appearance of the subsequent Recipient. · If a previous Recipient domain becomes a subsequent MailFrom domain, then the message appears to have been forwarded, with SPF rewrite, by the previous Recipient account. The forwarding action occurred between the last appearance of the previous Recipient account and the first appearance of that same domain within a MailFrom address. · If the MailFrom domain changes, the message appears to have been forwarded, with SPF rewrite, by the previous MailFrom account. The forwarding action occurred between the last appearance of the previous MailFrom account and the first appearance of the subsequent MailFrom account. · If any forwarding occurred, the originating RFC5321.MailFrom domain may have been the received RFC5322.From domain. Upon completion of this data collection, the originating Mail From domain may be uncertain, but should be constrained to no more than two values. All candidate MailFrom domains can be tested against the IP address used to exit the originating server. If none pass, the SPF result is not Pass. If one of the addresses produce SPF Pass, the originating server is considered authenticated and the MailFrom address tested is assumed to be the one used at origination. If the originating organization exit point is also in doubt, the SPF test can be repeated on multiple Received headers, but the trustworthiness of a PASS results becomes increasingly weaker as the amount of guesswork increases. x.2 DKIM authentication with Indirect Mail RFC6376 directs that unverifiable DKIM signatures should be treated as non-existent. In practice, this is not optimal. An unverified signature can only occur because of one of these causes: · The signature was legitimate and verifiable at creation, but the message was subsequently changed in a manner that broke the signature. · The signature was legitimate but created incorrectly (missing or unusable DNS entry, incorrect hash calculation.) · The message was illegitimately created in an attempt to deceive downstream evaluators. While the evaluator may have difficulty distinguishing between these possibilities, an evaluator may be able to draw a conclusion after additional research: · If research determines that the signature was applied legitimately, then future messages with the same mail flow and broken signature can be handled as if the signature was verified. · If research determines that the signature was applied illegitimately, and the responsible identifier can be determined, then the identifier can be blocked. x.2.1 Determining whether to treat a failed signature as previously-valid The following data is available to assist with evaluating prior DKIM signature state: · The position of a DKIM signature within the trace fields is a possible indication of when the message was created. This provides the signature with both the purported signing domain, from the signature, and the corresponding server organization, indicated by the next organizational boundary. · ARC-Authentication-Results and Authentication-Results fields may contain information about the prior state of a DKIM signature. If the result record can be associated with a Received header, then the evaluator knows that the signature was created within the exiting organization or earlier. If the evaluator chooses to trust the entity indicated by the Authentication-Results label or the ARC set signing domain, then it also trusts that the signature had that reported status when the result field was created. · Industry norms are to retain DKIM signatures in the message header, whether verifiable or not. If an ARC-Authentication-Results or Authentication-Results field indicates a domain signature that does not exist in the received message, then the result data is untrustworthy and should be ignored. Similarly, if a signature’s position in the Trace fields is inconsistent with the position of the ARC-Authentication-Results or Authentication-Results field, then the result data should be ignored. Of course, DKIM signatures may be appended to the message rather than being inserted into the Trace fields, rendering positional analysis risky. x.2.2 Interpreting prior DKIM status for Sender Authentication When the message flow is indirect, the evaluator is interested in verifying that the signature was applied to an authenticated message. This allows for two possibilities: · The signature was applied within the originating organization, or · The signature was applied by an outbound filtering organization that authenticated the message when it was received from the originating organization. Since a DKIM signature did not exist for this purpose, the known authentication techniques are “Smart Host” server-to-server login, trusted IP using a tailored IP list, or trusted IP based on SPF. When positional analysis indicates that a signature was applied outside the originating organization, evaluators may have great difficulty verifying that the handoff from the originator was legitimate. Sources of confirmation include: · Validating the originating organization based on forward-confirmed DNS host name. · SPF lookup by the evaluator, using the IP and Mail From values attribute to the organization exit point. · Checking authentication results fields to detect SPF Pass or Auth Pass, if the source of the authentication results field is considered trustworthy. · Private knowledge of the business practices of the outbound filtering service. Evaluators that use an outbound filtering service may not consider that their SPF record should include the boundary between originating servers and outbound filtering services. As a result, evaluators can expect false positives when trying to evaluate SPF behind an outbound filtering service.
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
