> legacy term. orig/recip are from the X.400 days and have a pretty high
> installed base of usage. I do not see our community having a dominant
> practise of using author -- although it does seem to have a high enough
> occurrence to cite the term also -- and this document is not trying to
> establissh new practise.
Hmm. My problem is that "originator" seems ambiguous between "author(s)"
(i.e. 822.From) and "submitter" (822.Sender).
understand.
however, given the extensive of using the term originator, i'm inclined to
change it only if there is a groundswell of popular preference expressed.
again, note that the goal for the document is to document, not really be
creative or even persuasive. it is trying to capture the current community
consensus on existing email architecture (and terminology).
> I definitely am used to thinking of protocols as residing at boundaries,
> pretty much by definition, and I hope we are VERY careful about
> maintaining the distinction between the abstract architecture, versus
> concrete implementations.
I agree. However in the ugly tables you say that the envelope is created
by the MSA, but from a the protocols point of view (and from the point of
view of most software these days) the MUA must create the envelope in
order to be able to talk to the MSA.
saying anything that means the msa always creates something is a writing error.
my intent is to say that it enforces things and *might* create/modify things,
in order to do the enforcing.
> > MDA:
> The only question this leaves is about choices for delivery protocols.
> I think the answer is reduced to <local> or SMTP.
LMTP is intended for this role.
The document is trying to capture actual practise. That's why this particular
diagram shows lists of candiates. It is my impression that LMTP is not used
much.
Also, on review, the MDA-MS, MS-MS and MS-MUA segments can have quite a bit of
overlap in the set of protocols they use. In particular, POP and IMAP do get
used in each of the segments, I believe.
> > Sieve should be mentioned as a means for controlling the MDA.
>
> The diagram shows sieve as feeding into the MDA.
Hmm. Sieve's a scripting language. What architectural entity interprets
it?
The diagram shows the sieve data being given to the MDA. The intent is to
indicate that the MDA does the interpreting.
> > Is it worth distinguishing online mode and local message store access?
>
> although the operational difference is important, how does that affect
> the architecture?
Whether an Internet protocol is being used or not.
Since this is a document about Internet mail, references to non-Internet stuff
is intentionally limited.
What, specific change are you suggesting?
Note that the diagram already shows two message stores. One of the reasons is
that the second one can be used offline.
The details of communication with the message store and where it resides
etc. in this section are rather complicated, because a lot of the
functions can be implemented in either or both of two places (on the
server and/or the client), with or without network protocols in between.
right.
> > Sieve should be mentioned as a means for controlling the movement of
> > messages in offline mode under control of the rMUA.
>
> please elaborate.
In the IMAP world, the MDA interprets a Sieve script to determine which
mailboxes to deliver the message into, and the MUA talks IMAP to the
message store to access the email.
I think the problem is that the document shows sieve in the diagram but does
not discuss it. I need to add some text, along the lines of what you are
saying.
I think it's essential to have a word to describe the SMTP commands that
occur before DATA (i.e. MAIL FROM and RCPT TO). See above in the
discussion about MSA for an example. I'm not sure what you mean by
"user-to-user message" and how it can be used to draw a line through the
message header.
This is the major architectural weakness to Internet mail. We blurred the
distinction between user headers and handling headers.
User-to-User is the stuff that the originator creates with the intent that it
be consumed by the recipient.
In contrast, the handling information is created for consumption by the
handling service or by the handling service, primarily for consumption by email
operators or for operational analysis.
The Subject: is probably included.
yes.
Are the addressing
fields included?
Ignoring the MUA/MSA protocol issues, where the MSA might get its rcptto list
from the to/cc/bcc fields, the to/cc/bcc fields are intended for consumption by
recipients.
What about instructions to the MSA (BCC:)?
depends upon the particulars of the mua/msa interface.
What about
Date:?
It really is not used by the handling system and very much IS used by
recipients.
Message-ID:?
mixed bag, on this one, i think.
X-Mailer:?
operations use.
When a message is Resent- are the trace
fields from the original message now part of the "user-to-user message" or
not?
Good question. I do not know what constitutes "prevailing" practise. My own
view is that old trace information should be dropped, since a re-send is
creating an entirely new message.
> > There should also be a section on MTA firewalling, to distinguish it
> > from gatewaying.
>
> I'm inclined to agree, but let's explore this a bit. What is the
> architectural role of a firewall? I understand it's operational import,
> of course, but how does this relate to an/the architecture?
We need a word to talk about the parts of the MHS that might mangle
messages. You mentioned fleshing out the operational side of the
architecture, so that we can talk about outgoing relays and incoming MXs
etc. and in this context the border firewall MTA is becoming practically
universal.
Historically, the email term for an entity that transforms content is 'gateway'.
A gateway is an entity that does message (semantics) conversions.
> > MUA Gateways:
> >
> > Aren't these really at the MTA level? Putting them at the MUA level
> > implies a "final delivery" event before the message reaches the
> > gateway.
That's right. A gateway sits between heterogeneous environments and does
conversions to reconcile differences. By contrast, a relay makes no changes to
message semantics and merely takes the message off one transfer link, makes a
routing decision, and queues the message for another transfer link.
Relative to the underlying handling service, when there is a gateway it usually
take formal delivery creates a new message. As I said, what makes gateways
interesting -- besides the impossible task of trying to preserve all the
semantics -- is that it is possible that they emulate a continuation of the
handling service, through the gateway. This is difficult and I believe it is
rare.
> Gateways are strange beasts, indeed. My experience forces me to view
> them as hybrid MTA/MDA/MUA devices. The basic point is that a gateway
> messes mightily with the content. So it is not merely a variant of an
> MTA. On the other hand, your point about the possibility of deferring
> the formal delivery event to a point after the gateway is well taken.
From the content mangling point of view they are close to firewall MTAs.
They are clearly inside the MHS boundary so are not MUAs.
I am not used to having the term firewall refer to the job of content
conversion. I am used to it strictly meaning a security function of detecting
attacks and rejecting them.
That a firewall might do the 'rejecting' by selectively modifying the content
is certainly true, but it's secondary to the task that is referenced by the
term firewall.
My point is not to be abstractly pure or to deny the reality of what is done in
existing practise. Rather I want to make sure the architecture is as clean as
possible in distinguishing roles and responsibilities. In this regard, one
thing we keep needing to juggle is the difference between the conceptual
architecture versus implementation choices that might cross architectural
boundaries (and/or blur them).
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
www.brandenburg.com