On Fri, 28 Jan 2005 12:02:10 -0500, Mark E. Mallett wrote:
Some more random comments-
> 4.1.4 Mail Delivery Agent (MDA)
>
> The <MDA> delivers email to the recipient's inbox.
Or, more generally, to the recipient's mailstore. "inbox" is usually
a name for a specific well-known folder in the recipient's mailstore.
The MDA might store directly to other folders; saying "inbox" implies
something narrower than that.
> Using Internet protocols, ...
> initiative of the recipient system. Notably, SMTP and POP effect a
> transfer of message control from the email service to the recipient
> host. In contrast, IMAP provides on-going, ...
I don't really get what you are trying to say here.
yeah. it needs cleaner language.
the point i was trying to make is that smtp and pop "move" the message from the
remote system to the local system, whereas IMAP is able to keep a copy on the
remote store.
I would say that
the MDA delivers to the mailstore. Access to the mailstore (rather than
"delivery") may be effected via POP and IMAP. Those are not the only
mailstore access mechanisms; direct filesystem access would be another.
"direct filesystem" and the like are what I mean by 'local'. this needs to be
modified to be more obviously what is meant.
Further, I think you've got a false distinction between POP as a
transfer technique and IMAP as an access technique.
This was a point of considerable debate, between me and lots of others, after
the first draft. I thought I had modified it to reflect rough consensus, but
obviously need to modify it more.
(it is even possible that i lost the text that was meant to reflect this
change. anyhow, i'll fix it.)
One perspective of "end-to-end" is that the receiving end is the first
mailstore delivered to (for those messages that do indeed end up in
mailstores, which is the majority.) All other operations on email after
that delivery are mere manipulations of delivered mail.
Your qualifier "one perspective" is the most important point. What is
increasingly clear is that "end-to-end" is a very useful term only if one is
VERY clear about defining the end-points, since the choice of where they occur
varies enormously, depending upon the semantics of the service AND the
configuration of its use.
One reason for adding the construct of Administrative Domain is tha there are
some functions that exist within an Administrative domain, but can occupy
different places within it. From a global perspective, it does not matter
which of those different places it resides in, as long as it is within an "end"
administrative domain.
With that
perspective, POP/IMAP and the like are probably better covered by an
"access" category (Actor: Recipient) which would include not only
reading email but moving email from one delivered mailstore to another.
The earlier debate, that I referred to, seems to come from exactly the issue of
distinguishing delivery from access. My own preference is to make an
architectural distinction between delivery and access but my reading of
community consensus is, instead, to view delivery as the architectural item and
access as a usage item. That is, either pop or imap can be used for delivery
and either pop or imap can be used for access.
Hmmm. Maybe I can still reflect this via an architecural point. It occurs to
me that the "Internet Mail Protocols and Services" has the seeds of this
distinction.
> 5.1
> Direct envelope addressing information, as well as optional transfer
> directives, are carried in-band by MTAs. All other envelope
> information, such as trace records, is carried within the content
> header fields.
"in-band" is not a clear term because there are multiple bands.
The message object is the RFC2822 thing. The SMTP Envelope is parametric
information not carried as part of the message object. It is carried within
the transfer protocol.
That is what I mean by "in-band". So now the question is how to say this more
clearly.
When I
read "in-band" I think "mixed with the message," e.g. in the message
close. i meant 'mixed with the protocol RATHER THAN the message'.
one thing that is now eminently clear to me is that 'in-band' is entirely the
wrong term.
This probably gets back to the whole "envelope/SMTP envelope/message"
brouhaha from the prior round of discussions. (Personally I thought
that X.400 made some good distinctions here, e.g. with the "P1 Envelope"
and "P2 Envelope" -- then again I haven't cracked open the old redbook
in, um, decades.)
On the average, I believe the OSI work often elucidated very important issues.
It's how they solved them that was the problem.
In the latest round of the architecutre, the obvious example is use of
Administrative Domain. X.400 used it as an addressing construct. In the
architecture document, I am trying to use it, instead, as an operations and
routing construct, invisible to addressing.
> 6.2.5 MUA Alias Handling
>
> Notably it does not typically change the RFC2821.Mailfrom
>
Realizing that you said "typically" : yet some alias implementations will
rewrite the return-path information, e.g. in sendmail;
Well, frankly the goal for this sub-section is to define an MUA-level function
that is essentially on a par with MTA-level relaying. It uses a new RCPT-To
address, but does not otherwise alter responsibilities for the message, for
notifications, etc.
Perhaps that is overly strict. The question, then, is what boundaries for the
function represent community rough consensus?
And what is the next level of MUA funnctionality? Do we immediatley jump to
"gateway" where any action at all might be done, or is there (another)
intermediate role that does more than the restricted aliasing but less than
gatewaying?
In other words, what are the gradations of labels for MUA-related re-posting
that are useful for the community?
And I believe that it is very common to use this "owner" rewriting when
expanding to more than one address, in order to take local responsibility
for problems with delivery to any of them.
And isn't that the essence of mailing list functionality?
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net