Subject: [long] commnets on draft-crocker-email-arch-01
From: Tony Finch <[email-masked]>
To: [email-masked]
Date: Fri, 10 Sep 2004 19:29:26 +0100
List-Id: <ietf-smtp.imc.org>

Tables:

I suggest replacing the tables (which are a typographical disaster)
with a formalized paragraph structure, for example:

Identity: RFC2822.From
Actor: Originator
Description: Names and addresses for author(s) of the message content
    are listed in the From header.

Identity: RFC2822.Reply-To
Actor: Originator
Description: If a message recipient sends a message that would
    otherwise use the RFC2822.From field information in the original
    message, they are to use the contents of the RFC2822.Reply-To
    field instead. In other words, this field is a direct override of
    the From field, for responses from recipients.

Roles:

The idea of roles is a good addition to the document.

I'm not sure about the "Provider" concept. This is partly because I
don't like the term (it's too generic), partly because I'm not sure
it's useful - it isn't used elsewhere in the document, though the term
"organization" is.

Originator/Recipient: Why not use the term "Author" instead of
"Originator"? It should be noted that a message may have multiple
authors and recipients. There's also some confusion of terminology
later in the document, because "originator" and "recipient" are used
to refer to Relays rather than Users in section 3.1.1.

Relay: Is it worth breaking down this category further, e.g. into
outgoing relays (e.g. "smarthosts") and incoming relays (MX hosts)?
Smarthosts in particular are significant because of their evolution
into submission servers in modern setups. These distinctions are
useful for talking about different kinds of access control
configurations (avoiding open relays and firewalling incoming email).
See the Operational Configuration section.

Mailbox addresses:

Is it worth adding examples?

   This domain name might refer to an entire organization (e.g.
   cam.ac.uk), or to a collection of machines integrated into a
   homogeneous service (e.g. hermes.cam.ac.uk), or to a single
   machine.

   It is common for sites to have local conventions for sub-structure to
   the left-hand side of an addr-spec.  This permits sub-addressing,
   such as for distinguishing different discussion groups by the same
   participant (e.g. [email-masked]).

Message IDs:

It might be worth explicitly mentioning that messages with the same
message ID can be assumed to be the same, e.g. for the purposes of
reducing the amount of space required by a message store.

I'm not sure what the following sentence refers to: "Although Internet
mail standards provide for a single identifier, more than one is
sometimes assigned."

Identity Reference Convention:

Why MailFrom but Rcpt-To?

Email System Architecture:

The overview diagram is very unclear, especially the arrows around the
outside relating to the envelope, DSN, MDN, and Sieve. The oMUA and
MSA may also use local conventions, as may the MSA and first MTA (e.g.
in the common case where the MSA is part of an MTA).

Should there be a concept of privilege? I.e. MUAs are not privileged,
but everything else is. This is relevant to MSA fix-ups and alias
handling.

MUA:

The commentary about bounce addresses in the RFC822.Sender
description really belongs in the MSA section.

The comment about the BCC field is incorrect according to my
experience: I think it's more usual for the message to be submitted
once, and the MSA deletes the BCC header and transfers its address
list to the RCPT TO list when constructing the envelope.

MSA:

It should be noted that the submission protocol does not lie on
the boundary between the MSA and MUA, because when it is being used
the user's software has to do some MSA work like setting up the
message envelope and handling the BCC: header field. An example of
an implementation boundary which lies on the architectural boundary is
the `sendmail -t` API in Unix.

The MSA section should talk about the header fix-up work it should do,
including adding missing fields (Date:, Message-ID:) and correcting
the Sender: field (in the case that the MSA is more trusted than the
oMUA and the MSA has authenticated the Submitter).

Is the outgoing interface of the MSA required to be SMTP or can it be
a local hook into the first MTA? For example, in the case of `sendmail
-t` should the whole of sendmail be considered to be the MSA or is it
a Siamese twin of MSA and MTA (I prefer the latter)? This relates to
whether the MSA can be said to "set" a HELO identity (I would say
not). Additional confusion is caused by the submission protocol, in
which a HELO identity is "set" by the MUA part of the MSA.

HELO/Received:

One of the difficulties in the tables is that the HELO and Received:
point in different directions, by which I mean that the Received:
field refers to the message's previous hop whereas the HELO argument is
related to its next hop. The HELO argument ends up in the next
Received: field, but isn't directly recorded which makes it a bit of
an odd fellow compared to the other "settings".

I also don't like referring to Received: as an identity because it is
really a composite field containing a number of identities - at least
the previous MTA's HELO, IP address etc. and this MTA's host name etc.
It's too complicated to fit into the model comfortably.

MTA:

The Return-Path field is set by the MDA not the MTA.

The paragraph about serendpity seems to belong better in the Service
Overview section.

MDA:

Nothing in this table should be there!

POP and IMAP are not delivery protocols, they are retrieval protocols,
for moving or copying messages from one message store instance to
another (about which more later) or for interactive message store
access (see old names for IMAP!). Note that IMAP doesn't have to be
interactive: it supports a number of usage models as described in RFC
1733 and the next section.

Sieve should be mentioned as a means for controlling the MDA.

MS:

I suggest invoking the "architecture is not implementation" clause
here in order to simplify matters. Treat the message store as a single
entity regardless of whether online, offline, or disconnected mode is
being used. The mode of usage determines whether the message store is
a single entity or two entities. This will help greatly with the
diagram in section 4.

Is it worth distinguishing online mode and local message store access?

Sieve should be mentioned as a means for controlling the movement of
messages in offline mode under control of the rMUA.

Layers of Identities:

"message header" not "headers". The same error is made in a section
name.

Message Data:

I find it useful to distinguish between the "message envelope" (i.e.
the sequence of SMTP commands before DATA) and the "message data"
(which consists of everything after DATA, i.e. the "message header"
and the "message body"). Before this document I haven't heard of
anyone including trace fields in the envelope.

Two Levels of Store-And-Forward:

Care is needed with the term "re-submission". It seems to imply that
RFC 2476 fix-ups occur, which is not the case in alias handling. I
still think alias handling is privileged, and architecturally an MDA
function rather than an MUA function: it happens before the
Return-Path: field is added to the message; some MSAs restrict the
user's ability to set the bounce address, but this restriction doesn't
apply to alias-forwarded email because the MSA isn't in the loop.

MTA Relaying:

There should also be a section on MTA firewalling, to distinguish it
from gatewaying.

MUA Basic Forwarding:

Should it be called encapsulation forwarding? The MIME type
message/rfc822 should be mentioned.

MUA Re-Sending:

This should not be referred to as redirecting because redirect is the
sieve command for alias forwarding.

The Actor for the To,CC,BCC fields should be the Originator. The Actor
for the Rcpt-To should be the Intermediate Submitter.

The terminology in the table isn't consistent with the terminology in
the preamble. Recipient-1 or Intermediate Originator/Submitter?

MUA Reply:

Would it be worth adding the following clause to the end of the
sentence to make the presence of this section clearer? "though it
may contain a quote from the original message."

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.

MUA Alias Handling:

I've already said I think this is an MDA function.

The actors are all wrong. to/cc/bcc should be "originator", rcpt-to
should be "intermediate recipient", mailfrom should be "submitter",
received should be "forwarder".

MUA Mailing Lists:

The actor for the Sender should be the intermediate submitter not the
original submitter. For to/cc it is the originator. For rcpt-to it is
the intermediate submitter.

------------------------------------------------------------------------

Whew. I think that's all.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
EAST FITZROY: SOUTHWEST 4 OR 5, OCCASIONALLY 6 LATER. RAIN OR SHOWERS.
MODERATE OR GOOD.

Date: Thu, 09 Sep 2004 10:48:38 -0400
From: Bruce Lilly <[email-masked]>
Reply-To: IETF-SMTP <[email-masked]>
Organization: Bruce Lilly
To: IETF-SMTP <[email-masked]>
Subject: Initial comments on draft-croker-email-arch
Sender: [email-masked]

Some comments, in the same order as the draft text:

In section 1.1. "intermingled" would probably be more accurate than
"divided".

Section 1.2 encourages review of tables.  Table 4.1.4 refers to actor
"h", which is nowhere defined.

Section 1.2 also discusses MDA/MS/MUA and requests review of the model.
Several terms used in the model (discussed separately below) probably
need revision, and gateways (of various types) aren't shown at all.

And section 1.2 mentions message identifiers, but nowhere are the
message header fields that use message identifiers -- Message-ID,
Resent-Message-ID, Original-Message-ID, In-Reply-To, References,
Supersedes, and Delivery-Report-Content-Original -- discussed!
Indeed, only a tiny fraction of standardized message header fields
are mentioned at all.

Section 4 omits presentation and discussion of gateways. I can think
of several types of gateways:
1. gateways between different transport methods (using different
   transport addressing), where the message content is identical,
   e.g. between SMTP and UUCP (some mention in RFC 976)
2. gateways between mail systems where transport, addressing, and
   message format all differ, but the basic function (interpersonal
   electronic correspondence) is the same. E.g. between Internet
   mail and X.400 (MIXER series of RFCs), between Internet mail
   and proprietary vendor-specific systems
3. gateways between systems that use essentially the same message
   format and transport, but between separate functional entities;
   typically a separate end-to-end function using the Internet
   message format and infrastructure. E.g. voice messaging (VPIM),
   fax, printing
4. gateways implementing end-to-end functionality layered on top of
   Internet mail (this is distinguished from the case immediately
   above; whereas in the above case the interaction with the user
   is typically *not* via a MUA except in particular implementations,
   this case typically *does* use a MUA). E.g. EDI (RFC 3335).
5. list expansion is typically a gateway function
6. message processing for security by MTAs or MDAs which are acting
   as gateways. E.g. virus scanning.  See RFC 1344 vs. CERT Vulnerability
   Note #VU836088 (http://www.kb.cert.org/vuls/id/836088).
7. gateways between systems that use essentially the same message
   format but different modes of distribution and addressing. E.g.
   between mail and Usenet.

Note that the message store (4.1.5), particularly type MS-1, is
correctly identified as a *message* store (and not a "mail" store);
IMAP (Internet Message Access Protocol) in particular is capable of
accessing messages in the message store regardless of how they may
have arrived at that store (Usenet, SMTP, ...).

Section 5.2 refers to "message headers". Some messages do in fact
have multiple headers; the message header and one or more MIME-part
headers. Section 5.2 refers to "headers" where it means message
header fields. Use of "headers" in lieu of "header fields" may
lead to confusion and/or misinterpretation.

Sections 6.2.4, 6.2.5, and 6.2.6 should probably be renamed; gateways
(in general), alias expanders (in particular), and mailing list
expanders (in particular) are not typically MUA functions. They
tend to be MTA or MDA functions.

Section 6.2.6 refers to mailing list "address", which should be
"mailbox" (a single mailing list is typically not accessed via
a named group, which contains a list of mailboxes and is the
difference between "mailbox" and "address" (RFC 2822)).

From: "Hector Santos" <[email-masked]>
To: "Tony Hansen" <[email-masked]>, <[email-masked]>
Subject: Re: 3rd party ietf-compliance testers
Date: Mon, 6 Sep 2004 19:39:17 -0400
Organization: Santronics Software, Inc
Sender: [email-masked]

For SMTP, you can get some operational compliancy testing done at
http://www.dnsreport.com   Type in a domain and it spits of a report for
proper mail hosting operations.   It helped clean up some things for our
mail server.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

----- Original Message -----
From: "Tony Hansen" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; "ietf-822 mailing list"
<[email-masked]>
Sent: Wednesday, September 01, 2004 4:14 PM
Subject: 3rd party ietf-compliance testers

>
> Do anyone know of any companies out there that will do IETF compliance
> checks of SMTP and/or POP servers? We have a situation where we could
> use such a service.
>
> Thanks!
>
>  Tony Hansen
>  [email-masked]
>
>
>

Date: Wed, 01 Sep 2004 16:14:35 -0400
From: Tony Hansen <[email-masked]>
To: [email-masked], [email-masked], ietf-822 mailing list <[email-masked]>
Subject: 3rd party ietf-compliance testers
Sender: [email-masked]

Do anyone know of any companies out there that will do IETF compliance 
checks of SMTP and/or POP servers? We have a situation where we could 
use such a service.

Thanks!

	Tony Hansen
	[email-masked]