> Date: 2005-02-22 08:35 > From: John C Klensin <john-ietf@xxxxxxx> Sorry for the delay in responding; I've been preoccupied with other matters. > The observation that a number of > implementers and ISPs/mail service vendors have chosen to adopt > the "Submit" model speaks far more loudly than either of our > opinions, at least unless we can make a strong "harmful to the > Internet" argument, which I note you haven't tried to do. The question is, what precisely is that model -- that relates to my concern regarding documentation of *fully* conforming implementations as required for advancement to Draft. > Moreover, for Draft Standard, it is not necessary to even > demonstrate usefulness or deployment --although I suggest that > Randy has documented both-- only the interoperable > implementations exist. ÂThe latter is a fairly objective > criterion, using rules about what counts and what does not that > we have been using for many years. ÂIf you don't like those > rules, that issue should probably be separated from 2476 and > taken, e.g., to newtrk. My understanding of the rules is that there must be a minimum of two independent and interoperable implementations, each of which implements *all* of the mandatory provisions of the specification. As far as I can tell, the documentation doesn't list two such implementations. > > As it stands, the items required by the message > > format which 2476 permits an MSA to alter are: > > 1. mandatory From header field > > 2. mandatory Date field > > That those are the only two fields that are permitted to be > modified is a misreading of the spec. That was not my assertion. Those are the only fields which are at present mandatory in the Internet Message Format. A client which cannot provide one of those is severely brain-damaged. > Please note, e.g., the > sentence "Even when submitted messages are complete, local > site policy may dictate that the message text be examined or > modified in some way." from the opening section (somewhat > mis-identified as "Abstract" of 2476. Â Just one example [...] > Similar comments could apply to a number of non-required, but > important (to someone), header fields, including just about > anything that knows or incorporates a domain name. ÂThat list > doesn't just include standardized fields. [...] > Note also the discussion in section 8 of 2476. Fine, but my point is that let's call it what it is -- mucking about with the content for administrative purposes -- rather than passing the buck by blaming the client: "the MUA may be unable to [...]". The only things that the MUA *has to* provide are the From and Date fields. > The Message Submission protocol is designed to provide a way > around those problems, one that works in the real world, escapes > some barriers that have been erected against SMTP, and that is > less harmful than having clients use SMTP for message submission > and having the associated SMTP servers invoke the "gateway rule" > to justify just about anything. But the protocol in 2476 and the draft *IS* [E]SMTP; the documents clearly say so. How is this *not* a case of smoke-and-mirrors as an alternative to that "gateway rule"; 'this is a (wink, wink) "submit" server', otherwise indistinguishable from an SMTP server, therfore "just about anything" is justified? > You have missed some ease of deployment issues (it takes a long > time to get an SMTP extension accepted into clients and client > authors resist needing fallback plans when a depended-upon > extension is not offered). A learning curve to deployment is a fact of life for a separate protocol, which is how "submit" is being positioned. > You have also missed the important > fact that the server cannot tell, in this case, whether the > client purports to be an MUA or is just another MTA. Â Simple; define it as being prohibited for use by the client side of an MTA. > There was, however, another > model for Submit itself in which the client would specify, via a > new verb, just exactly what message-diddling services it wanted > the server to perform. Â That has considerable elegance to it, > especially if one thinks of the MUA-MSA relationship as a > split-function MUA-MTA relationship rather than separate > functions. ÂBut it was just too complicated, especially in the > presence of real-world incompetent clients. Same (trivially-solved) issue as above; the server can't tell if the client is an MUA or MTA. 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