You are asking the wrong question. DMARC does not attempt to solve the evaluator's problem with malicious impersonation. It only solves the sender's problem of protecting its brand image.
We know that DMARC produces false positives, and the subject earned its own RFC. Neither RFC7489 nor DMARCbis provide any guidance to the evaluator for handling false positives, so he has to develop a solution on his own. An evaluator that does not have a plan for handling false positives will be poorly served by implementing DMARC. We also expect that DMARC policies with p=reject cover less than 10% of all messages received by an evaluator. If an evaluator only blocks on Fail with p=reject, he can assume that somewhere around 90% of all malicious impersonation is being missed. If he blocks on Fail with p=none, he can reasonably assume an unacceptably high rate of false positives. An evaluator should consider neither outcome to be acceptable, When DMARC successfully detects and correctly blocks a malicious impersonation, it only blocks that one attack type. The evaluator is only protected until the attacker impersonates a domain without p=reject. An intelligent evaluator should use messages that are blocked by DMARC (or by content filtering) to detect and block the entity responsible for the attack. DMARC provides no guidance for doing that task either. In short, your scenario is not important to DMARC. A message with no FROM domain has no brand threatened, so the problem is out of scope, as Todd correctly indicated. A solution to the evaluator's problem will require authentication checking on all messages, investigation of all authentication failures, and an architecture for handling authentication failure on wanted messages. But this group never intended to design that solution. Doug Foster On Fri, Jan 31, 2025, 11:35 AM Damian Lukowski <rfc= [email protected]> wrote: > DMARCbis38 states > > DMARC operation is predicated on the input being a valid RFC5322 message > object. For non-compliant cases, handling is outside of the scope of this > specification. > > RFC5322.From can be valid and still have no author domain information. > RFC7489 section 6.6.1 at least stated > > Messages with an RFC5322.From field that contains no meaningful > domains, such as RFC 5322 [MAIL]'s "group" syntax, are typically > ignored. > > So, ignore instead of fail or pass. What should DMARCbis verifiers do? > > _______________________________________________ > dmarc mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
