[Top] [All Lists]

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

2009-03-05 18:32:58

ned+ietf-smtp(_at_)mrochek(_dot_)com wrote:

> I agree it falls into the mediator category. But it if falls into RFC 5321
> gateway category, it ends up dragging almost everything else in there
> with it.
> And we're left with a document that goes to enormous trouble to specify
> behavior something that for all intents and purposes doesn't exist.

Ned, with all due respect, uou repeated this a few times and was going
to leave it alone, but it appears that is being used as premise for

Lets not confuse Gateways as being just some heterogeneous network
transition point with two way transformations.

That's exacly what I'm opposed to doing.

A gate would generally be just the final destination to a backend
storage system.

Actually, that's quite different from RFC 5321's defnition, which talks about
gateway being a component between transport environments.

It could be hosting in passthru fashion (old) or
presenting it for users (active) - s system that has the fundamental
components for electronic messages:


The backend could be a common framework for a myriad of networks.

This is different from a SMTP relay which is homogeneous - the same

The definition of gateway in RFC 5421 doesn't mention different networks. Only
tranport environments. And in practice true gateways, such as SMTP/MIME to
X.400, often operate entirely on a single network.

I guess, we can have a RELAY-GATE if you consider that the backend
could be hosting and storing the reformatted passthru mail.

That is whats "old" and what still remains is that the storage is
available for reader as well.

We still have customers that can read the mail online, but they can
also be "small point", they can QWK, FIDONET into our backend servers
to pick up/sent mail gated from 2822 based networks.

To suggest this is all intents and purposes doesn't exist, well, its
not only untrue but we are seeing a "rebirth" of different and
traditional networking methods. e.g.; to lower the footprint for
small-device communications, to purify mail, to reformat into other

I'm suggesting no such thing. What I am saying is that if every time we come
across something a relay does that doesn't jibe with RFC 5321's relay
restrictions, instead of bringing RFC 5321 into line with reality, we instead
say, "Oh, that's not a relay, it's a gateway, and so rules for relays don't
apply", pretty soon everything will be a gateway and there won't be any relays
left. I don't think that's a desireable outcome.

But that isn't the key point, whether is is or not.

It should not be the premise to eliminate or change a specification
regarding case.

Which nobody is proposing doing. All I'm arguing for is a change to RFC 5321 to
say that the MUST NOT apply semantics to local parts not apply to address
comparison operations.