Re: question about the new port

[Einar Stefferud <Stef@xxxxxxxxxxx>]

Hi Eliot -- I believe you have broken the code and found the answers!

I agree with you regarding the respective group charters!

But, with regard to your next paragraph...

> Let us also keep something else in mind.  821/822 presumed a fully
> connected network - that mail was going to go from origin to
> destination in one hop.  Even the existence of MX records hasn't
> altered this paradigm, really; rather it has minorly tweeked the
> concept of a destination. That presumption has, over the years, made
> life a lot easier for me and a lot of other people.

First, internet mail has not been operating as a fully connected
service since the first UUCP gateway and the first MMDF relay phonenet
connections went into service, with introduction of source routing for
user%site@relay.domain and the site!user@relay.domain addressing.  I
believe this preceded DNS and MX records, and neither was dependent on
DNS or MX records, then or now.  What DNS does is allow us to route
through relays to "non-contiguous" sites without "source routing".

>                                                       If you use the
> word ``gateway'' once in your discussions, I suggest that you have
> broken that model, and made your lives considerably harder than they
> need be.  Eliot Lear [lear@turbo.bio.net]

Second, the basic problem with denying use of the word "gateway" is
that as soon as we admit to passing both "8-bit data" and "8-bit data
encoded in 7-bit data", we need to have a translator that operates at
the UA level, with UA authority to munge the UA content (e.g., RFC822
or RFC-XXXX).

So, when transferring a message from the 8-bit realm to the 7-bit
realm, WE NEED TO DEFINE A GATEWAY that will do whatever it does in a
very precise way, so it can be undone precisely at the final
destination (e.g., by the final UA or at the final UA/MTA boundary).

So, the very act of deciding to do both 8-bit and 7-bit transfers,
with conversion on the fly at randomly selected points in between,
means exactly that THERE MUST BE WELL DEFINED GATEWAYS at those
conversion points.

SO, BY MY LOGIC, THE BASIC MODEL INHERENT IN OUR JOINT-WORKING-GROUP
TASKS INCLUDES THE DEFINITION OF AN 8-BIT<->7-BIT GATEWAY.  Attempting
to claim that there is no gateway is just whistling in the dark!

So, listening carefully to some of our European friends (many messages
ago), I detected that what they really want is to be allowed to have
8-bit enclaves with gateways at their borders, so that when 8-bit mail
leaves their enclaves, they force it through the gateway to make it
into INTERNET STANDARD (RFC-XXXX) 7-bit transferable.  

The decision to route mail to a gateway, instead of routing to another
8-bit MTA is simply made in each enclave's MTA routing processes.  To
get to any host outside the enclave, it must be routed to a gateway,
and after the gateway munges the outbound copy of the message, it can
be routed to any 7-bit MTA.  Each enclave knows its own boundaries and
can easily know what to do with each and every copy of every message.

Also, it is assumed in this "8-bit enclave model" that reversal back
to 8-bit clean is not done until it arrives at either, its final UA
destination, or an 8-bit enclave boundary gateway.  This is to avoid
repeated encoding-decoding-encoding-decoding-encoding-decoding- at
random gateways along the way.

The good part of this, which lets me accept it, is that the encoding
is always done by the enclave that knows what it is doing and which
has a large interest in assuring that it is done right, and the
decoding is done at the final destination, or an enclave gateway.

Someone recently suggested that there might be a some (many) single
hosts around the internet that also want to do 8-bit clean transfers,
even tough they are totally surrounded by 7-bit MTAs.  This is simply
handled by putting a gateway on each such host to deal with all
outbound transfers.

(I won't comment on how useful this isolated single host enclave is to
(its users.  It was not my idea in the first place.

However, if there is any cluster of 8-bitters somewhere, then this
cluster would perfectly fit the model of an 8-bit enclave.

If someday, some 8-bit enclaves want to interconnect themselves for
8-bit clean transfers, this is fine, as long as the deal correctly
with gatweaying copies to the 7-bit realm.

Maybe, some time in the future, 8-bit will become the primary transfer
mode.  Then we will reverse our thinking and regard the 7-bitters as
the enclavists.  But, everything should still work the same as at the
beginning, with 8-bit<->7-bit gateways at the boundaries.

Best...\Stef