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. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
