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

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: https://www.fcc.gov/call-authentication
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".

pgp0h44UJgpPN.pgp
Description: PGP signature

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp