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

From: Bruce Lilly <[email-masked]>
Date: Wed, 2 Mar 2005 15:15:00 -0500

>  Date: 2005-02-22 08:35
>  From: John C Klensin <[email-masked]>

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: John C Klensin <[email-masked]>
Date: Fri, 04 Mar 2005 19:16:44 -0500

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

>...

---

From: [email-masked]
Date: Fri, 04 Mar 2005 19:43:01 -0800 (PST)

> protocol was first being designed.

Not only was it discussed, the draft actually specified this scheme at one
point.

It was overwhelmingly rejected by the participants at the time and removed.

> I can't remember all of the
> we didn't want to put unreasonable burdens on clients.

The problem in a nutshell was that it required client modifications. It is one
thing to configure clients to use a different port for submission, another
thing entirely for them to add support for a new SMTP extension.

I actually was somewhat in favor of the extension at the time. And while it is
difficult to say what would have happened had the extension approach been
taken, the overwhelming success of the approach that was finally used argues
strongly that I was wrong and the correct choice was made.

> At this

I see no evidence of any operational reason, let alone a
compelling one, to make this sort of change at this point.

			Ned

---

From: Bruce Lilly <[email-masked]>
Date: Fri, 4 Mar 2005 23:35:35 -0500

> The problem in a nutshell was that it required client modifications.

Ned, if I understand your remarks correctly, you are claiming that
the scheme that I outlined requires client modification.  That is
incorrect, though w/o modification, operation would be as is currently
the case (i.e. the scheme is intended to be backward compatible) with
RFC 2476 (client can't distinguish whether server is MTA or MSA, has
no control over modifications, etc.).  Could you please explain
specifically where you believe that the scheme outlined *requires*
client modification.

---

From: [email-masked]
Date: Fri, 04 Mar 2005 21:58:14 -0800 (PST)

> specifically where you believe that the scheme outlined *requires*

OK, fine, it doesn't *require* client modification, but client modification is
necessary for the scheme to offer much benefit.

It's still a solution looking for a problem.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Sat, 05 Mar 2005 01:50:40 -0500

--On Friday, 04 March, 2005 23:35 -0500 Bruce Lilly
<[email-masked]> wrote:

>> Not only was it discussed, the draft actually specified this
>> scheme at one point.
> 
> Ned, if I understand your remarks correctly, you are claiming
> that the scheme that I outlined requires client modification.
> That is incorrect, though w/o modification, operation would be
> as is currently the case (i.e. the scheme is intended to be
> backward compatible) with RFC 2476 (client can't distinguish
> whether server is MTA or MSA, has no control over
> modifications, etc.).  Could you please explain specifically
> where you believe that the scheme outlined *requires* client
> modification.

Bruce, 

Like Ned, I think history and deployment have voted and the
community doesn't see any need for this.   But suppose there is
such a need.  The change you propose is either compatible with
the protocol as written or it isn't.   If it isn't, then my
earlier comments apply.  If it is compatible, which is what you
say above, then it has nothing to do with whether the document
should move to Draft because nothing prevents you from doing a
writeup of the specific extension(s) you propose as an I-D and
see if you can get others, especially those who implement and
deploy these sorts of things, interested in adding those
extensions as a new Proposed Standard piece of protocol to be
optionally used with Message Submission.

  john

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 05 Mar 2005 14:22:30 +0100

Would there be an objection that netiquette calls to quote the Draft's URL 
when discussing a Draft, as when quoting and discussing any other document? 
The time wasted in finding discussed Drafts (and actually discussed 
version) probably make interest in them to drop and comments to be lost or 
never proposed.

Last Call: 'Message Submission' to Draft Standard  ...
Impending publication: draft-iab-dns-assumptions-02.txt
'Labels in Subject Headers Considered Ineffective At ...

are among the last drafts I would have been interested to review after some 
of the coments. If one cannot easily compare a comment with the proposed 
text, what is the interest of the text and of the comment?
jfc

---

From: Bruce Lilly <[email-masked]>
Date: Sun, 6 Mar 2005 14:47:27 -0500

> It's still a solution looking for a problem.

It's a rough outline of a possible solution to the problem
"there is no real way to permit [explicit client] authorization
[for message-tampering] even if one  wanted to do it".
That was not my statement of the problem.  However, that issue
is related to 2476 and its draft successor due to the assertion
that they [2476 and successor] are solutions to abuse of the
"gateway" provisions of 2821 which permit message tampering.

---

From: Bruce Lilly <[email-masked]>
Date: Sun, 6 Mar 2005 15:12:52 -0500

> we didn't want to put unreasonable burdens on clients.

As separately detailed, there are no burdens placed on any
clients; a client would not be required to implement recognition
of the proposed ESMTP keyword(s).  In the absence of any
client implementation (or if implemented but ignored) the
submit server would be free to make modifications as is now
the case by virtue of the administrator whispering "this is
a submit server" inside an anechoic chamber.  The difference
is that there would be a provision which would provide a
clear differentiation of a submit server from an MTA; a
differentiation which has been claimed to exist but which
can be found nowhere in RFC 2476 or its draft successor.

> new protocol design.

No, it's merely an ESMTP keyword.  It provides a "deterministic
means" of identifying a submission server; that was the intent
of the ESMTP keyword -- additional verbs provide for control
of munging by client-server negotiation which arose later in
our dialog.

> For that, I think you are going to need 

As discussed, the "deterministic means" claimed in the draft
for identifying submission seems to be lacking (a.k.a. "broken").

I have no problem in developing either a draft or text that
could be incorporated in a future revision of the draft
under discussion (I note that a -01 version has already
been produced).  If separate from the 2476 successor, that
should probably happen in an IETF WG, but I see no active
WG for such work.