[Top] [All Lists]

Re: [ietf-smtp] IETF Policy on dogfood consumption or avoidance - SMTP version

2019-12-27 21:58:09
Keith Moore writes:

I wonder whether there's anything that we can learn from the SHAKEN/STIR example, which now has some legal support at least in the US.

This piqued my curiosity, so I briefly Googled up on its history.

The FCC regulates telephone companies, and has some authority to impose rules on them, and the SHAKEN/STIR framework was, slowly, pushed onto the industry within this existing regulatory framework. The following page provides a nice timeline:

And this is where the analogy breaks down. Anything that's listening on port 25 will accept mail from anywhere else in the world. There's no existing regulatory authority of any kind here. The pitifully little authority that exists is over turnkey Internet providers. Government-imposed controls over communications are found only in certain authoritarian political regions, and only that kind of a control could be in a theoretical position of imposing something similar for SMTP. And, after some thinking, I still think they'd have a problem handling SMTP entering the aforementioned political region.

P.S. I started getting robo-calls in Mandarin, for the very first time, after my cell phone carrier activated its SHAKEN/STIR implementation. I presume that the shown caller ID was valid. A lot of value that is to me. I definitely agree: SHAKEN/STIR is an excellent analogy to various SMTP validation schemes, like SPF and DMARC, and from the looks of it, is just as effective – has some marginal benefit, but somewhat misses the mark. The problem was always not the sender's identity, but its unsolicited/unknown nature. I will maintain that the focus on verifying the sender's John Hancock is misplaced; until the unsolicited nature, itself, of either spam or robo-calls, gets /directly/ targeted, the respective problem will remain unsolved.

So, how do I think it should be targeted. Well, I don't think it needs to involve SMTP. DMARC is implemented in mail headers, and SMTP's involvement, if any, is limited to accepting or rejecting mail that fails DMARC validation. I think this gets handled similarly – in terms of header-based metadata proving/disproving that the message's source is known[1] to the recipient or it is completely unknown/unsolicited: spam. For that reason, I don't think this is SMTP's problem to solve.

[1] Note that "message's source is known" includes things like sending mail to a publicly listed contact, so the objections about the usefulness of being able to receive mail from new contacts is covered. The "message's source is known" would simply include things like "public contact info given at such and such place".

Attachment: pgp0h44UJgpPN.pgp
Description: PGP signature

ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>