ietf-smtp
[Top] [All Lists]

Re: Final draft: draft-crocker-email-arch

2007-05-11 20:26:04

Dave Crocker wrote:
 
If you have any final comments, please get them to me.

| The body may be unstructured simple lines of text, or it may
| be a MIME tree of multi-media subordinate objects, called 
| body-parts, or attachments.  [RFC2045], [RFC2046], [RFC2047],
| [RFC4288], [RFC4289], [RFC2049].

s/or attachments/including attachments/

An "attachment" is a Content-Disposition for MIME parts, MIME
parts can be also inline.  With my MUA it's a major difference.

| It can be generated by an rMUA and is sent to the 
| Disposition-Notification-To address(es).  The mailbox for 
| this is shown as Disp in Figure 5.  It

? It
+ It is typically the same address as the Envelope-Sender address.

| Upon delivery, some SMTP-level envelope information is typically
| encoded within additional message object header fields, such as
| Return-Path.  [RFC2821],[RFC2822]

The Return-Path is not optional, it's required for 3834 and SIEVE.

s/such as Return-Path./especially the Return-Path./

| Procedures for registering header fields are defined in [RFC4021].
| An extensive set of existing header field registrations is
| provided in [RFC3864].

Swap 3864 (procedure) and 4021 (initial registry).

       | Message header fields | From        | Originator          |
       |                       | Sender      | Source              |
[...]
       |                       | Message-ID  | Source              |

+1  That's probably Peter's observation about Message-IDs in 3.3.1,
    it should say "associated with the 2822.Sender", not 2822.From,
    corresponding to the figure in 4.1.4.

| Specification of the error return addresses -- the "Bounce"
| address, contained in RFC2821.MailFrom -- is made by the
| RFC2822.Sender.  Typically the Bounce address is the same as the
| Sender address.  However some usage scenarios require it to be
| different.

The term "envelope sender address" (after a definition) would be
much better than all those "bounce" and "error return addresses".

It's not only used for NDNs, it's for (almost) all auto-replies.

| The MSA can specify its hosting domain identity for the SMTP HELO
| or EHLO command operation.

s/MSA/MTA/ or something in this direction, not only the MSA.  The
I-D says "set by source", but I think it should use a similar "set
by" as RFC2821.Received (source, relay, mediator, dest).  Probably
minus "dest".

| RFC2821.RcptTo
|
|     Set by: Originator

Is that "set" as in "initially set" ?  And why isn't it set by the
"source" as for the 2821.MailFrom ?  It's also set by a "mediator".

| This indicates trace information, including originating host,
| relays, Mediators, and MSA host domain names and/or IP Addresses.

s/MSA/MTA/

 
| RFC2821.Return-Path
|
|     Set by: Source

s/Source/Dest/  (reflecting the last Mail From of course, maybe
                 it depends on the precise definition of "set".)

| A recent alternative is SUBMISSION [RFC4409].  Although SUBMISSION
| derives from SMTP, it uses a separate TCP port and imposes distinct
| requirements, such as access authorization.

Please strike "recent" and "Although".

|      RFC2822.Received
|
|         Set by: Relay Server
|
| 4.3.3.  Mail Delivery Agent (MDA)

Is the "Set by:" blurb here a dupe of 4.1.4 (?)

In 4.3.3 there are two similar "set by:" blurbs, I think you want 
this only in 4.1.4 (?)  

Ditto in 5, but there it makes sense to show the differences from
4.1.4.    

In the "resent" section you have:

|        RFC2822.Received
|
|        Set by: Mediator Dest
|
|        When resending a message the submission agent can record a
|        Received header field, to indicate the transition from
|        original posting to resubmission.

What's "Mediator Dest", the MDA before the resending (last Received
below the Resent-*) or the MSA used for resending (first Received
above the Resent-*) ?  The text sounds like the latter, but that's
a "Mediator Source".  Something's messy with those "set by" blurbs.

In 4.1.4 it's "RFC2821.Received", all later "RFC2822.Received" are
dubious, ITYM "RFC2821.Received", not 2822.

You could mention Resent-Message-ID in 5.2.  For the 2821.RcptTo in
5.* I'd say "mediator source" instead of "mediator originator" (as
mentioned above for 4.1.4), same issue in 5.1 + 5.2 + 5.3

Giving up at 5.4 for today and -07, this "set by" stuff is not yet
consistent everywhere.

Frank