Bruce, fwiw, this general approach was discussed when this
protocol was first being designed.
Not only was it discussed, the draft actually specified this scheme at one
point.
It was overwhelmingly rejected by the participants at the time and removed.
I can't remember all of the
reasons why it was rejected, but at least one of them was that
we didn't want to put unreasonable burdens on clients.
The problem in a nutshell was that it required client modifications. It is one
thing to configure clients to use a different port for submission, another
thing entirely for them to add support for a new SMTP extension.
I actually was somewhat in favor of the extension at the time. And while it is
difficult to say what would have happened had the extension approach been
taken, the overwhelming success of the approach that was finally used argues
strongly that I was wrong and the correct choice was made.
At this
stage, you are talking about what would, in essence, be a whole
new protocol design. For that, I think you are going to need
both a draft (not an email note with an outline of what you
would like to see in principle) and a compelling reason to undo
or change what, operationally, does not appear to be broken.
I see no evidence of any operational reason, let alone a
compelling one, to make this sort of change at this point.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf