On Mon, 15 Oct 2007, Tony Finch wrote:
In general I think the email architecture document needs to replace many
of its neologisms where there is existing terminology with the same
meaning.
Dave has asked me to expand on my grumble.
"email object" - Should be "message".
"Originator" - In *822 this comprises multiple authors, a distinguished
sender, and a list of reply-to addresses. (There's also the return path
which tends to be the same as the sender.) However Email-arch describes it
as comprising one author. In a number of places the draft uses "author"
where "sender" would be more correct per 822, so the "originator"/"author"
synonym is off the mark. I think email-arch would be better off if it
didn't try to lump these concepts together, except for presentational
purposes.
"Source" - Is this supposed to comprise more than the message submission
service? Or is it the whole outgoing email infrastructure of the
originaing domain?
"Dest" - there's a box in a diagram but no description.
"ADMD" - I'd prefer simply "domain", though this is liable to confusion
with domain names.
"Mediator" - I remember it being difficult to find a good word for these
entities, and I think it's still not quite right. To me "mediator" implies
somthing acting on behalf of the other entities to achieve some goal (e.g.
in a non-computing context, mediation to resolve a dispute without going
to court) with active back-and-forth communication between the mediator
and the others. However this email thing is often acting in its own
interest, and the communication is open-loop (section 1.2). I suggest
"intermediary" since it has a closer meaning to what we want (or rather,
less misleading implications), and the adjective "intermediate" leads to
better grammar when describing situations involving intermediaries, e.g.
original source, intermediate dest, intermediate source, final dest (c.f.
section 5).
"Envelope" - The description here is much better than in earlier drafts,
though it fails to explain the rationale for the header/envelope split,
i.e. that basic message relay and delivery can be performed using only the
envelope, and without inspecting the message data but only sticking a
Received: or Return-Path: field (respectively) at the front.
"2821.EHLO" - the table at the start of section 4.1.4 is correct but the
longer paragraph is completely wrong.
Some more general comments.
There's no serious mention of authenticated security boundaries in the
draft. The most significant ones are between the MUA and the MSA (message
submission) and between the MUA and the server message store (POP & IMAP).
(There's also the option of authenticated SMTP relay, though that's
usually by IP address rather than SASL or TLS, and is relatively simple
architecturally.)
The draft sort-of covers message submission in its discussion of the
"Source", though it does not explain the dual-allegiance in terms of
enforcing a security boundary.
The MDA / message store discussion is more confused, because the
boundaries that the draft draws do not correspond to security boundaries.
I'd argue that the MDA and server message store are all part of the MHS,
since they are behind the security boundary that separates MHS
administration from the users.
Should the draft have more to say about "final delivery"? (This fits in
with the terminology discussion above, e.g. "as performed by the MDA at
the final dest".)
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> http://dotat.at/
WIGHT PORTLAND PLYMOUTH: SOUTHWEST BECOMING CYCLONIC, THEN NORTH, 5 TO 7,
PERHAPS GALE 8 LATER. SLIGHT OR MODERATE, OCCASIONALLY ROUGH. OCCASIONAL RAIN
OR DRIZZLE. MODERATE OR GOOD, OCCASIONALLY POOR.