--On Tuesday, September 6, 2022 12:36 -0400 Timothy Mcsweeney <tim@xxxxxxxxxxxxxx> wrote: > It's pretty easy to say there is no evidence of how it works > when you refuse to try it. Not what I said or at least not what I intended to say. > As per our conversation a couple > months back when I asked you about getting a 5xx response code > added to your bis draft, I told you to send me a simple hello > email to test@xxxxxxxxxxxxxx and follow the link in the reply. > > Go ahead, I'll wait. I think you are confusing two very separate things. (1) If I send a message (deliberately with subject and body of "test", I get a response that tells me that address blocks everything except from people on the safe list and then gives a link for being added to that list. That message is not different in any substantive way from dozens, probably hundreds, of messages I've received over the years whose theme is "unless we know you and/or can authenticate you, your mail isn't getting through and here is how to fix that". As an interesting example, I've had a mailbox (different names, different platforms) since the 1970s that has never gotten any spam or other trash because it requires proprietary sender authentication before a message is accepted. The same thing could be done, albeit less reliably because of the ease of faking email, with a white list. In the years in which the rules have been enforced in the MTA (delivery receiver-SMTP) rather than at or near the MUA, I generally have not generated a bounce or reply message on the theory that I don't want to tell bad actors that the address is active and give them an incentive to break any authentication system I might be using. Your model, as I understand it, is different from that, but really not much. It is even less different from systems that respond to incoming messages (either per-message, per-apparent-sender, or within some time period) with a response that says "have not seen you (or this message) before (or recently), please perform the following act to prove that you are not a dumb robot". For your system, if I then send a second message --same source address, different subject line and content, I get (after a fairly short wait), nothing. Going through the link gives me a short form that presumably allows you (or your robot surrogate -- I can't tell and don't care) to decide whether to add the address to a whitelist. Again, nothing obviously new about that either, details about what you put in your form and how it is processed notwithstanding. Now, do such systems "work"? Sure, if the number of qualified senders is kept sufficiently small (some of the variations don't scale terribly well, even if they may be able to handle thousand of senders in their mechanism or databases) and people are willing to go along. However, every person you ask to go through the link and fill out that form is likely to wonder whether communicating with you at that address is worth the trouble. You might or not like the answer. It would also suggest some behavior you almost certainly would not like, e.g., having those who maintain mailing lists set up a handshake protocol that would prevent you from posting if your address would not receive messages from anyone on the list without registration. That would certainly protect you from spam, but would also protect you from many legitimate messages. And, again, nothing novel in any of that. The fact that we have not seen widespread adoption creates a real question of why you think your method would achieve widespread adoption. If you don't care about that, you may have a tool that works for you and your preferences but, if it is not of obvious general use and likely to see such adoption, I see no reason why the IETF should spend time on it, much less start altering some rather basic protocol specifications (or at least how they are interpreted. (2) None of that has, at least AFAICT, anything to do with a "drop#" URI type or syntax. Things appear to work perfectly well with a conventional URL. Part of the "won't work" comment is that, if you were to convert the message you are sending out to use a drop# URL rather than an HTTPS one, the overwhelming fractions of email clients in the world would generate an error if anyone tried to use the link. Most of those that did not would say something like "unknown or syntactically invalid URI, what do you expect me to do with it". Either way, if there is no deployment beyond MUAs and browsers whom you control or have convinced to implement specific support for your scheme/mechanism, it is hard to figure out why the IETF should care, much less invest effort. Same comment applies to use of such a URI in a browser: much as I might wish it different, few, if any browsers today are good and handling URI schemes they don't recognize and fewer are going to recognize something that does not conform to the syntax of 3986 as a URI at all. Most of the same comments apply to your idea of a special email response code. We decided back when the "extended code" idea was introduced that we did not want to introduce more three-digit codes unless the need was very clear and very strong. That decision was reinforced by the knowledge that both the specifications and most implementations provided for checking the first digit only, especially if the rest of the code was unrecognized. You have not made --or, IMO, even tried to make-- a compelling case as to which the email infrastructure needs an extra code. That case is very different from one you might make that your particular idea might benefit from such a code. More generally... If this were a novel idea or set of ideas, my personal reaction (maybe not the IETF's) would be "let's see how we can define it so it does not require modification of core protocols or with deployment across the Internet as a condition for being useful". With those modifications, let's go ahead and get it documented and see if anyone [e]se] cares to modify their systems in a way that would make it useful to more than just Tim and his closest friends. Even though few, if any, of the essential ideas are novel, that is a longer form of what I said in my last note. best, john
