But they are not all the same! I'm not even sure this cryptographic signed sender stuff is a good idea for email.

But good look getting through to postmaster@gmail|outlook etc.

But they'll hold you to some arbitrary standard that's supposed to mean "less spam" when they should have more than enough traffic to get by with statistical/ml methods anyway... /rant

This cryptographically signed sender stuff is extremely important.

DKIM+SPF+DMARC means you can prevent anyone else from impersonating your domain.

Every MTA will reject mails that violate the DMARC policy you specify in your DNS, if you have any.

All the old From: [email protected] scams are gone, impossible.

This means spammers either have to use hacked servers, or their real From: address.

And as soon as they have to use their real From: address, it becomes trivial to block spam.

Blocking spam is only so hard because From: was basically meaningless until now.

Yeah well. It's email. Either the postcard is (cryptographically) signed by a personally trusted sender, or it's unsigned.

It's not like impersonation is dead. When I signed up for the Gmail roll-out, [email protected] was reserved, but you can email me at [email protected] - a poor Norwegian translation equivalent. More importantly, I can email you from that address, and tell you there's a problem with your account, could you please verify that your password is "hunter2", if not email your current password so we can verify that your account is secure (not that I ever have, or will, I got the account for a laugh).

Federated trust (s/mime) or Web of trust/direct trust(gpg) secures email. All this domain pseudo secure dns nonsense... I'm not sure I accept it's better than static analysis.

The point isn't to verify the account, the point is to validate that the account belongs to a certain server.

If I get email from [email protected], then I now know it's from example.tld. If the mail is spam, I can ask example.tld to block alice, or I can simply blacklist example.tld.

The important part in this is spam prevention, and that if I get an email from @paypal.com, knowing that it's real.

What you're complaining about is another question, but not really relevant. Google always uses @google.com for employees, and if you get an email from that, it's real.

This is about enforcing identification, not verification, security, trust, or anything else.

> If I get email from [email protected], then I now know it's from example.tld. If the mail is spam, I can ask example.tld to block alice, or I can simply blacklist example.tld.

Is this better than graylist+whitelist? Is it better than content based filtering? I'm not convinced.

Is it better than requiring tls with valid cert for smtp? I can't see how.

Rather than all this mess, I think I'd prefer we start at tls/ssl required for smtp...

Yeah I'm talking more about how every other mail provider has their own rules and you have to set it all up. Like one requires your mail domain to me an AAAA record (where I've used a CNAME) and other things.

That's not just one, most require AAAA or A records.

With SPF, DKIM, DMARC correctly set up, correct IPv4 and IPv6 reverse DNS, only A or AAAA or NS or GLUE records used in the entire resolution path, correct from and reply-to addresses, you should usually be good to go, though.