Hacker News Reader

Comment by kube-system | Hacker News Reader

> at least you get more signals to work with (headers, DKIM/SPF/DMARC, filtering, etc.) than just a string of 10–12 digits with no real context.

For most people it is a distinction without a difference because they know about as much what to do with a DMARC policy as they do an SS7 frame.

DKIM/SPF/DMARC as bandaids just as much as STIR/SHAKEN are, they just need to get a kick in the ass to implement them -- on both fronts. I get tons of official and sensitive email still from domains that fail DMARC.

View on HN

Sure, but my point still stands — you have more tools to work with in email. For what it’s worth, I can usually contextualize a message from the subject line and the sender’s address without needing to dive deep into headers. (Phishing is definitely a real problem, but it’s not unique to email in this discussion.)

Now compare that to the PSTN: what does 555-123-4567 really tell you? Not much. It’s just a string of digits with no inherent context. And unlike email, I can’t even choose to outright refuse delivery of a call at the network level.

You have more tools because the market created them because it’s a federated protocol. The PSTN is a different case where market forces don’t align incentives with spam reduction. This is why regulators like the FCC exist.

I get the distinction you’re drawing, but that just brings us back to the same fork: if decades of FCC involvement haven’t produced a trustworthy caller identity system, then the reliance on regulation isn’t solving the structural weakness, it’s just propping it up.

At that point, we’re repeating the same values clash — you see regulation as a workable fix, I see it as evidence of fragility. I don’t think continuing this line is going to get us any further.

> Now compare that to the PSTN: what does 555-123-4567 really tell you?

It tells you exactly as much as the "from" field does in your email.

> you have more tools to work with in email.

Only if you're an engineer implementing a mail server configuration. But if you're implementing a telco you also have more tools to work with than a caller ID.

End users use DMARC/SPF the same way end users use STIR/SHAKEN... they don't. None of them are user-servicable values. And service providers use DMARC/SPF the same way end users use STIR/SHAKEN... they implement those controls for their users in the form of a managed service.

Even if I don't run my own mail server, I can still open an email header and see context. Last time I checked, I can't walk into a telco and ask for the telephone equivalent of that. On PSTN, there's nothing beyond a bare caller ID string, and that lack of context is exactly why I see it as a problem.

Email gives end users multiple signals and filters to work with. PSTN doesn't, and that's why I disagree with your equivalence.

DMARC/SPF/DKIM are not something that users can take advantage of by reading their email headers, because it is nonsensical to end users.

You can take advantage of it because you're an expert. Just because email vomits out more information that are useful for experts doesn't mean it is better as a real world system for normal people who use it.

I've been consistent in framing this as a structural critique. The question isn't whether most users inspect metadata. It's whether the system makes that inspection possible. That's the architectural affordance I've emphasized throughout. Email exposes trust signals. PSTN does not. Its opacity isn't a side effect of user behavior. It is a design feature. That's the distinction I've been drawing, and it remains central to the evaluative lens I've laid out.

Reply on news.ycombinator.com