Despite what everyone said, I'm excited specifically for DKIM2. As someone that had managed a mailing list, that one is probably the hardest thing to juggle around and DKIM2 layering seems to fix that issue neatly. I hope postfix has a guide proto.
DKIM2 and DMARCbis Have Landed
11–20 of 100 posts
Re: DKIM2 and DMARCbis Have Landed
#12I really don't understand what the original DKIM was not sufficient. Can someone ELI5? If you can verify that a message (including headers, which DKIK can sign) was signed by the outgoing server, then why isn't that the end of the story? Who cares how or why it got forwarded, or whatever else?
Re: DKIM2 and DMARCbis Have Landed
#13Can someone distill this down to how it will be used by the big three email providers to make it impossible to use email except through them?
> by the big three
Which big three?
Gmail has something like 1.8 billion users. iCloud mail around 1 billion.
Microsoft with 400 million users of its email is closer to Yahoo! Mail (225 million users) than to the big two.
Re: DKIM2 and DMARCbis Have Landed
#14Sounds pretty cool! I wonder if it closes enough holes that we could finally stop using SPF at all?
Re: DKIM2 and DMARCbis Have Landed
#15Missed opportunity to get rid of SPF. What I want to my DMARC policy to say: if someone is sending you an email that claims to be from my domain and it's not signed by one of the keys I have published under my domain, you should reject it, regardless where it came from.
And on the receiving side, the policy is similarly simple: if I receive any unsigned or unaligned email, I will reject it.
Edit: to clarify, I want there to be an option where I specify my DMARC policy to explicitly tell well-configured receiving servers "ignore whatever I have configured as my SPF record, only look at the signatures". There will no doubt be a long tail of mail servers where I will still need an SPF record for them to accept my mail.
Edit2: Another feature that I feel is lacking is ability to give dkim selectors a scope - e.g. this key is only valid for these particular From addresses.
Re: DKIM2 and DMARCbis Have Landed
#16Aw hell. How many things do I have to set up just so that I can send e-mails from my own domain? The effect of all this seems to be less "making e-mail secure" and more "making it so that only Google, Apple, and Microsoft can send e-mail successfully"
DMARC isn't for sending email successfully, it's for preventing other people from impersonating your domain. Without it, there's nothing stopping anybody from sending an email saying it is from you@qurren.com. SPF tried. DKIM tried. Both of them had gaps.
When you use them together and have a DMARC policy that requires one of them or the other for successful delivery, it's the best current solution.
Re: DKIM2 and DMARCbis Have Landed
#17Aw hell. How many things do I have to set up just so that I can send e-mails from my own domain? The effect of all this seems to be less "making e-mail secure" and more "making it so that only Google, Apple, and Microsoft can send e-mail successfully"
DKIM2 and DMARCbis are actually the opposite of this. They are long awaited fixes of brittle and often broken systems that are designed to now make providing secure email easier rather than harder.
They both have fairly clean migration paths and resolve a lot of the annoying edge cases that currently exist with authenticating and verifying email.
Re: DKIM2 and DMARCbis Have Landed
#18Aw hell. How many things do I have to set up just so that I can send e-mails from my own domain? The effect of all this seems to be less "making e-mail secure" and more "making it so that only Google, Apple, and Microsoft can send e-mail successfully"
> Aw hell. How many things do I have to set up just so that I can send e-mails from my own domain?
... said every spammer.
I'm sorry for your pain, and I'm in the same boat.
But it's important to understand that any sufficiently large, distributed-agent system (like federated email), will see the rise of parasites that will pump resources and diminish the value of the system.
What we're seeing here is an "immune" response to those parasites. We all pay for it.
I think this is an important lesson for anyone designing a distributed-agent system [1]. How do you design it so as to keep the bad actors out, or at least so their impact is negligeable?
[1] imma make my own email system! With blackjack, and hookers! oh wait...
Re: DKIM2 and DMARCbis Have Landed
#19Missed opportunity to get rid of SPF. What I want to my DMARC policy to say: if someone is sending you an email that claims to be from my domain and it's not signed by one of the keys I have published under my domain, you should reject it, regardless where it came from. And on the receiving side, the policy is similarly simple: if I receive any unsigned or unaligned email, I will reject it. Edit: to clarify, I want t…
I suspect SPF is used because it's cheaper than performing cryptographic checks for each email. A (cached) DNS lookup and IP check on a connection is comparatively cheaper.
Re: DKIM2 and DMARCbis Have Landed
#20I really don't understand what the original DKIM was not sufficient. Can someone ELI5? If you can verify that a message (including headers, which DKIK can sign) was signed by the outgoing server, then why isn't that the end of the story? Who cares how or why it got forwarded, or whatever else?
There are a few gaps with DKIM.
1. You have to set it up on every sending server. It's easier today but it wasn't always
2. You have to periodically rotate each of the keys that you setup because they can be cracked/stolen. Soon as somebody steals your key, they can impersonate anyone sending email from your domain.
3. Receiving email servers have no way of knowing if a message they received without a DKIM signature is supposed to include a DKIM signature, so simply not including one creates a scenario where receiving mail servers have to guess if the message was really from you.