Hi Dave,
At 14:59 06-05-2007, Dave Crocker wrote:
I've sent in draft-crocker-email-arch-07 to the I-D folks.
If you have any final comments, please get them to me.
In Section 3.3.1, it is mentioned that the message-id is associated
with the RFC2822.From field, although any actor within the
originating ADMD might assign it.
The message-id is an identifier which refers to a particular message
(RFC 2822 Section 3.6.4). It identifies the message as a whole and
not the instantiation of the RFC2822.From field.
In Section 4.1.4:
RFC2822.Sender
Set by: Source
This specifies the address responsible for submitting the message
into the transfer
service. For efficiency this field can be omitted if it contains
the same address as
RFC2822.From. However this does not mean there is no Sender
The RFC2822.Sender should not be used if it is the same as the
RFC2822.From (RFC 2822 Section 3.6.2).
You could say:
For efficiency, this field is omitted if it contains the same address
as RFC2822.From.
In Section 5.1:
Aliasing mixes local aliasing and forwarding. I'll use the term
"Address rewriting" and define it as a re-addressing facility that is
performed before the message is delivered. If the rewrite is a
"Forward", the message does not have to be submitted back to the
transfer service unless the forwarding is done by the MDA. The
message's RFC2821.MailFrom is not changed during the forwarding process.
The RFC2821.RcptTo value can be outside the scope of the ADMD doing
the address rewriting. There is no need to change the envelope
information if the rewrite is local aliasing as it is more of final
delivery decision as to which mail store should be used.
In Section 5.2:
Re-Sending does not create a new message. According to RFC 2822,
Section 3.6.6, a Resent is when a message is reintroduced in the
transport system.
Re-Sending should not pass the RFC2822.BCC field set by the original
Originator (RFC 2822, Section 5).
In Section 5.3:
Mailing lists have explicit email addresses and they re-post
messages to a list of
subscribed members. The Mailing List Actor performs a task that
can be viewed as an
elaboration of the Re-Director role. In addition to sending the
new message to a
potentially large number of new Recipients, the Mediator can
modify content, such as
deleting attachments, formatting conversion, and adding
list-specific comments. In
addition, archiving list messages is common. Still the message
retains characteristics
of being "from" the original Originator.
could be changed to:
Mailing lists have an explicit list of email addresses of
subscribers to which
they repost messages. The Mailing List Actor performs a task that
can be viewed as an
elaboration of the Re-Director role. In addition to sending the
new message to a
potentially large number of new Recipients, the Mediator can
modify content, such as
deleting attachments, format conversion, and adding list-specific
comments. In
addition, archiving list messages is common. Still the message
retains most of the
characteristics of being from the original Originator.
I added "most of the characteristics" as the RFC2822.Sender is
obviously changed.
"Bounces" do not go to the RFC2821.MailFrom when a message passes
through a mailing list. There should be a RFC2822.Sender to which
the bounce goes to.
In Section 5.5:
Organizations often enforce security boundaries by subjecting
messages to analysis, for
conformance with the organization's safety policies.
As the next sentence talks about spam, it may be better to drop "safety".
A Filter might alter the content, to render it safe, such as by
removing content deemed
unacceptable. Typically these actions will result in the addition
of content that
records the actions.
A Filter may reject a message or alter the content if the message is
deemed unacceptable.
Regards,
-sm