On Fri March 4 2005 19:16, John C Klensin wrote: > 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. As separately detailed, there are no burdens placed on any clients; a client would not be required to implement recognition of the proposed ESMTP keyword(s). In the absence of any client implementation (or if implemented but ignored) the submit server would be free to make modifications as is now the case by virtue of the administrator whispering "this is a submit server" inside an anechoic chamber. The difference is that there would be a provision which would provide a clear differentiation of a submit server from an MTA; a differentiation which has been claimed to exist but which can be found nowhere in RFC 2476 or its draft successor. > At this > stage, you are talking about what would, in essence, be a whole > new protocol design. No, it's merely an ESMTP keyword. It provides a "deterministic means" of identifying a submission server; that was the intent of the ESMTP keyword -- additional verbs provide for control of munging by client-server negotiation which arose later in our dialog. > 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. As discussed, the "deterministic means" claimed in the draft for identifying submission seems to be lacking (a.k.a. "broken"). I have no problem in developing either a draft or text that could be incorporated in a future revision of the draft under discussion (I note that a -01 version has already been produced). If separate from the 2476 successor, that should probably happen in an IETF WG, but I see no active WG for such work. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf