Bruce, fwiw, this general approach was discussed when this protocol was first being designed. 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. 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. john --On Wednesday, 02 March, 2005 15:15 -0500 Bruce Lilly <blilly@xxxxxxxxx> wrote: >... > There's another fairly simple way to handle the situation; a > "submit" server could offer an extension keyword (or multiple > keywords) that identify the types of modifications it will > perform in the absence of direction to the contrary by the > client. The keywords would be defined solely for "submit" > use, so a client encountering any of them would be able to > identify the "submit" protocol. If none are offered, then > either the server is an SMTP MTA, or won't modify the message > content (in which case it is acting as an SMTP MTA (should)). > Corresponding verbs would allow a client to direct the MSA > to disable certain modifications. Some observations: > 1. legacy clients not supporting recognition of the extension > keywords won't be able to distinguish ESMTP from "submit". > Same as now. But future client development could take that > information into account. > 2. legacy clients would not be able to direct the MSA not to > apply some modifications. Same as now, but again, future > clients could benefit. Such clients would be able to > determine -- in advance -- what sort of modifications > would be performed, and could either negotiate application > of those modifications (e.g. "no, I don't want you to > alter 'foo.com' in the address fields, that's what I mean, > not 'foo.com.bar.org'") or terminate the session. > 3. If a session is initiated with HELO, the extension > mechanisms would be unavailable. Ergo, a client would > be unable to determine if the server is an MSA or MTA > (same as now). MOral: if the client needs to know, let > it speak ESMTP. > 4. It might even be reasonable to disallow HELO on port 587. > 5. The verbs corresponding to the "submit" extension keywords > would be disallowed to MTAs acting as clients (though I > can imagine a sort of split gateway where some non-SMTP > transport might make use of an MSA to do part of the > translation work, so maybe there should be an exemption > to allow for that). _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf