Your specific problems of identifying those that are vs those that are
not gateways is one of the reasons I want to define it in terms of what
it does to things outside its range of authority...\Stef
--------
From: Bart Schaefer <schaefer(_at_)z-code(_dot_)z-code(_dot_)com>
Message-Id: <9205151005(_dot_)ZM11722(_at_)z-code(_dot_)com>
Date: Fri, 15 May 1992 10:05:28 -0700
In-Reply-To: Dave Crocker <dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu>
"Re: Second Draft of "Implications of MIME for MTAs"" (May 15, 8:21am)
References: <9205151521(_dot_)AA05270(_at_)Mordor(_dot_)Stanford(_dot_)EDU>
Reply-To: schaefer(_at_)z-code(_dot_)z-code(_dot_)com
To: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Subject: Re: Second Draft of "Implications of MIME for MTAs"
On May 15, 8:21am, Dave Crocker wrote:
} Subject: Re: Second Draft of "Implications of MIME for MTAs"
}
} A "mail gateway" performs store-and-forward electronic mail transfers
} between two environments that are using *different* electronic mail
} format syntax or semantics. Hence, transfering email to any of the
} existing, national email services, or transfering to any X.400 service,
} or even transfering into a non-MIME RFC822 environment is performed
} by a gateway, rather than a simple relay.
This is a reasonably good definition except that there isn't any way to
identify a "non-MIME RFC822 environment". If I've compiled metamail and
stowed it away in ~/bin, my environment is MIME-capable even though the
"official" status of my site may be otherwise. The MTA at the final
destination of the message may have some chance of determining "non-MIME",
but other gateways can do no better than "non-RFC822".
Unless your definition of "non-MIME" is considerably narrower than my
interpretation, e.g. you mean to imply "non-8-bit-clean" or the like ...
--
Bart Schaefer Vice President, Engineering
schaefer(_at_)z-code(_dot_)com Z-Code Software
Corporation
-------- End