ES version is available. Content is displayed in original English for accuracy.
Advertisement
Advertisement
⚡ Community Insights
Discussion Sentiment
52% Positive
Analyzed from 1816 words in the discussion.
Trending Topics
#email#mail#dmarc#domain#spf#more#still#spam#dkim#set
Discussion (50 Comments)Read Original on HackerNews
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"
They both have fairly clean migration paths and resolve a lot of the annoying edge cases that currently exist with authenticating and verifying email.
Recently I checked the IP against blacklists, waited a few months, did all of the other things, and then found out Microsoft bounces my entire VPS’s IP range. Appealing did not help.
They intermittently block Cloudflare email routing IPs too. All of these security measures and still it comes down to the IP address of your sender.
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.
Making a spec that contains a venn diagram of most of the features each of the signatories to the specification have implemented themselves ends up pulling the ladder up behind them. Each non-academic committee member discovers they're already more than 75% of the way to having completed the spec and any junior members or amateurs have years of work to do in order to catch up to Now. If any upstarts threaten to get within striking distance of an implementation you can always convene the committee again and discuss version 2 of the spec.
Mobile devices tamped this down just a little bit but mostly they lowered the slope of the line a hair and changed where the focus was a bit.
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.
Which is subtly different.
... 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...
Countries' legal systems really need to do something about them.
Don’t get me wrong, there are tons of areas where countries’ legal systems have no excuse for not enforcing the law more stringently (e.g. flagrant corruption in multiple regulatory bodies’ failure to enforce investment/wire fraud). But spam is part of the other category—technically difficult enough to crack down on that legal action is a waste of time. There are ways to change that, but they’re all either more centralization-prone, worse for privacy/liberty, or extremely expensive.
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.
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.
Because that's easy and keys and signing are hard.
[1] https://taejoong.github.io/files/publications/hamza-2026-dma...
- 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?
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?
Even better: You are more likely to see an immediate refusal instead of a delayed bounce, if the recipient exchange can during transmission already determine that they do not want message claiming to be originally transmitted from X to Y yet breaking their ability to check the signature added by X.
I hope not. Just like SSL, I think requiring a registrar+DNS server to vouch for a durable identity is an important barrier to abuse (and an important intervention point for violation reports).
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.
you're among the first few who have done it:
https://github.com/mjl-/mox/issues/404#issuecomment-43627498...
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.
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.
There are some aspects of (possibly positive) deniability by an individual that probably still remain with DKIM but they kind of remain anyway with domain anchored S/MIME.
Depending on your perspective, this can be either a feature or a bug.
2. Is this an actual problem that has arisen with a worrying frequency in the past, or just a hypothetical? And how is it different from someone stealing your SSH key or TLS certificate?
3. Isn't it obvious from previous emails you've received from the same server?