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.
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.
Wait, that is probably from the local mailer, and otherwise the sender may never know about the rejected messages.
If you send an email, your client would talk to your local MTA (i.e. the SMTP server you own or are authorised to relay mail through, e.g. ISP). The local MTA usally just accepts the email to insert it into a queue for attempting delivery. When your MTA processes the queue, and talks to another and gets 5xx or 4xx response, your MTA will generate a "bounce" (non-delivery report) email that lands in your inbox with the details of the response it received.
So jeffbee is correct that when the local MTA gets a 5xx or 4xx response code in the SMTP session with target MTA, that /the response code is not a bounce/. Microsoft responding with 5xx or 4xx in the SMTP session, they are not bouncing the email. They are refusing to accept delivery.
For Microsoft to "bounce every email" from the original parent commenter, it would have accept each email first, and then use the return path address of each email accepted to send a bounce email asynchronously, i.e. the bounce is not part of the original session.
If a MTA talks to another MTA who accepts a message for delivery, they can then bounce the email at any later point via the address specified in the return path header. Why? Maybe incoming email is queued and scanned, because it would take too long to determine if it passes secondary rules when it's initially being accepted.
Given how this works, you could take an email inbox you received a year ago, or five... and send an email with whatever content to the return path address, and you have "bounced" the original email.
A 5xx is a bounce, and results in a bounced email message. Variances always abound, but I'll stick with my 30 year old terminology, and it is correct.
You don't agree with my terminology, but we're not disagreeing on what's happening. In this case, as per my dictionary, 'rejected' and 'bounced' are synonyms. If this was me, and my MTA hitting this Microsoft server, my MTA/server would see the bounce(5xx), then my MTA/server would generate a bounce message(email) which I'd receive in my inbox.
The bounce message is a result of the bounce. The action/cause is the bounce/reject 5xx.
How can you have a bounce message, without a bounce happening?
Again, you don't agree with this terminology, and that's fine. But I'm not pulling this out of a random hat, it's 30+ year old terminology that I've used with endless people locally and online. That doesn't mean your view is wrong, we may just be running into local variances in lingo.
There are all sorts of edge cases in our compute discourse. I ran into a company where they didn't use initialisms to discuss daemons/protocols, but treated them as acronyms. Of course, they didn't really discuss such things often. So when discussing smtp, they'd pronounce it 'sim-tee'. Of course, sntpd, smtpd, snmpd, and others are all pronunced 'sim-tee', which makes for a fun meeting. Think of it as 'I am groot' taken too far. For prudence, I kept enforcing initialisms, which of course resolved this.
Anyhow! Point is, well.. not really sure except info.
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.
The anti-email authenticity standards gang has always smelled like the anti-TLS gang to me.
Which is subtly different.
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.
... 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.
In total they are a finite set, and even catching 5% of them will scare the rest.
In the physical world, we can have police that go after criminals who break down doors. But builders also have a responsibility to install locks.
And negligently failing to build a lock is actually not a great look if you want police to give you the time of day.