Dave Crocker wrote in <373ab2bd-47ac-49a3-992d-2a3095e9ba29@xxxxxxxxxxxx>: |On 10/30/2024 10:02 AM, Rob Sayre wrote: |> I think the WG could agree to briefly describe STARTTLS and get on |> with it. | |The protocol SMTP provides no facilities for privacy or security. And |the nature of the task it does does not inherently require any. So, it |will function just fine without either. | |That is, nothing about privacy or security for SMTP, the protocol, |requires a MUST. Or even a Should. | |It does support extensions that can be announced and might provide |privacy or security enhancements. But these are not part of SMTP, per se. I speak against this as per se SMTP is a network protocol. It uses TCP. "Network protocol" has evolved in practice regarding encryption. Some newer IETF protocols are even available in only encrypted form (i think). It is only natural that an evolved SMTP protocol description includes references to encryption. That is of course my personal opinion only. I recognize that SMTP does not standardize all the authorization options even though it knows about users per se. |And the document in question, here, is SMTP, not the entire world of |email or even the entire world of email handling. | |So the concern, here, is about best practices for using /associated/ |privacy/security technologies in many/most environments -- with some |lobbying to claim that it is needed in absolutely, positively, all |environments, no matter the cost or inconvenience, including to the |installed base. | |Here, too, a MUST is problematic, because, as has been noted, installed |base. | |For SMTP over the open Internet, the fact that usage involves |interactions with other, independent parties justifies being quite |forceful about protection mechanisms, because it is not just the single |operator of SMTP that is affected by problems. But note the context. |Which sounds like the scope of an A/S, not a protocol specification. As an outsider and implementor this sounds very strange. It is true i need to collect several RFCs in order to be able to use SMTP as such, but other email protocols do. Moreover, dear all, the submission protocol as of RFC 6409, and that is nothing but a dedicated subset of SMTP, knows about all that. And moreover moreover, for submission there is also a SRV DNS entry defined to discover server capabilities. Therefore i say |A view that something is easy to add to a spec is wonderfully appealing, |especially when accompanied by dismissal of concerns about... installed |base. For matters affecting clear and present dangers, such dismissal |not only make sense; it is required. So, for example, mandating TLS |over the open Internet can make sense. But in the privacy of your own |home (network)? hmmm. | |to include in the intended A/S, and none of it pertains to the technical |specification of SMTP's base document. that i cannot understand this. It is splitting hairs. It is continuing the completely non-understandable mistreatment (yes, let me name it like that) of SMTP in the IETF / email universe. "Micky Mouse has grown up a cow", and .. SMTP is just the same. The IETF should "streamline" also SMTP, and make it easily accessible to developers again, and very easily usable for normal persons, as email should be easy. (And do not send me XML status reports please. Just bounce it.) --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) | |And in Fall, feel "The Dropbear Bard"s ball(s). | |The banded bear |without a care, |Banged on himself fore'er and e'er | |Farewell, dear collar bear -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
