Subject: Re: Last Call: 'Message Submission' to Draft Standard

From: Bruce Lilly <[email-masked]>
Date: Fri, 18 Feb 2005 08:32:19 -0500

>  Date: 2005-02-16 01:14
>  From: John C Klensin <[email-masked]>

First let me say that in principle separating MSAs from MTAs
does not seem unreasonable (on the other hand, I don't believe
the distinction is clear from a protocol view), and that I can't
forsee any huge amount of damage that could arise from RFC 2476
or the draft revision.  Nevertheless, I am uneasy about some of
the content and some of the statements about 2476 vs. ESMTP, and
I have some procedural uncertainties about migration to Draft
Standard status given lack of clarity about the distinction
noted above and the unclear state of implementation conformance.

> Bruce, if I understand your concern (I may not), let's back up a
> bit and look at a bit of history and the usage case.  The notion
> of a separate submission protocol arose in part out of a problem
> that became clear when we were doing 2821.  There were a whole
> series of things that we would really prefer that MTAs not do
> --things that violated the "don't mess with the message"
> meta-principle for MTAs but were necessary because clients
> weren't able to supply all of the information needed for a valid
> 2822/822 message, or weren't able to supply it in a form that
> would be security-acceptable.  So, to face the reality of the
> fact that these MTA-fixes were being applied (and were
> necessary), 2821 contains a loophole for submission servers to
> fix messages up.

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
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).  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). 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.]

The two specific mandatory fields listed above aren't particularly
strong cases in favor of message munging; a case can be made that
the From field should be optional (draft-lilly-from-optional),
and the Date field plays absolutely no role in protocol other
than end-to-end, user-to-user information (moreover the semantics
are specified as being the time of message *creation*, not of
message *submission* for transport).

> That loophole is, however, somewhat bad news, since it doesn't
> involve explicit client authorization for message-tampering and
> there is no real way to permit such authorization even if one
> wanted to do 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)?

> "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.

It's also unclear what "mechanism" you refer to...

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...

> and the mere fact 
> of using the Submit protocol says "this is a submission agent,
> not a general MTA, and hence gets to use those features".

The description as a separate protocol is also a bit baffling,
as 2476 and the draft state "The protocol used is ESMTP", i.e.
the same as specified in 2821.  Moreover, if I connect to an
MSA on port 25 (which is explicitly permitted), there is
nothing in the greeting reply code or EHLO extended response
that indicates that a server is an MSA (conversely, as noted
above, if ETRN is offered, clearly the server is not (supposed
to be) an MSA).  So where exactly is the supposed indication
in the protocol that "says 'this is a submission agent'"?

What I seem to be reading is that there really isn't any
indication in the protocol; the administrator of an SMTP
server waves an imaginary magic wand and utters (very quietly)
the incantation "this is a submission agent", unbeknownst to
the client or the message originator, and if that happens,
then any of the message munging that would be a no-no without
the incantation is now magically OK.  Please tell me what
subtlety I missed that makes that not so.  [No disrespect to
you, your co-author, or the submit group intended -- I'm
really baffled by the apparent magic (or smoke-and-mirrors
if you prefer) that seems to be implied.]

> But, if it is run on port 25, the question
> immediately arises as to how you tell it from SMTP, since the
> two are deliberately quite similar in their handshakes.

"similar" (as opposed to "identical" implies some significant
difference.  I can find none to point to that specifically
identifies submission.  Even with no provision for client
control (aside from QUIT), there could be a difference
simply by defining an EHLO keyword (let's see 1869 - letters,
digits, hyphens, no maximum length) e.g.
this-is-a-submission-agent-not-a-general-MTA-and-hence-gets-to-mangle-content
and requiring its use for submission agents and prohibiting it
for MTAs.  However, I see nothing even as simple as that (i.e.
just a machine-parseable announcement w/o corresponding feedback)
that truly defines "submit" as a (trivially) *different*
protocol from ESMTP.  I submit (no pun intended) that lacking
such a differentiating protocol difference claims that the
protocol is different are misguided.  Mind you, with such a
trivial difference, I would call it a minor variant on a
single protocol rather than a different protocol.

> The 
> answer is "administrative or policy decision, reflected in
> configurations".

But that doesn't tell *me* (as the client connecting to that
server) whether it is "ESMTP" or "Submit" (which we're told *is*
ESMTP).  Sure, the administrator of the server (supposedly) knows,
but so what?  If I (as the client) can't tell which (variant of)
protocol the server is running, then I can't make sense of the
response codes, especially where the semantics differ (as with
5.6.2).

> > My understanding is that implementations are permitted to have
> > configuration options that allow sites to deploy them in ways
> > that violate the RFCs, as long as they can be operated in a
> > conforming manner.  For example, it is not uncommon for POP
> > implementations to have options to have timeouts shorter than
> > mandated, or to enter UPDATE state on abort.
> 
> This has always been the rule, at least since we decided that
> specifications, to advance to draft, must exhibit implementation
> of all of the features.

I don't want to get too bogged down, but I'm concerned about
a specific subset of violations, where (as in this case):
1. there is an RFC 2119 "MUST" or "MUST NOT" provision. Recall that
   a 2119 MUST [NOT] is only supposed to be used where a violation
   would cause harm or where the feature is necessary for
   interoperation (RFC 2119 section 6).
2. implementations can be operated in such a way as to violate
   said provision.
Note that I'm not referring to a "SHOULD".  My conclusion is that
the implementation in question can be configured in such a way
as to cause harm (e.g. initiate DoS attacks (where "attack" may
include behavior on the part of the implementation which is not
intentional on the part of the administrator) and/or result in
failure of interoperation, possibly including excessive numbers
of retransmissions, etc.), or that there is an error in the
specification (inappropriate use of 2119 imperatives). I can't
imagine that we'd want to encourage the former, and in the latter
case, the error in the specification should be corrected.

> We don't do code review to verify 
> conformance and spot possibly-non-conforming capabilities.

There is supposed to be "testing of the interoperation of [...]
implementations" (RFC 2026 section 4.1.2).  Code review is not
specifically required, and might not be possible for proprietary
implementations.  Nor is it necessary for interoperation testing;
just see how the implementations behave.  Black-box testing is
hardly a novel concept.

> The 
> rule is that the implementations must be able to demonstrate
> that they can be configured in a way that conforms to the spec.

The full specification, presumably, not just parts of it.

> > From my understanding of the requirements, there are multiple
> > implementations which comply.  This is based on two points:
> > (1) implementations can be compliant even if they have options
> > which permit non-conformance; and (2) there must be at least
> > two implementations for each feature, but it is not required
> > that any individual implementation meet every SHOULD.  I
> > believe Message Submission meets the criteria on the basis of
> > either of these points; the fact that it meets it on both is
> > nice but not required.
> 
> Under other circumstances, I might actually quibble about (2),
> but (1) is the important point.

As I mentioned, I don't want to get bogged down on the first point;
I hope I have made my concerns clear above.

The second point is also important, and relates to the rationale
behind the RFC 2026 sect. 4.1.2 "requirement for at least two
independent and interoperable implementations [which] applies to
all of the options and features of the specification". Now I
can think of two reasons for such a requirement:
1. to ensure interoperability, which is the point of having
   standards in the first place. In support of the interpretation
   I note that 2026 goes on to state that a Draft standard is
   considered to be a final specification and that it is reasonable
   to deploy (conforming) implementations in disruption-sensitive
   environments.  One certainly would not want to deploy
   implementations in a disruption-sensitive environment if
   serious (i.e. warranting RFC 2119 imperatives) interoperability
   problems were known, nor would one wish to encourage
   implementation by vendors if the specification were unstable.
2. to winnow out unnecessary or unused features, which is implied
   by the remainder of the second paragraph of 2026 4.1.2.
Again, as before, my primary concern is with mandatory features
(MUST/MUST NOT) rather than with less consequential matters.
The interoperability report lists many features and many
implementations; many feature/implementation pairs have unknown
status. In the interest of brevity, I'll consider a hypothetical
feature set of 3 features (numbered 1-3) and three implementations
indicated by letters A, B, and C.  Implementation A supports
features 1 and 3, B supports 2 and 3, C supports 1 and 2. While
one can list two implementations in this hypothetical example which
support each of the features separately, one cannot list any two
implementations which are interoperable with respect to "all of
the options and features".  Implementation A will not interoperate
with implementation B because the former lacks support for feature
2 and the latter lacks support for feature 1.  Likewise for (lack
of) interoperability between A and C and between B and C.  What
are the implications for the two possible reasons for the 4.1.2
requirements enumerated above?

Clearly interoperability doesn't exist w.r.t. all of the features.

It's not clear what the implications are w.r.t. necessity or
utility of features; clearly one implementer can be found who
believes that any given feature is either unnecessary or otherwise
not worth implementing. However, one can find at least two
implementers who support any individual feature. Most important,
though, is the fact that none of the implementers in this
hypothetical example support "all of the options and features of
the specification"; consequently one cannot enumerate two 
implementations which do so.

Returning to the case at hand, the question w.r.t. the 2026 4.1.2
implementation requirement, as I see it, is: "can one list two
implementations which support all of the mandatory features of the
specification?".  If there are more than two which support all of
the features, that's a bonus.  But listing a dozen implementations,
each of which supports a couple of features (but not all features)
doesn't answer that question, and doesn't fill me with confidence
that there are any fully interoperable implementations (w.r.t. all
features) or that unnecessary features have been trimmed from the
specification.

[re. extended response code discrepancies]
> To the extent to which this is an issue, it is an issue with RFC
> 3463 and not with this draft.

I disagree. RFC 3463 (nee 1893) defined the extended response
codes and was specified as a reference. There are defined
response codes to cover the situation(s) addressed by 2476
and the draft (though those are not used), and at least one
code is used in a way which conflicts with the (original)
definition.

> A real problem would arise only 
> in the "both protocols, same machine, port 25" case described
> above.

I believe it also applies to the case "I have no way to determine
whether or not the server is a 'submission' server; it responded
with 5.6.2 -- is that supposed to mean 'conversion required and
prohibited' or 'bad domain or address', and what do I (as the
client) present to the user (who might not understand English)?".

> But I agree with Randy -- the right action is to delete 
> the specific codes from this specification and leave that to
> 1893, 3463, and their successors.

I believe there's an identity crisis that needs to be resolved;
if the protocol is just some minor variant of ESMTP, as implied
by the statement in section 3.1, then
a. the response codes should be consistent with ESMTP except in
   specific enumerated cases where some difference is warranted;
   it may suffice to state explicitly that codes are the same
   except for enumerated differences (giving 2821 as a normative
   reference).
b. we should refer to it as a variant of ESMTP rather than as some
   wholly distinct protocol
Conversely, if it is in fact intended to be a wholly distinct
protocol from ESMTP, section 3.1 should be reworded to accurately
portray that and specific responses should be enumerated for each
command -- including positive responses and temporary failure
responses.

I don't think sweeping the problem under the rug by simply not
mentioning response codes is appropriate for a document that is
intended to be "considered to be a final specification" and
"well-understood".

> For example, assume that one has a
> submission client on a private network using 1918 space.

OK (I'm typing on one).

> It 
> submits the message to an MSA which lies at the NAT boundary
> between that network and the public Internet.

Nope. The MSA in this case is on the inside of the firewall
which provides NAT.  I wouldn't want to run an SMTP server
(submit or otherwise) *on* a firewall given the history of
security vulnerabilities in various implementations of SMTP,
not to mention the possibilities for DoS attacks.  Nor do I
trust firewall appliance vendors to implement plain vanilla
SMTP correctly (I know for a fact from experience that some
fail to do so), much less a particular variant of SMTP.  Because
the MSA is on the inside, it also has a 1918 IP address (in
my specific case, it happens to be the same machine as the
client, which it knows as 127.0.0.1).

Now I suppose there might be another MSA on the outside of
the firewall (the next step uses ESMTP with AUTH on port 25,
but I have have no way of knowing what incantations its
administrator might have muttered :-), but neither 2476 nor
the draft mentions anything about multiple MSAs in the transport
path. [Patrik Faltstrom's diagram at
http://www.ripe.net/ripe/meetings/ripe-47/mailflows.pdf
might be illustrative of how complex such paths can be]

> To meet the 
> requirements of 2821, the MSA (or submission MTA) should modify
> or supplement addresses and internal names so that they reflect
> public names and addresses.

In the SMTP envelope? Sure; no problem.  I wouldn't expect
domain literals (the 1918 issue) there in the first place,
though.

In the message content? Big problems.
1. Verboten for Received fields already in the message.  You
   want to treat Received fields specially?  Now you need a
   full-blown message parser.
2. No need for change to address fields (message is unreplyable
   if mailbox(es) in from or address(es) in Reply-To are
   broken, and the client has a better chance of getting those
   right (closer to the user) than some remote MSA. The Sender
   field is irrelevant, and in any case need not be replyable.
   To and Cc fields likewise are best set by the client and
   left untouched by transport.  Modification would also be a
   layer violation; the header fields are specifically for
   user-to-user, end-to-end communication, not for transport.
   About the only thing that might be OK is handling Bcc
   fields, but that really should be handled by the client in
   conjunction with the SMTP "envelope" transaction(s).
3. What happens when somebody invents a new address field?
   The client that generates a field clearly knows about it.
   But who is going to update all of the SMTP (oops, "submit")
   servers around the world to start mangling that field, too?
4. What happens when somebody (Hi, Carl) invents a field that
   uses domain-name-like constructs but in an odd arrangement
   (RFC 3865)? 
5. The only RFC 2821 requirement[s] that I see that is relevant
   specifically applies only to gateways...

> That moves it into gateway 
> territory,

Circular argument detected; "I modify the message" therefore
"I am a gateway" therefore "RFC 2821 permits/requires me to modify
the message".  I don't buy it.

> and 2821 was written to permit that case (doesn't 
> make that I, or the DRUMS WG, liked the case very much, but it
> reflects reality).

The dislike (speaking for myself) has to do with unnecessary
and therfore undesirable layering violations.  A *real* gateway,
where there is a drastic change in network conventions, such that
necessitates (reversible) transformations for end-to-end
functionality to operate, is another matter [even so, there's
still those nasty "what happens when..." #3 & #4 above].

> >>>  It is not the intent of either this draft or RFC 2476 to
> >>>  say that MSAs are always gateways; rather, the intent in
> >>>  both is to recognize the reality that organizations
> >>>  sometimes see a need to examine and potentially modify
> >>>  messages submitted using their servers,

"Desire" != "need". (truth in advertising, please) If there
were no layering violation involved, I would ask what
interoperability or harm-prevention issues constitute such
a "need".  Given the layering violation, I would expect any
such issues to be very clear and subject to intense scrutiny.
[hint: "we want to hide host names at the edge because we're
too lazy to properly configure clients and we truly believe
that obscurity equals security" doesn't pass the sniff test]
At minimum, the consequences in terms of network damage or
serious interoperability problems associated with not mangling
content would have to be quite serious to justify the layering
violation of fiddling around with ser-level content.

> >>>  and to make a clear 
> >>>  distinction between this case, and the
> >>>  examination/modification of messages being relayed.

Given the inability for a client to detect and/or control
the situation on behalf of the user initiating the message
(as detailed above), I don't see that there is "a clear
distinction".  The message is being relayed by exactly the
same store-and-forward mechanism used by MTAs, and provides
exactly the same (non-)information and (lack of) control
to/by the message originator regarding examination/modification.

> Bruce, you are assuming, I think, that every MSA must be
> conformant to the MTA requirements of 2821 (gateway or not).
> That was never intended to be the case.  Indeed, that is part of
> the reason why this is a separate protocol (i.e., the "clear
> distinction" to which Randy refers to above).

See my "identity crisis" remarks above.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Tue, 22 Feb 2005 08:35:41 -0500

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
<[email-masked]> wrote:

>...

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.

> 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@baz>
    ...
    From: foo
    To:   bar@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 [email-masked] and
[email-masked] 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
> 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.

>...

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.  

> ETRN, for example, can be used with SMTP but is forbidden by

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.

> 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