Bruce,
I'm going to try to respond to this note as a courtesy, but we
may need to agree to disagree. 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.
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.
More below.
--On Friday, 18 February, 2005 08:32 -0500 Bruce Lilly
<blilly(_at_)erols(_dot_)com> wrote:
...
One bit of uneasiness is that I'm not convinced that there
really is something that SMTP clients can't supply which is
vital to the message format [aside from cases of "the user
is computer-illiterate and hasn't set the time zone" or some
such thing]. 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. 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 of a
handy and important case not covered by your narrow reading is
covered by the following scenario:
RFC 2821 essentially requires that the addresses in Received
fields be public ones (if that isn't clear enough, it is a
problem in 2821, not 2476). It also encourages, but does not
require, that the SMTP-ish client on the client machine put in a
trace field, a practice that has become reasonably common since
we clarified that the "Date:" header field was expected to
reflect the composition date-time, not the queuing/sending
date-time. Many of those organizations that are using private
address space on their LANs, or who are using public addresses
but don't want to expose their topologies, want internal client
addresses to be hidden from public view. It is rational for a
submission server to alter trace fields other than the ones it
inserts to substitute public addresses for private one or
generic addresses for internal LAN addresses that are considered
sensitive. A conventional SMTP server is forbidden to tamper
with earlier trace fields unless a convoluted "gateway" argument
is made for it, and we have discussed that situation already.
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. I, personally, don't
think
Virus-scan: Found to be clean, pure, and in a state of grace
doesn't pass a laugh test, at least in the absence of some
serious digital signature and trust structure action. If such a
thing came up for standardization, I'd join the rush to make
sure there was a security considerations section that identified
all of the ways malware could invade a message after such a
statement were attached, how the statement itself could be
inserted by malware, and so on. But people do seem to want to
put them in, they are certainly valid under the relevant specs,
and it might well make more sense to do the work in a submission
server than in an originating MUA.
Note also the discussion in section 8 of 2476.
All other message header fields are optional [RFC 2822], and
tampering with the SMTP envelope does not affect the message
format content (at least not directly; at final delivery the
SMTP envelope return path gets inserted in a Return-Path trace
header field).
Even here, there are exceptions, some of which are explicitly
identified in 2476. I've never been happy with the idea, but
there are many MUAs who either don't have a clue about their own
domain names or that are configured to use an abbreviated-form
domain name, or no domain name at all, on mail that is local to
the MUA's environment. Virtually every MTA I've seen has
provision for a "default domain" to deal with this problem. But
that situation implies that mail may leave the desktop with
MAIL FROM:<foo>
RCPT TO:<bar(_at_)baz>
...
From: foo
To: bar(_at_)baz
and it is required, to meet the requirements of 2821 and 2822
(and 821 and 822) that these pairs of envelope and header fields
be altered to reflect foo(_at_)default(_dot_)domain and
bar(_at_)baz(_dot_)default(_dot_)domain or some other set of FQDNs. Note that
this case is explicitly called out as a requirement in section
4.2 of 2476.
Now I can understand that administrators might
like to enforce policy w.r.t. use of host names under a domain,
etc., but that's a very different matter from "needed but can't
be supplied" (paraphrasing).
But your narrow reading that produces "needed but can't be
defined" is not what the spec says, or has ever said.
If the issue is really about
administrative fiddling with message content to centrally
enforce policy (rather than have policy enacted at the client
-- which certainly does not appear to be impossible), then say
so instead of using purported client inability as a
justification. [then we can move on to discussion of the real
issue, ACAP, DHCP parameters and extensions, etc.]
Bruce, I personally find it extremely frustrating, both
philosophically and in terms of impact on my own work habits
that IMSP, ACAP, or some member of that family isn't widely
deployed and used. I also find it frustrating that, while it is
possible to pass SMTP-related information to clients via DHCP,
neither the IETF nor most operating system vendors have provided
a safe, convenient, and reasonably standardized way of picking
that information up. As has been discussed on this list before,
the number of contexts from which a mail client might want to
identify with for finding that information is also problematic.
I wish there were no incompetent MUAs, running on incompetent
operating systems out there. And I wish that ISPs, claiming (or
perhaps believing) that it will prevent spam, have decided to
block outgoing SMTP to private servers, even when the traffic is
authenticated. But none of those are, to me, "the real issue"
and maybe that difference in opinion is why we are disagreeing
here. If the purpose of this discussion, of "Submit", or of
IETF in general involved designing for a next-generation
Internet, all of whose implementations were perfect and in
conformance with our preferences and biases, then the issues
above would be "the real issue".
But, instead, I contend that the "real issues" all have to do
with making things work well, or at least better, taking
behavior of implementations in the wild as a given. In that
"real issues in the real world" context, ACAP isn't a "real
issue", it is irrelevant because we can't seem to get it
deployed. DHCP isn't a "real issue" in a mail client
configuration context, but is irrelevant because the mail
clients can generally not get to the information with an
acceptable level of work and security -- perhaps sometime, but
not so far.
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. In the real world, those are
real issues, and the Message Submission Protocol has proven to
be a useful tool. In some idealized, fantasy, world of perfect
clients, perfect operating systems, no security treats, and a
better network-wide understanding of naming and addressing
constraints and issues, we probably wouldn't need it. But I
don't see us living in that world, no matter how much we might
wish for it.
...
How to authorize message-tampering via ESMTP in 3 easy steps
(some detail omitted):
1. server offers TAMPER extension in response to EHLO
2. client indicates acceptance of TAMPER option (separate
command or argument; as promised, I have omitted details :-)
or not, as the case may be (if the client does nothing,
tampering is not authorized).
3. server tampers if authorized; does not tamper if not
authorized.
That seems almost too easy; what have I missed (aside from the
details)?
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). 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.
"Message Submission" ("Submit" below) is
obviously different: we allowed for extensions to be used with
Submit that are not specified for SMTP (even though no one has
done that -- the mechanism has been shown to work with
extensions that are also specified for SMTP)
I'm a bit baffled by that as I can see no ESMTP extension
specified or referenced by RFC 2476 or the draft which does
not also apply to SMTP. The converse is true (but irrelevant);
ETRN, for example, can be used with SMTP but is forbidden by
RFC 2476 with an MSA.
That is correct. 2476 only specifies that the extension
mechanism be supported and requires support for some existing
SMTP extensions. We couldn't very well specify extensions no
one had thought of yet and made the decision to not belabor that
point.
It's also unclear what "mechanism" you refer to...
The [E]SMTP extension mechanism.
It seems like the hypothetical "TAMPER" extension (if not
permitted for non-submission SMTP) would do what is described
above (and shortly below) as desired...
Not really, for the reasons above. 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.
I think maybe that is enough... I've got to get to a meeting.
best,
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf