[Top] [All Lists]

Re: [ietf-smtp] Possible contribution to moving forward with RFC5321bis SMTP

2020-01-02 13:28:02
On 1/2/2020 10:17 AM, John C Klensin wrote:
   Whether we
change the spec to follow their practices or retain and clarify
the recommendation, it seems to me that we are going to need
text, somewhere, that explains our decisions, why we are giving
whatever advice we are providing, and why people should follow
that advice.  That text, which probably belongs in a separate
document from RFC531bis, may actually be more important than
whatever we put in 5321bis.

If it turns out to be more important than the actual protocol spec, we've got bigger problems.

But explanatory text certainly can be helpful. Here is is worth distinguishing text that explains utility of what is specified -- and one of the benefits of the IETF style of specification, as opposed to that of many other standards organization, is that such text can be inline with the spec -- versus discussion of group decision-making that produced the spec.

While production of this latter type of history review can be interesting, I'm not aware of that being a regular -- or even established? -- practice in the IETF.

I don't recall specific examples, but believe it has been done, though not very often. Perhaps you can cite some examples?

Absent our providing a persuasive
explanation of why people should, or should not, do something,
experience, both on the anti-spam side and based on continuing
references to 2821, suggests that sites will do whatever they
(locally) think best and that some of those decisions will be

Such explanation has pretty much never altered independent decision-making in the adoption or rejection of Internet mail practices. Perhaps you have counter-examples?

The same principle applies, IMO, to suggestions that we pull
material out of 5321 that is considered obsolete, irrelevant, or
not belonging there. Some of the arguments about what should be
included ultimately date from the 1980s and involve questions of
whether the envelope-message body (with headers) separation
arrived at then was correct, whether we should have placed more
reliance on message processing rather than transport processing
or vice versa, and so on.

The topic of the envelope received significant discussion during the development of RFC 5598:

4.1.  Message Data

   The purpose of the Message Handling System (MHS) is to exchange an
   IMF message object among participants [RFC5322].  All of its
   underlying mechanisms serve to deliver that message from its Author
   to its Recipients.  A message can be explicitly labeled as to its
   nature [RFC3458].

   A message comprises a transit-handling envelope and the message
   content.  The envelope contains information used by the MHS.  The
   content is divided into a structured header and the body.  The header
   comprises transit-handling trace information and structured fields
   that are part of the Author's message content.  The body can be
   unstructured lines of text or a tree of multimedia subordinate
   objects, called "body-parts" or, popularly, "attachments".
   [RFC2045], [RFC2046], [RFC2047], [RFC4288], [RFC4289], [RFC2049].


4.1.1.  Envelope

   Internet Mail has a fragmented framework for transit-related handling
   information.  Information that is used directly by the MHS is called
   the "envelope".  It directs handling activities by the transfer
   service and is carried in transfer-service commands.  That is, the
   envelope exists in the transfer protocol SMTP [RFC5321].

   Trace information, such as RFC5322.Received, is recorded in the
   message header and is not subsequently altered [RFC5322].

If there has been discussion that deviates from this and/or calls for modifications to this, please cite it.

      That even includes such questions as
whether RFC 974 was the right solution to that problem and
remains the right solution in a world in which the DNS is being
optimized for other things and we have strongly discouraged open
relays (something else 5321 says little or nothing about) and
whether, when we introduced EHLO, we should also have introduced
a three-layer envelope [2] and whether we should do that now via
a new but strongly-recommended extension.

Again, please document indications of current community concern of these issues.

In any event, I believe the discussion we need now is how we get
to a WG and how to sort out the details of Barry's suggested
approach for moving forward.

Whereas I think there's been some significant attempt to do just that.

 As just one example, as I read his
suggestion, I don't think it allows making major scope changes
in 5321bis, especially because, because of the way it is
constructed, different parts of that document are sufficiently
intertwined that simply adding or removing a substantive
sections or two may lead to inconsistencies that would require
very careful examination and revisions to sort out [3] [4].

Ahh. I think there's been some very useful discussion about work to be done, but apparently you think that Barry's suggestions somehow constrain what constructive discussions we are permitted to have? So, ummm, his suggestions were really a mandate?

[2] Somewhat like the X.400 P1/P2/P3 distinction but not
necessarily using that model.  I note that many of the rough
edges associated with the relationship between trace information
from xx21 and the header specifications of xx22 and many of the
issues with signatures over message headers would be at least
considerably simplified by pushing that type of information into
an intermediate layer or structure.

Whereas I think that any issues with disparities, ambiguities, etc. between RFC *21 and RFC *22 involves the occurrence of redundant text rather than thoughtful incorporation by citation from one to the other.


Dave Crocker
Brandenburg InternetWorking

ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>