[kube-system]

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

[unsignedint]

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.

[kube-system]

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.

[unsignedint]

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.