> On 09/06/2022 3:57 PM EDT John C Klensin <john-ietf@xxxxxxx> wrote: > > > --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. > John, Thanks for (kinda)trying it today. You don't have enough information to determine its novelty. And you don't have enough information to determine its scalability. And you don't have enough information to determine the model. It can fix spam and as you helpfully pointed out, all but a very very few will fill out the form. You didn't fill it out, see, its working already working. I didn't _need_ the response code for it to work, that was to benefit anyone else who wanted to do the same thing as I was doing (in reagrds to email only). Water under the bridge now i guess. With that in mind, I'm not asking the IETF to spend anytime on it. As a matter of fact, I've never wanted the IETF to be involved with anything I'm doing. This whole thing wasn't supposed to be more than an IANA registration. Remeber in that email I sent you where I said there are 289 Unassigned Experts and 638 Specifications Required?[1] That's a good place to start looking for people asking for the IETF to waste time (unless the IETF just wants the thoughts). And I think its unfair to charactize things as if I'm asking for something huge while some people were ready to create whole new subsystems for the GNS to use ALT tld. Bravo to Larry Masinter. He fully gets what its all about. [1]https://www.iana.org/protocols
