--On Friday, December 31, 2021 19:03 -0500 Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote: > On Fri, Dec 31, 2021 at 6:04 PM John C Klensin > <john-ietf@xxxxxxx> wrote: > >> >> >> --On Friday, December 31, 2021 17:09 -0500 Phillip >> Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote: >> >> > ... >> > It is not in the callsign system itself, but once there is a >> > directory that maps @alice onto a public key fingerprint >> > plus a service from which a contact assertion signed under >> > that key can be obtained, we can bootstrap to new messaging >> > protocols that give us any desired communication properties >> > very easily. >> > >> > The reason SMTP email is so sticky is that all Bob has is >> > the address alice@xxxxxxxxxxx. So Alice is limited to the >> > set of protocols supported by example.com in the case of >> > Alice and the least common denominator in the general case >> > which is SMTP. There is no way to negotiate a service >> > upgrade to OpenPGP over SMTP. >> >> Sorry but, having spent much of the last several days working >> on rfc5321bis, I don't understand that at all. >> >> First of all, at least in principle, absolutely nothing >> prevents Alice from creating alice-bob-only@xxxxxxxxxxx (or, >> preferably, something much more obscure) and then discarding >> or rejecting anything that does not come from Bob, using >> whatever authentication mechanism the two of them can work >> out. > My goal is to allow Madonna to use @madonna as her callsign for > personal and business use. (rearranging for convenience) > A naming system where Alice has to create a new name for every > set of people she wants to communicate with isn't really a > naming scheme. And you still don't do anything to address the > issue of SMTP spam. Oh and please don't suggest that because > an anti-spam solution has a very small chance of allowing a > few pieces of unwanted messages through that it is no > improvement on SMTP. Ok, but "Madonna uses a single callsign and has things routed selectively depending on the senders" is different from "Madonna gets to use multiple callsigns". I was picking up on and responding to the latter. > Only the callers she authorizes get > access to her personal inbox, everyone else gets her PA or her > fan club secretary. >... In principle, not hard to do that in an SMTP environment and there is a great deal of deployed proof of concept. Alice can simply set up filtering, possibly in her MUA, possibly with SIEVE or something like it, or possibly in other ways, that maintains a "people I want to hear from directly" list, routing everything else to the PA, the fan club, and/or spam as she (and the configurations and tools she uses) have available and find appropriate. That solves the authorization problem but not the authentication one. We have ways to do the latter too but have had extreme problems getting people to understand and bother to use them. Or she might do something else (or combine it with the above), which would be to prioritize messages, or route them to different folders or mailboxes, based on whether those messages could be authenticated at the user level. I can't be the only one who has experimented with that and found it useful but impeded by lack of general usage of signing or other authentication mechanisms by senders. Depending on configuration, SPF, DKIM, and DMARC can be seen as variations on that theme (my opinion, or yours, about them is another matter). But that was not the point I was trying to make -- I obviously didn't make the point clear. So... My main point was something else. Your assertion that these things cannot be done with SMTP and supplemental tools is simply false. An assertion that your method is better, or would be much better if we were starting from a clean slate, might be true, but that is different from saying "can't be done". Similarly, an assertion that doing them on an SMTP base would be quite ugly is different from "can't be done". I, and I believe almost everyone else who has worked closely with SMTP (and/or other aspects of Internet mail) for many years, have a list of things we would do differently if we were starting from scratch while knowing what we know now. The bar for "do better than today's SMTP if one were starting over" is actually fairly low. So, from my point of view, there are three questions, with the first being purely speculative. I don't have answers to the second or third, but I do have a hunch about the second: (1) If we were starting from a completely clean slate today, trying to build a communications system for messages longer than typical 19th century telegrams, would we base it on something resembling the postal services and/or SMTP models or on something closer to your model? In thinking about that, remember that --the present situation with a small number of dominant providers notwithstanding-- the SMTP design is for an extremely distributed system with no central authority while yours, as I understand it, requires a centralized mechanism for (at least) callsign registration and handling no matter how benign, profit-free, and robust that mechanism might be. (2) Given that we probably cannot start over and that SMTP-based systems are very widely deployed and used (the rapid growth of systems optimized for very short and quick communications notwithstanding), is your system sufficiently better to take over despite the considerable inertia implied by the installed base? Of course, if "take over" is not your goal but, instead, you would be satisfied to help out a small and sophisticated set of users who would be happy with a new system to communicate with each other while continuing to use traditional email for communications with others, the threshold of "sufficiently better" might be much lower. (3) Given how poorly we have done with deployment and active use of S/MIME and [Open]PGP (and scaling the PKI required for the former and the web of trust for the latter) to the non-specialist public and the almost equally poor track record of new and incompatible systems taking over from ones that are widely used --at least in the absence of the "new" version being completely free and/or having huge amounts of bundled marketing muscle and money behind them-- would your system be more likely to be accepted and deployed if, instead of saying, "SMTP is dead or irretrievably broken and needs to be replaced", you were looking at hybrids and transition strategies? Again, I don't know the answers but, no matter how much better your ideas might be (at least in your opinion), the installed base (or at least the portion of it that has not abandoned conversations like this for << 500 character messages) so far does not agree with your opinion about the non-usability and non-adaptivity of contemporary Internet email models. And every time someone looks at your messages or specs and makes comments about telephone numbering, X.500 or other universal directory systems, the DNS as it has evolved, or transnational use of national identity or certification systems, it is a challenge to you, not just to show that you can do better but that your system won't ultimately succumb to the problems for which those systems have been criticized. best, john
