Eric,
EAH> | End-to-end Internet mail exchange is accomplished by using a
EAH> | standardized infrastructure comprising:
EAH> Two additional core functions are routing and [re-]queuing algorithms,
As with Chris' note, I think yours extends the doc... but in a good way.
Certainly the role of independent mta-based routing needs to be cited.
I'm not so sure that re-queuing does. I think of email's queuing as a
(popular) local implementation issue. (However, as Graham Klyne persists
in noting, email's persistence across system outages is in marked
contrast with instant messaging's lack of it. And this permits very
different implementation choices.)
Let's explore this a bit: The formal service has the concept of
transient problems. This implies later retries by the client SMTP. But
it is not required and the specs specify remarkably little about this.
Would it be valid to have an email transmission client that bounced
messages after the first transmission failure (of any kind)? If it is
legal but no one can possibly envision that it is a viable choice for an
implementation, then retries are probably a core aspect of the service.
EAH> | 3 Email System Architecture
EAH> I disagree with the use of this terminology for the purpose of describing
EAH> the global network of mailboxes; the "agent" model stopped being useful
EAH> for most environments by 1990, and it is far better to talk about the
You appear to want to invent an entirely new architecture reference
model. That might be a fine exercise to pursue, but it's not a goal of
this document.
EAH> The principle reason for talking about functions instead of node-types is
EAH> that modern agents often incorporate functions that are not reflected by
EAH> historical classifications. For example, it's not unheard of for a
EAH> first-hop "MUA" to make routing and queuing decisions based on the
EAH> destination address, at which point it is no longer a simple MUA, but
EAH> instead is an MUA (presentation) with a local MSA (queuing) and MTA
EAH> (routing and transfer).
You would be making an interesting point, were it not for the NOTE at
the beginning of Section 3.
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>