In a perfect world, we would have a two-tailed test, where PASS really means "no malicious impersonation" and "FAIL" really means "malicious impersonation". Absent that ideal, we can try for a one-tailed test, either "FAIL" means "malicious interpretation" but "PASS" only means "uncertain", or "PASS" means "no malicious interpretation" and "FAIL" means "uncertain"
The discussion has convinced me that neither is entirely reliable, so we have a zero-tail test. But as a practical matter, I trust PASS more than FAIL so I only act on FAIL after all other possibilities are ruled out. In the typical environment, messages which are not blocked by sender authentication will still need to pass content filtering, unless the sender is whitelisted. Whitelisting needs to be based on evidence to avoid whitelisting an impersonator. So if an evaluator does any whitelisting, he needs a PASS rule to make whitelisting safe. That makes PASS critical, at least for that subset of messages (and those messages may not be from DMARC-enforcing senders.) I don't have the luxury of blocking messages that are legitimate and needed for business purposes, so I have to quarantine and inspect for messages that are uncertain. Sender authentication FAIL is prioritized for that quarantine and review process. Messages which pass sender authentication can still get blocked during content filtering. Content filtering failures often indicate malicious senders, so those results are reviewed and often become sender authentication blocks. Doug On Wed, Jun 21, 2023 at 11:46 PM Scott Kitterman <[email protected]> wrote: > I think that's exactly backwards. The most DMARC pass can mean is from > who it > says it's from. It says nothing about if the message should be accepted. > Even in the case of email directly from the infrastructure of a high > reputation domain, there's no guarantee it didn't get there because one of > the > employees got phished and their credentials or client are compromised. > > Scott K > > On Wednesday, June 21, 2023 9:26:28 AM EDT Douglas Foster wrote: > > Every allowed message is presumed to be free of malicious impersonation. > > That presumption is either based on evidence (some mixture of DKIM, SPF, > > and fcDNS) or blind faith. "Positive assertions" are intrinsic to > what > > we are doing. Without them, we have only blind faith. > > > > Doug Foster. > > > > On Tue, Jun 20, 2023, 1:29 PM Dotzero <[email protected]> wrote: > > > On Tue, Jun 20, 2023 at 11:18 AM Scott Kitterman <[email protected] > > > > > > > > wrote: > > >> I am starting a separate thread, because this isn't just about SPF. > > >> > > >> I think the criticism of the reliability of SPF data is valid, but I > > >> think > > >> DKIM is similarly problematic. Once you get rid of SPF, you'll find > you > > >> haven't really solved much. The next logical step will be to get rid > of > > >> DKIM. > > >> > > >> DKIM has man wonderful features, but the bottom line for DMARC is a > valid > > >> DKIM > > >> signature indicates that the mail was sent (at some point) from an MTA > > >> that > > >> was authorized by the signing domain. This is what a SPF pass result > > >> means > > >> too. DKIM has broader utility in DMARC because it can persist through > > >> some > > >> indirect mail flows, but either way, an SPF pass and a valid DKIM > > >> signature > > >> both mean the message was authorized by the domain in the relevant > > >> identity. > > >> > > >> > > >> The particular SPF problem that's being the focus of some much > attention > > >> is > > >> addressed in the RFC 7208 security considerations (See section 11.4). > > >> > > >> DKIM has a similar, but different problem. The DKIM replay problem is > > >> bad > > >> enough that the IETF has chartered a working group to try to address > it: > > >> > > >> https://datatracker.ietf.org/doc/charter-ietf-dkim/ > > >> > > >> I'll lay out examples to demonstrate: > > >> > > >> Case 1 - First Party Only > > >> > > >> An organization only authorizes email to be sent from MTAs it directly > > >> controls (I know this mostly doesn't exist, but it's useful to show > where > > >> the > > >> problems are). The organization does not send email for any third > > >> parties. > > >> > > >> In this case, as long as the organization can limit sending to > authorized > > >> users, the quality of both SPF and DKIM pass results should be well > > >> aligned > > >> with the nature of the mail the organization sends. > > >> > > >> Case 2 - Sender For Others, Own Domain > > >> > > >> An domain uses it's own domain to send mail for others (like all > webmail > > >> providers). The domain's email is sent using it's own > infrastructure, so > > >> it > > >> doesn't need to worry directly about third parties. > > >> > > >> In this case, there's still no real risk of external forgery, so an > SPF > > >> or > > >> DKIM pass means it was sent by the domain. The risk is to the > domain's > > >> reputation if users sign up and use the service to send "bad" mail. > > >> > > >> If the domain fails to prevent 'bad' messages from being sent, then > these > > >> 'bad > > >> messages get a DMARC pass. The mail is sent through the authorized > email > > >> server, so it gets SPF pass and a valid DKIM signature. > > >> > > >> This is a particular threat for DKIM, because once this succeeds for a > > >> single > > >> message, the user can replay the message on third party > infrastructure to > > >> send > > >> it to large numbers of recipients. This is the core issue the DKIM > > >> working > > >> group was resurrected to address. It is not, however, clear that > there's > > >> a > > >> protocol solution to this problem and the group has been pretty quiet > > >> recently. > > >> > > >> Case 3 - Sender For Others, Their Domain > > >> > > >> When organizations authorized third parties to send on their behalf > (by > > >> publishing an SPF record or a DKIM public key record in DNS), they are > > >> trusting their domain's reputation to those third parties. > > >> > > >> In particular, they are at risk of those third parties doing poor > inbound > > >> validation and other customers of the authorized third parties > injecting > > >> 'bad' > > >> mail authorized by their domain. > > >> > > >> This is where I think the focus of recent discussion has been. > > >> > > >> In these cases, email is emitted via third parties and passes SPF (may > > >> also be > > >> DKIM signed, but I suspect it's less common because replay is > easier), so > > >> it's > > >> authorized, but unwanted. > > >> > > >> Case 2 and Case 3 are both real problems, but only because people are > > >> trying > > >> to make DMARC pass a positive assertion. In order to do that > reliably, > > >> organizations need to be more like Case 1 and be very careful vetting > > >> third > > >> parties that they authorize for. I don't think that's a protocol > > >> problem. > > > > > > I think this is a key factor for the calculus of value in DMARC " > ...but > > > only because people are trying to make DMARC pass a positive > assertion." I > > > agree that it's not a protocol implementation. > > > > > > It really can't/shouldn't be used to try and make positive assertions > > > (even though people attempt to do so). Apart from the cases Scott > points > > > out, there is the very real situation of when good domains go bad, > whether > > > because the good domain has been subverted, sold or for other reasons. > If > > > we move away from attempting to use DMARC to make a positive assertion > > > then > > > the issues around configurations/implementations become less > problematic. > > > Perfection is the enemy of good. > > > > > > Michael Hammer > > > > > > _______________________________________________ > > > dmarc mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/dmarc > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
