Date: 2005-02-22 08:35
From: John C Klensin <john-ietf(_at_)jck(_dot_)com>
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf