On August 5, 2022 2:23:38 AM UTC, "Murray S. Kucherawy" <[email protected]>
wrote:
>On Thu, Aug 4, 2022 at 7:04 PM Douglas Foster <
>[email protected]> wrote:
>
>> Sorry, Barry. I should have included the problematic text. here it is:
>>
>> 4.7. DMARC Policy Discovery
>>
>>
>> If the set produced by the DNS Tree Walk contains no DMARC policy
>> record (i.e., any indication that there is no such record as opposed
>> to a transient DNS error), Mail Receivers MUST NOT apply the DMARC
>> mechanism to the message.
>>
>>
>> The purpose of DMARC is (or should be) to help evaluators make better
>> disposition decisions, because when they do, senders of wanted messages
>> will benefit from improved delivery as a result of the improved decision
>> making,
>>
>> DMARC uses available information to produce a result of "Authenticated" or
>> "Not Authenticated". Sometimes, the message can be reliably categorized
>> as "Authenticated" or "Not Authenticated" without reference to the
>> specifics of a domain owner policy. "Authenticated" is certain if the
>> RFC5322.From address matches the domain which generated SPF PASS domain or
>> a domain which generated DKIM PASS. Conversely "Not Authenticated" is
>> certain if no domains match at the right-most two labels.
>>
>> But this language says that the evaluator must not consider results
>> certain, even if DMARC's logic clearly indicates that they are certain,
>> when the policy is missing. If "Authenticated" and "Not Authenticated"
>> are not allowed, then the result becomes "Unknown." This design is asking
>> the evaluator to do something which defies common sense and defies his own
>> self-interest. If an illogical design causes an evaluator to make
>> sub-optimal disposition decisions, then it hurts the domain owner also.
>>
>> Does this clarify the issue?
>>
>
>There's a thing that was proposed some time ago called "Best Guess SPF",
>wherein a receiver would apply a default SPF policy if none was found in
>the DNS. I think the policy was a simple "a mx" or something close to
>that. It had the flavor of "I'm going to assume this is what you meant,
>since you didn't actually say anything else", and on that basis was
>discouraged because it could result in false bounces under the SPF
>moniker. This has a similar feel.
SPF Best Guess never appeared in any IETF documents, not even drafts. It was
something used pre-IETF to help bootstrap SPF usage. It wouldn't have been
appropriate for standardization even if it was reasonably accurate (which I
don't think it was, although there's at least one major email provider that was
still using it last time I checked - a few years ago, but relatively recently
relative to its origin in 2003). The biggest issue was that it made
participation in SPF involuntary for senders.
I agree this has a similar feel and should be avoided for similar reasons.
Just because a domain does SPF or DKIM, it is not reasonable to assume that
they have any interest in DMARC.
>In this case I think you're arguing that if something has a positive signal
>from one of the supported authentication methods and the resulting
>identifier falls within strict alignment, we should consider that a "pass"
>irrespective of what policy may or may not have been published (and, in
>fact, there's no need to go look). That's certainly a change since RFC
>7489 and would have to be explained. It does save the verifier some
>redundant DNS work though.
I think It would be a substantial design regression to go down this path
relative to RFC 7489.
Scott K
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
