--On Saturday, November 2, 2024 00:33 +0000 Dave Crocker <dhc@xxxxxxxxxxxx> wrote: > On 11/1/2024 4:25 PM, John C Klensin wrote: >>>> This command, described in RFC 821, raises important >>>> security issues since, in the absence of strong >>>> authentication of the host requesting that the client and >>>> server switch roles, it can easily be used to divert mail >>>> from its correct destination. Its use is deprecated; SMTP >>>> systems SHOULD NOT use it unless the server can >>>> authenticate the client. >> FWIW, that test was present in RFC 2821, so is more than 23 years >> old. >> >>> In this new version of the document - perhaps we make this more >>> directive? > Is the existing text causing problems? Where is the documentation > that it is? > > The existing text provides a very clear caution. Is there any > evidence this is insufficient. > > Playing with spec text just because, gosh, we could do better, > should be questionable for a spec and especially for the late-stage > of a -bis effort. Dave, In case it was not clear, I agree (with the possible exception that, if it were a year or two earlier in the process, I might be a little more inclined to play with the text... but it isn't). And, of course, my last suggestion of just deferring dealing with this until the time comes that it can and should be addressed as a single-purpose topic in a relevant context is also consistent with your comments above. However, I am hoping that we can come away from next week's EMAILCORE meetings with a very clear plan about what I should put into the document going forward and how we are going to explain to the IESG about what we decide to not do (and convince them). That leads me, where possible, to want to explore possibilities in sufficient depth that if the WG decides to dig into, e.g., this topic about TURN, we know where to start the conversation that comes next and do so efficiently. My personal preference is that the WG looks at this ticket (and several others) and says, based on any combination of your questions and logic and my explorations/speculations, "no change needed, move on" leaving just enough tracks that Alexey (as both co-chair and document shepherd) can put together a sufficient explanation that the IESG won't send us back to the proverbial drawing board. Does that make sense? john -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
