Maybe Dave you should add an Updates tag to your draft?
Eliot
On 3/2/09 5:26 PM, ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:
At 20:21 01-03-2009, Dave CROCKER wrote:
>What inconsistencies are you seeing, specifically, so we can fix them.
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."
The draft says that a relay can modify message content representation
whereas RFC 5321 says that a relay does not do any modification to
the message data other than adding trace information.
Another place where RFC 5321 is at odds with reality, I'm afraid. MIME
downgrading is the obvious example where relays alter message content
and such
alterations are explicltly condoned by other standards.
The customary fig leaf we try and draw over this is that systems that
perform
such alterations are gateways, not relays. But this particular fig leaf
has gotten awfully small and thin over time.
In any case, this is one where I think the email-arch document is right,
RFC 5321 is wrong, and we should fix RFC 5321.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf