Hacker News Reader

Comment by lisper | Hacker News Reader

No, it's not a fundamental problem. It's just laziness on the part of many email providers. My email server has proper SPF records, and so anyone whose email server is configured properly can easily verify that my server is authorized to send email on behalf of my domain(s). But email admins just subscribe to blacklists and follow them blindly. There are a few big players, including Microsoft and AT&T, who just don't care if a few small players get blocked by false positives. (Ironically, despite their tolerance for false positives, they still let through an enormous amount of spam. I know this because my parents have their email on AT&T.)

View on HN

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.

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 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.

> 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.

Just to be clear: Due to email forwarding, having an SPF record isn't enough for domain authentication; you also need DKIM and DMARC. Mailbox providers want to deliver emails that people actually want to get, so not relying only on SPF records is a reasonable policy. But yes, thanks to domain authentication, we should be able to move away from IP reputation to domain reputation – at least in theory.

See my response here: https://news.ycombinator.com/item?id=34869796

And setting up DMARC opens you up to an entirely new type of spam: corporate networks emailing you every time someone spoofs you. I had it set up for a short time before I quickly turned it back off.

For one thing, you can configure a DMARC policy without a reporting address. For another thing, you can use third-party services, such as https://dmarc.postmarkapp.com/, to aggregate DMARC reports for you (if you're fine with the privacy implications of that).

You can also just set up DMARC without a reporting endpoint. But DMARC aggregate reports are very useful, so I wouldn't recommend using DMARC without reporting. Also, you do not receive a report 'every time someone spoofs you', but rather periodically, at an interval which you can even configure.

That said, DMARC aggregate reports are not supposed to be human readable. You don't want to set the reporting endpoint to your personal inbox. You need a DMARC aggregation tool, such as included in https://www.mailhardener.com to process them. (full disclosure: I work there)

I have some procmail rules set up that sends most of that stuff to a different mailbox that I never look at.

Reply on news.ycombinator.com