> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf