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 <[EMAIL PROTECTED]> 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.
