Hello Nathaniel -- My definition of a gateway is simple and direct!
In our MTA/UA case, is any process that does its work at a level which
requires UA Authorization. In general, any Gateway operates at the
layer above the layer where it is lodged, and as such, must operate
only with implied or explicit authorizations by agents at the higher
layer level.
[This is where you and I come to major differences! I fear do-gooders
who act for me without authorizations, while you tell me what
wonderful things these do-gooders will do for/to me! I recall that
do-gooders act without any knowledge of what is good for me. What
answer do you have for this question?]
In more general terms, it is a gateway if it violates layering by
doing something to transform any element of service that belongs to
the level above the layer at which the transform is performed.
There may be other times when a transformer is called a gateway, but
this case defines all the instances I am trying to label in this
discussion.
Now then, my model requires that we also develop and adhere to the
rules of our famous MTA/UA Abstract Model, which I still think is a
critically needed RFC for use to develop and establish as a standard
abstract model for reference in other RFCs.
Remember that we are not concerned here about boundaries inside
implementaions, but about the rules of behavior that are specified in
terms of the abstract model, when building implementations.
So, what I require is that we establish some means of handling the
authorization problem. This makes lots of local problems into network
problems, in terms of the authorizations network which must overlay
the transport network (an MTS in our specific mail system case).
This is how all your do-gooder ideas degenerate into a serious threat
to MTS Quality Of Service (QOS). If we condone do-gooder actions by
random actors at any point in the transfer network, we put ourselves
on a very slippery slope with no stop rules in sight.
Therefore, I want all RFCs to say that such things are a very bad idea
and are not to be allowed, without strict observation of authority
guidelines which say that no transport service is allowed to take any
action for whtihc it is not autorized by some explicit or implicit
authoriazation situation or action.
A gateway between SMTP and UUCP networks, between SMTP and BITNET, or
SMTP and X.400 is a clear case of implicit authorizations.
Your ideas for content conversion hint at some sort of implicit
authoritzation, but the your rules are just too too fuzzy for me.
They involves MTA determinations to act based on "feelings about the
path ahead" and stuff like that.
You do suggest that it would be useful to include
Conversion: prohibited
headers to ward off unwatnted conversions, but you also define
Converion: permitted
as the network default. What about all those UA/MTA system pairs that
do not allow users to insert arbitrary headers into outgoing mail?
All those users are locked into Conversion: permitted!
I will stop here, having made my primary point with my above stated
definition.
Cheers...\Stef