[Emailcore] rfc5321bis, Ticket #60, Restricted-capability clients

[John C Klensin <[e-mail]>]

Hi.  In the hope of getting things moving again (and noting that
the number of messages posted about rfc5321bis since the day of
the plenary appears to be zero), I thought I might have a go at
this.  

I went back to my notes to try to be sure of what we were
talking about when the text went into the spec.  The first part
of the story comes from there: the term is in 2821 and, modulo
the "submission server" issue (and noting that RFC 2476, the
first "message submission" spec was published before 2821), it
is unclear why questions about it didn't come up until now if
they are important to spend significant time on.  While I
believe the relevant text could, and should, be more clear, that
history does make an argument that leaving text alone that has
been unchanged for 21 years and never produced significant
complaints until now would be unlikely to cause major harm.
However, we did change it (see below) and that made it worse.

For additional context, most of the discussions about that term
have appeared to assume that it is used without context.  That
was not the case in 2821 and 5321.  The text in both 2821 and
5321 comes from a paragraph that starts out talking about
<forward-path>s and source routes.  It may be worth going back
and reviewing the whole paragraph (part of Section 3.3 of RFC
5321) but the specific "restricted-capability" text reads:

	"These restrictions make a server useless as a relay for
	clients that do not support full SMTP functionality.
	Consequently, restricted-capability clients MUST NOT
	assume that any SMTP server on the Internet can be used
	as their mail processing (relaying) site."

In the process of trying to straighten out and shorten the text
about source routes, I moved and rewrote that sentence and its
context to read:

	"Historically, the <forward-path> was permitted to
	contain a source routing list of hosts and the
	destination mailbox; however, source routes are now
	deprecated (see Appendix F.2).  Restricted-capability
	clients MUST NOT assume that any SMTP server on the
	Internet can be used as their mail processing (relaying)
	site."

Conclusion #1: That change, and how I did it, made whatever
problems that may or may not have existed worse.  I obviously
bear the responsibility for not getting it right, but some of
the cause was the WG decision to try to clear all discussion of
source routes out of the document and that should be treated as
a lesson.

Another issue is that this is one of the places where the
"client", rather than "sender-SMTP", terminology does not help
with clarity.

Now, the requested explanation:

A restricted-capability client (sender-SMTP) is one that does
not support "full SMTP capability".  That includes the ability
to use MX records and maintain message queues and retrying as
specified in the spec.   I haven't tried to think through other
possible restrictions but those two are obvious.  Remembering
that we did wrote RFCs 2476, 4409, and 6409 on the assumption
that the "submission server" was a host that would send messages
outward as either a fully-conforming sender-SMTP or, perhaps, to
a "forwarder" relay that was itself a fully-conforming
receiver-SMTP and then sender-SMTP (rereading RFC 6409, it is
probably not be as clear about that as it should be but that is
out of scope for the current discussion).  In terms of the code
used, it might receive those messages either as a
slight-restricted receiver-SMTP (on port 587 or 25) or by a
variety of other means, but that is not our problem today
either.  There are no provisions there for relaying messages
around through a collection of systems. 

So, some example "restricted-capability" sender-SMTPs might
include:

 * The sender-SMTP side of an RFC 6409-conforming
	submission server that forwarded to a relay rather than
	maintaining its own queues.  As hinted above, 6409 does
	not appear to discuss the operation of the sender side
	of an MSA host.
	
 * An intra-enterprise host to which submission servers
	forward messages but that does not, itself, maintain
	queuing or MX processing but, instead, forwards to
	another, presumably intra-enterprise host that supports
	those functions and interfaces with the rest of
	Internet.  It might or might not route messages to
	destinations within the enterprise, presumably using
	internal DNS arrangements or some other (outside the
	spec) mechanism.
	
 * A national or regional host in an area with poor or
	intermittent connectivity that might handle intra-area
	traffic normally but that routes traffic for external
	Internet destinations to a common host for processing
	and, as needed, queuing etc.  FWIW, such "poor or
	intermittent connectivity" environments might easily
	include the Mars (or even the moon), where the
	advantages of transmitting messages to a host acting as
	an interplanetary gateway -- a host that would be
	completely unknown to an arbitrary destination host
	earthside (and hence would not appear in its MX list).

In each of these cases, the sender-SMTP knows which host or
hosts the message should be sent to because that information is
somehow configured in, not because of the MX mechanism and that
is at least part of what makes it, operationally,
"restricted-capability".

So, options (not mutually exclusive except for the first):

(1) Leave the current text alone and move on.  I _do not_
recommend this.

(2) Leave the current text alone but come up with better
terminology and/or get the relevant sentence(s) far away from
any sentence that mentions source routes.  Any suggestions for
better terminology should include one or more proposed terms.
Suggestions about moving it would be more welcome if they
included a suggestion about where to.

(3) Insert a significant portion of  the above, possibly
rewritten, to explain and illustrate what we are talking about.
An abridged version would be fine too if people want to suggest
what might be trimmed.

(4) Revert the attempt to clean out source route-related
language to the language and organization of 5321 on the
assumption that, if the move created this problem, it is likely
to have created others as well.

I await comments, injections of wisdom, and other responses.

    john


(3)