Re: Miscellaneous comments on draft-crocker-email-arch-04.txt

[Bruce Lilly <[e-mail]>]

On Tue April 5 2005 10:13, Dave Crocker wrote:

> No, the first standardized architecture was the IFIP WG 6.5 effort, later, 
> that fed the X.400 work.  There was no public, standard "architecture" work 
> prior to that.

OK, if there is some document that can be referenced, a suitable
reference in the draft would help.

> Saying "core aspects" leaves all sorts of room for "other", and hardly 
> constitutes an implication that the changes you cite have not occurred.

IMO, one of the core aspects was the end-to-end Architectural nature
(as in Internet Architecture, hence the reference to RFC 1958) of the
service in the decade prior to insertion of transport markings into
that content starting with RFC 788.

One possible use of an architecture document may be in development of a
next-generation mail system.  It is in that case important to consider
not only how things are now, but also how they were and how the changes
have affected the mail system, for better and for worse.

Other possible uses include further extensions, and in that case also
it is important to differentiate those things which have turned out in
retrospect to have caused difficulties, so as to not compound the
problems by repeating past mistakes.

> the problem with terminology, here, is matching existing practise, in 
> particular finding a term that people will be comfortable with.  as nearly as 
> i can tell, 'bounce' is a common term, in spite of the fact that it also 
> applies to intermediate and successful delivery notices.

But "bounce" doesn't mean "delay" or "success"; it indicates failure
only, and that's the problem.  Specifically for delivery status
notifications, "delivery status notification" or "DSN" is a suitable
standardized term (which can be a noun when used alone to refer to a
DSN message -- though adding "message" removes ambiguity -- or it can
be a modifier for some noun, e.g. "path").  Alternatively, "delivery
status" alone could be used as a modifier, in the way that the noun
"notification" can be modified by "delivery status", message
disposition", and "message tracking status" to indicate distinct types
of notifications.

Incidentally, the draft doesn't discuss message tracking at all (RFCs
3885 through 3888).

> >  Section 2.2.3 states "A Relay may add information to the envelope, such as
> >  with trace information.  However it does not modify existing envelope
> >  information or the message content semantics".  Routes in paths (forward
> >  and reverse) generally are modified in transit. Routes in paths are now
> >  somewhat uncommon, but are not obsolete and should not be ignored in a
> >  description of the mail system architecture.
> 
> what specific changes are you saying are legal for an mta to do?  

If an MTA at host example.net receives a message with the forward path
<@example.net:[e-mail]> and a reverse path
<@example.org:[e-mail]>, both in the SMTP envelope, those may be
modified to <[e-mail]> and
<@example.net,@example.org:[e-mail]> respectively. 

> please cite the rfc2821 text that authorizes it.

Section 3.3:

   The <forward-path> can contain more than just a mailbox.
   Historically, the <forward-path> can be a source routing list of
   hosts and the destination mailbox, however, contemporary SMTP clients
   SHOULD NOT utilize source routes (see appendix C).  Servers MUST be
   prepared to encounter a list of source routes in the forward path,
   but SHOULD ignore the routes or MAY decline to support the relaying
   they imply.  Similarly, servers MAY decline to accept mail that is
   destined for other hosts or systems.

Note that the MUST is a requirement; SHOULD/SHOULD NOT are (mere)
recommendations.  Per that section, the reverse path in the example
above MAY be modified to simply <[e-mail]>.  See also section
5.2.6 of STD 3 (a.k.a. RFC 1123).

> yesthe rMUA take the actions that effect synchronization between the MSs.
> 
> however it is synchronization between the MSs that is of interest.

My point is that (contrary to the draft implication) the MSs do not
connect to each other, an rMUA connects to both MSs simultaneously and
it is the rMUA that effects the synchronization.  The operational
relationship is between the rMUA and each MS, not between two MSs. In
the description of Disconnected operation, "connected" and
"reconnected" should each be followed by "to a common rMUA" (connecting
two independent rMUAs, one to a local MS and the other to a remote MS
won't result in synchronization).

> >  Section 5.5 should explicitly caution against mangling of Originator
> >  fields (e.g. see draft-malamud-subject-line-04.txt).
> 
> You might have noticed that that section is rather short.  There are all sorts 
> of things one might put into such a section, but I most clearly was not 
> intending to make the section be any kind of thorough.

I have noticed that the other section 5 subsections have detailed
indications of which envelope/header fields may and may not be modified
and that such considerations are missing from section 5.5 only.