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?
They want to allow forwarders (such as mailing lists) to modify signed messages all while keeping the original signed author email address. It is meant to replace ARC which is now deprecated.
You can now verify who changed what and when but it is still based on will and trust to accept what has been altered and therefore a security theatre.
It ‘solved’ a problem for a mailing list that insist on altering signed messages, even though they do not have to modify forwarded messages in my opinion and many lists do not.
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 boun…
> Can you send mail from something that doesn't have a DNS entry? You never really could. Participating in public email exchange requires that the sender can resolve then "fully qualified" domain in your return address. Except after prior agreement or authentication, messages simply that fail this are not generally accepted. > If your headers are correct, are you guaranteed mail bounces for un-deliverable emails? Eve…
> You never really could. Participating in public email exchange requires that the sender can resolve then "fully qualified" domain in your return address.
I thought you could send from for things that shouldn't bounce.
I don’t think they can. Spam, like speeding on highways and drug sales, is such an asymmetric enforcement area that I have very limited confidence that legal enforcement would make a significant dent in the volume. It’s far too technically easy to anonymously, repeatedly break anti-spam laws. This is an area where consortium enforcement (like the big inbox providers pushing solutions like DKIM2) is probably the most…
They keep finding that huge spam campaigns were run by one guy from his bedroom. I can't remember which specific spam campaign was recently caught, it might've been the phone spam about car insurance. It was one guy with a huge botnet. In total they are a finite set, and even catching 5% of them will scare the rest.
I interpret that the opposite way: if a huge spam campaign can be run by a guy in his bedroom, there’s no way that larger spam operators can be effectively killed by legal action. They’ll just employ different guys in different bedrooms. The same thing is true with phone phishing scams—they’re not individually hard to eradicate, but the combination of lucrativeness and rapid-rebootability means that legal crackdowns in the past have not been effective at scaring the rest out of business.
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…
1&2 sound worse after this update as described.. I'm not really sure why we are still bothering with this when DNSSEC progress means DANE like setups could solve the original E2E S/MIME issues of payment and domain indicating expectation of what its email senders are required to have for S/MIME. There are some aspects of (possibly positive) deniability by an individual that probably still remain with DKIM but they ki…
Is Cloudflare a cheapo VPS? It is a cheap VPS, but it would still be nice if there was a way to know (not assume) beforehand. > 550 5.7.1 Unfortunately, messages from [IP ADDRESS] weren't sent. Please contact your Internet service provider since part of their network is on our block list (S3150). > Your IP(s) qualify for conditional mitigation. Still blocked. The system is working as expected.
You can't have the cake and eat it too. Either you use cheap infrastructure that attackers can buy by the bulk for sybil attacks. Or you pay a reasonable price for a slice of an IP block that doesn't share its reputation with elcheapos.
No disagreement here. I had never planned to use it for email, but I was bored and I already had it when I got an idea.
> Can you send mail from something that doesn't have a DNS entry? You never really could. Participating in public email exchange requires that the sender can resolve then "fully qualified" domain in your return address. Except after prior agreement or authentication, messages simply that fail this are not generally accepted. > If your headers are correct, are you guaranteed mail bounces for un-deliverable emails? Eve…
> You never really could. Participating in public email exchange requires that the sender can resolve then "fully qualified" domain in your return address. I thought you could send from for things that shouldn't bounce.
If the return path is null that just clarifies unattended notifications should not be returned. The mail is still considered to be sent by the transmitting system, and when no mailbox is specified, the implied envelope sender simply defers to the "postmaster@your-ehlo-fqdn.example" address.
(Accepting mail at the "postmaster" mailbox is a mandatory part of SMTP, as is mentioning your fully qualified domain name in the "Hello" message when initiating the session. Public mail exchanges are free to, and often do, reject clients that submit anything other than resolvable domains there. Same with clients that use for applications other than those very limited "notification about specific quoted/referenced message" scenarios where the standards mandate .)
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 t…
Best way to go about this is just blackhole SPF so it never passes, then set your DMARC alignment to strict. This approach prevents SPF from satisfying DMARC on the vast majority of providers [1]. [1] https://taejoong.github.io/files/publications/hamza-2026-dma...
In theory, yes, in practice this will currently result in deliverability issues, both for servers which don't speak dmarc and for spam signals. I have tried this :)
If this mode of operation was an explicit choice, this would give me the option to have a fallback SPF record for legacy mail systems, but most up-to-date servers will use the more secure and (for my use case) operationally simpler verification.
Isn’t that already what DMARC does though? For DMARC to pass you need DKIM _or_ SPF alignment, not both. It’s designed that way because there are scenarios where SPF _can’t_ pass (email forwarding, mailing lists). So a well-configured mail server should accept your email regardless of SPF if DKIM is properly configured. Re: specific keys for specific usernames: I can appreciate that you wish DKIM allowed for this, an…
> Isn’t that already what DMARC does though? For DMARC to pass you need DKIM _or_ SPF alignment, not both. GP wants require DKIM, so SPF alone is insufficient to send mail from their domains. If everyone did dmarc, you could set SPF to -all. But there are servers that check SPF but not DMARC. You need to pass SPF for those, so you need a passable SPF... but then DMARC will pass with only SPF.
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 s…
> Or just use Hashcash or any other PoW. People love the idea of this, but i don't think it really makes sense. How high do you set the PoW to? I dont think there is any middle ground that would actually deter attacks but not deter legit users.
When I have personal email server and I need just ocasionally send email or two it can be as high as possible.