I wonder how this post was composed. It's full of LLM-isms, but is also pretty informative and not too fluffy - basically, higher-quality than I'm used to seeing from LLM blog posts, especially at this length. Perhaps it was composed based on a detailed human outline? Or perhaps, could this be the power of Fable?
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.
Missed 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.
Questions:
- How much infrastructure has to be fixed before this works, and in what order?
- Can you send mail from something that doesn't have a DNS entry? How does this affect the first hop from a desktop or mobile SMTP client?
- If an spam email came via SendGrid, Constant Spammer, or MailChump, are you going to be able to tell from the header signatures?
- If your headers are correct, are you guaranteed mail bounces for un-deliverable emails?
They spent a huge amount of complexity supporting mailing lists that claim mutated messages came FROM the original sender instead of FROM [email protected]. Is that use-case worth the additional effort?
First time I'm reading about this, I'm glad there's progress in this area.
The JSON DSL for rewriting emails feels like a spammer/exploit vector waiting to happen. Some product is going to spam filter before applying reconstruction rules, or get tricked into applying reconstruction rules when it shouldn't, and spammers and scammer are going to abuse it.
Until either Google or Microsoft will adopt these standards, they'll remain effectively meaningless most likely. But even so, it's good to know people haven't given up on fixing email's spam problem entirely.
well done
you're among the first few who have done it:
https://github.com/mjl-/mox/issues/404#issuecomment-43627498...
Can 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?
What always bugged me about whole email its that we still dont have two best and most reasonable practice to fight about abuse:
1 - Ability to pay once to provider give your domain Good reputation score to new or old domain and IP and whatever. Like pay once, be a good citizen.
2 - Or just use Hashcash or any other PoW.
This would really solve a problem with 99.9% of spam and allow actually more decentrolized email system.
Fact that no matter what you do its impossible to setup own emaik server to just send few emails a year with 100% guaranteed delivery is just beyond me.
I 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?
Sounds pretty cool! I wonder if it closes enough holes that we could finally stop using SPF at all?
Anyone migrated from exchange to stalwart? Curious about results
[flagged]
Aw 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"