I am much discouraged by the recent discussion about false DMARC PASS based on false SPF PASS or malicious mDKIM replay. When combined with the discussion about false DMARC FAIL for mailing lists, it seems like we have a very unimpressive standards proposal.
We have proposed defending against false SPF PASS by providing a DMARC option for “DKIM-only”. This will provide a solution to the domain owner’s problem, at least for those evaluators who understand and enforce the DKIM-only parameter. But it does not come close to solving the Evaluator’s problem, because the Evaluator is at risk of deception from impersonation of any hosting service’s client domain. Consider the close similarity between these two scenarios: Legitimate Client via Legitimate Domain · MailFrom = user@GoodDomain, From=user@GoodDomain, Rcpt To=user@TargetDomain · Received #1: From clientdevce.tld by inbound.hostingservice.tld with SMTP (Authenticated) · (Normal routing) · MailFrom = user@GoodDomain, Rcpt To=user@TargetDomain · Received #2: From outbound.hostingservice.tld by inbound.TargetDomain with SMTP (Unauthenticated) · Result: SPF PASS and DKIM PASS based on SPF Strict Alignment Attacking client via Co-Conspirator domain · MailFrom = user@GoodDomain, From=user@GoodDomain, Rcpt To=user@ConspiratorDomain · Received #1: From maliciousserver by inbound.hostingservice.tld with SMTP (Unauthenticated0 · (SPF Failure intentionally ignored. Forwarding without any change to MailFrom) · MailFrom = user@GoodDomain, Rcpt To=user@TargetDomain · Received #2: From outbound.hostingservice.tld by inbound.TargetDomain with SMTP (unauthenticated) · Result: SPF PASS and DKIM PASS based on SPF Strict Alignment Note that these two scenarios are nearly identical to the evaluator at TargetDomain. To distinguish between the two scenarios, the evaluator needs to reliably know either: · that the legitimate client used authenticated SMTP, which seems infeasible, or · that the Rcpt To address was altered in transit. Authentication result headers are only useful if the Evaluator knows that the results apply to an unauthenticated connection, which in these examples is uncertain in respect to the Received #1 header. Additionally, authentication result headers do not document the SMTP Rcpt To address. We have only one tool for downstream communication of the Rcpt To address: the “For” clause of the Received header. Some servers also document the current value of the Mail From address by including a Received comment of (envelope-from <emailaddress>). Our solution needs to take advantage of this capability. If hosting services will add these clauses to inbound and outbound Received headers, downstream evaluators could parse the headers to distinguish between the malicious message and the legitimate one. Even better, the hosting service itself could use the inbound and outbound Mail >From data to detect the malicious impersonation and block the message. The Received header information will have added credibility if both inbound and outbound Received headers are included in a DKIM signature provided by the hosting service. One problem with the “For” clause is that it is only used for a single address. As a result, it is typically omitted if the message has multiple recipients. To work around this limitation, the following is proposed: · Inbound processing splits inbound traffic by domain, either by deferring Rcpt To address requests involving a secondary domain, or by splitting the message by domain after initial reception. · When a message has multiple recipients in a single domain, the For address is interpreted as a proxy for all destination addresses in a domain. This could be accomplished using the first address from the recipient list, using a placeholder for local-part such as “_null@RcptToDomain”, or omitting the local-part completely “@RcptToDomain”. I am not clear whether we create a layer violation by defining this enhancement to the Received header, since this proposal does not create an incompatibility. The Email Core WG seems intent on discussing the Received header in the future, but is not ready to do so at this moment. More importantly, Email Core seems adverse to considering anything involving authentication, so it seems to be our problem to solve. I don’t think we can be ready for publication unless the problem and its recommended solution are documented, Doug Foster
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
