I have multiple objections to this paragraph in section 5.7.2 "Heuristics applied in the absence of use by a Domain Owner of either SPF or DKIM (e.g., [Best-Guess-SPF <https://www.ietf.org/archive/id/draft-ietf-dmarc-dmarcbis-04.html#Best-Guess-SPF> ]) SHOULD NOT be used, as it may be the case that the Domain Owner wishes a Message Receiver not to consider the results of that underlying authentication protocol at all."
First, it is unnecessary. A sender who wants SPF ignored for purposes of DMARC can simply publish "?ALL" to produce the desired result. Second, I don't know why a sender would want this behavior. I understand that some senders have difficulty describing their environment within SPF complexity limits, but Google, Microsoft, and Amazon seem to have been able to cope with the constraint. Even when complexity is the problem, a partial list of clauses, terminated with "?ALL", would be preferable to no policy. My experience has been that SPF=NONE has a high probability of being unwanted mail. There is enough usage of SPF that serious participants are unlikely to use it. I have been using default SPF clauses for the last couple of years, with good results, so I need some serious convincing to backtrack. I think this text was inserted because of an open ticket when discussion was going nowhere and a new draft was created. Perhaps the originator of that ticket can elaborate on his thinking. Counter-proposal Another part of the draft observes that SPF policies can become too loose. For example, this could happen from range consolidation or nested includes, either of which might cause unauthorized servers to be included in the allowed list. If a sender knows that his SPF has this problem, and that all of his messages are DKIM-signed, he might want to publish a flag which says, "All my messages are signed. Any messages that are not DKIM-verified should be treated as DMARC FAIL, even if they pass SPF." I still doubt that we have a critical mass of domain owners who would use this option if it were available, and it seems like yet another avenue for false positives. But if such a capability is desired, it should be implemented as part of the DMARC policy statement, not as a general constraint on evaluators. Doug
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
