ned+ietf-smtp(_at_)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.
Which ones? With middle ware?
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.
+1.
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.
-1.
I hate middle ware, passthrus, relays, routers, what have you, that
alter the original mail integrity. It should be against the law.
hmmmmmmmmmm, in fact, if push came to shove there might be some legal
(US) precedence for such mail tampering claims.
I know society has been molded to believe that we can SNIFF
transmissions, but alterations within a homogeneous network should not
be encourage, nor tolerated. Be very careful to [further] open
Pandora's Box here.
--
Sincerely
Hector Santos
http://www.santronics.com