Email: Explained from First Principles

Re:Email: Explained from First Principles by franga2000 on Monday February 20, 2023 @08:40AM (#34867939)

Spam and forgery aren't the same. I can be 1000% sure that you own the sending domain, that the mail came from an authorized server, etc., but that tells me absolutely nothing about whether I want to read what you're sending. Spammers used to be lazy and not configure the whole stack, so that became a simple heuristic, but these days it's nearly trivial to set up automatic provisioning of new domains and IPs with full SPF+DKIM+DMARC setups, so the big players went back to blacklists and IP reputation.

Spam definitely is a fundamental problem of all open-inbox systems like email.

[ Parent | on HN ]

Re:Email: Explained from First Principles by lisper on Monday February 20, 2023 @11:41AM (#34869796)

Yes, that is certainly true, but in this case it is irrelevant because it is my server's IP address that is being banned. I am sending email to people with whom I have been corresponding for years (like my parents) and it is being blocked simply because the IP address of my server changed.

[ Parent | on HN ]

Re:Email: Explained from First Principles by klabb3 on Monday February 20, 2023 @04:15PM (#34873013)

Parent poster here. Assuming malicious actors can easily set up all the fancy acronyms to verify the sender’s identity, how should spam be prevented if not through IP reputation (and whatever else they have today)? Should the reputation apply to the domain name instead? Would that protect against Sybil attacks?

To my knowledge, these systems are proprietary, obscure secret sauce heuristics. My point is that we should find a way to do spam prevention in an open and easy to implement way. Such an algorithm could then be applied to any open-inbox system, not just email.

[ Parent | on HN ]

Re:Email: Explained from First Principles by lisper on Monday February 20, 2023 @05:52PM (#34873988)

> Assuming malicious actors can easily set up all the fancy acronyms to verify the sender’s identity

How is a malicious actor going to set up a fake SPF record for my domain without compromising my DNS account?

It makes sense to block a domain even with a correct SPF record. It makes no sense to block an IP with a correct SPF record for a domain that you already trust. And, like I said, I'm getting bounced mail from people I've been corresponding with for years, so I know the recipient email providers do trust the domain. They're just being stupid with IP black listing.

[ Parent | on HN ]