![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Maybe Dave you should add an Updates tag to your draft? Eliot On 3/2/09 5:26 PM, ned+ietf at mauve.mrochek.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 notmodify the envelope information or the message content semantics. Itcan 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. MIMEdowngrading is the obvious example where relays alter message content and suchalterations are explicltly condoned by other standards.The customary fig leaf we try and draw over this is that systems that performsuch 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.org https://www.ietf.org/mailman/listinfo/ietf
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.