On December 4, 2021 10:35:17 PM UTC, Douglas Foster
<[email protected]> wrote:
>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.
The alternative is not needed either. If operational advice is needed, then it
should be in an appendix or perhaps another document. It shouldn't be part of
the protocol specification. It's not particularly good advice either.
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
