At 10:10 26-02-2009, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Internet Mail Architecture '
<draft-crocker-email-arch-11.txt> as a Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
Some of the terms in the draft are also used in RFC 5321/5322 which
are on the Standards Track :-
email-arch Section 2.1:
"The Author is responsible for creating the message, its contents, and
its list of recipient addresses."
RFC 5322 Section 3.6.2:
The "From:" field specifies the author(s) of the message,
that is, the mailbox(es) of the person(s) or system(s) responsible
for the writing of the message.
email-arch Section 2.2.2
"The Relay performs MHS-level transfer-service routing and store-and-
forward, by transmitting or retransmitting the message to its
Recipients. The Relay adds trace information [RFC2505] but does not
modify the envelope information or the message content semantics. It
can modify message content representation, such as changing the form
of transfer encoding from binary to text, but only as required to
meet the capabilities of the next hop in the MHS."
RFC 5321 Section 2.3.10:
"A "relay" SMTP
system (usually referred to just as a "relay") receives mail from an
SMTP client and transmits it, without modification to the message
data other than adding trace information, to another SMTP server for
further relaying or for delivery."
email-arch Section 2.2.3:
"A Gateway is a hybrid of User and Relay that connects heterogeneous
mail services. Its purpose is to emulate a Relay and the closer it
comes to this, the better. A Gateway operates as a User when it
needs the ability to modify message content.
RFC 5321 Section 2.3.10:
A "gateway" SMTP system (usually referred to just as a "gateway")
receives mail from a client system in one transport environment and
transmits it to a server system in another transport environment.
Differences in protocols or message semantics between the transport
environments on either side of a gateway may require that the gateway
system perform transformations to the message that are not permitted
to SMTP relay systems.
As this draft is being considered as a Proposed Standard, will it be
authoritative instead of RFC 5821/5322?
In Section 1.2 of the draft, RFC2822.From and RFC2821.MailFrom are
used to refer
to structured fields of a message. I prefer Header.From and
SMTP.MailFrom as it doesn't require any changes if RFC 5321 and RFC
5322 are updated. There was a similar discussion about the
replacement for message/rfc822 in the EAI Working Group.
In the Security Considerations Section (6.1):
"As mentioned in Section 4.1.4, it is common
practice for components of this architecture to use the
[RFC0791].SourceAddr to make policy decisions [RFC2505], although the
address can be "spoofed"."
As the focus of the draft is email architecture, this doesn't fit
under security considerations.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
