On March 18, 2024 3:15:42 AM UTC, "Murray S. Kucherawy" <superu...@gmail.com> wrote: >On Mon, Mar 18, 2024 at 1:08 PM Dotzero <dotz...@gmail.com> wrote: > >> >> Add this to 11.1 Authentication Methods >>> >>> >>> Both of the email authentication methods that underlie DMARC provide >>> some assurance that an email was transmitted by an MTA which is >>> authorized to do so. SPF policies map domain names to sets of >>> authorized MTAs [ref to RFC 7208, section 11.4]. Verified DKIM >>> signatures indicate that an email was transmitted by an MTA with >>> access to a private key that matches the published DKIM key record. >>> >>> Whenever mail is sent, there is a risk that an overly permissive source >>> may send mail which will receive a DMARC pass result that was not, in >>> fact, authorized by the Domain Owner. These false positives may lead >>> to issues when systems interpret DMARC pass results to indicate >>> a message is in some way authentic. They also allow such unauthorized >>> senders to evade the Domain Owner's requested message handling for >>> authentication failures. >>> >> >> I have a problem with this 2nd paragraph and believe it is factually >> incorrect. The Domain Owner has in fact authorized the message(s) as a >> result of an overly permissive approach. I would suggest that in fact any >> resulting DMARC pass is technically NOT a false positive because it is >> authorized by the overly permissive approach.. >> >> >It's a false positive in the sense that the result is not what the Domain >Owner probably wanted to have happen. > >It is not a false positive in that the technology did exactly what it was >supposed to do; i.e., this is not a bug. > >We should just be clear about this. > >-MSK, p11g
I agree. I think John's proposed text is appropriate for this. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
