On Mon, 28 Oct 2024, John R. Levine wrote:
I would have hoped we would agree that we do not want to make breaking changes to a widely deployed 40 year old protocol. While it is true that most mail over the public Internet uses STARTTLS, you and I do not know all of the places SMTP is used, it's always been an optional feature, and we at least used to give lip service to maintaining interoperability.
This seems like the same arguments that could be used for telnet, ftp and rcp. I don't see us doing a bis document for ftp. I think the IETF is a fine place to start saying "you better start adding TLS now or soon you might see SMTP failures". If the IETF doesn't do this gentle push, the same people will eventually end up severely broken when either a widely used SMTP service or commonly deployed SMTP software decides to flip the switch to mandate TLS (be it opportunistically or authenticated). For example, postfix in fedora/rhel already installs with a selfsigned cert to do TLS for what? two decades? SMTP without TLS is living on borrowed time. The security consideration of "you better do TLS" is also not a "breaking change".
But they are all optional extensions, not part of SMTP, which is why I don't want them cluttering up the SMTP spec.
These extensions are "optional" as much as Paul@xxxxxxxxx and paul@xxxxxxxxx are optionally mailboxes belonging to different entities :P If we update an RFC, we should attempt to reflect reality and not hold on to things overtaken by events. Paul -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
