[Top] [All Lists]

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

2009-03-02 12:49:18

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.


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.


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.


Hector Santos

<Prev in Thread] Current Thread [Next in Thread>
  • Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard, Hector Santos <=