At a fundamental authentication property level, there are additional differences too. IPs tend to be shared more than private keys. Proving an IP based validation to a third party is harder than with a digital signature. (This is one the issues of trusting the SPF results in ARC-Authentication-Result, whereas with DKIM once can try to validate the signature yourself). On the other hand it's only fair to make the observation that SPF is easier to set up than DKIM and we want to capture those benefits as well.
Is dkim really harder than SPF? I think part of the reason some of mega ESPs only support dkim alignment is because a lot can be automated. And you’re addiding something, not changing something (I.e., the envelope from). In most cases these days implementing dkim on the user side involves copying and pasting a txt or, increasingly common, a CNAME. It’s easier for everyone.
I think DKIM’s simple for the end user at the mega ESPs. The incentives push them to make it as easy possible, while punting or shoving aligned spf aside.
No, SPF has its place unless I’ve been a way from this list for so long I didn’t get the memo on that. So yes not deprecated until we come up with something a bit better or it becomes more of a liability than an asset.
We're definitely not saying SPF should be deprecated, and in fact we want more deployment of SPF as it's highly complementary to DKIM both from a deployment perspective but as a spam fighting signal. We just want to prevent its use in From header spoofing.
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.
Just pointing out we're prototyping one of the drafts and there's other work behind the scene.
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'm not sure. Much as Case 1 provides safety, the email Internet today has a large part that's based on Case 2 and 3 and it's up to us to frame standards that provide safety for our users by solving the issues you mentioned. (Or if those needs are ignored, then likely those users will move to walled gardens that can claim more safety) For case 2, we (and others) put drafts that provide a technical solution. For case 3, we posed some ideas that can hopefully help. -Wei
Scott K
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
|
