mail-ng
[Top] [All Lists]

Re: Operations requirement: no hop-by-hop

2004-03-11 07:30:55

Einar,

At 09:00 PM 3/10/2004, Einar Stefferud wrote:

Paul: --

What you say makes very good sense to me, because the current Internet is
capable of single-hop delivery across the great central part of the Internet,

I have always assumed that the 3rd-party relay (i.e., in a domain other
than the message sender and receiver) acted like a point of presence
when the sender or the receiver had intermittent connectivity, as
was the case with many institutions in the U.S. in the 1980's.  I imagine
that there are global regions with intermittent-connectivity today and
that this will be true in outer space as well.

Mark

but has no say about what happens to a message sent to a mailing list expander,
or a corporate firewall, (or a home firewall for that matter)!

And, i might add, it is a very  good thing that the internet does not have
control of what happens in mailing list expanders or inside corporate
private networks.

Your proposal follows the rules of good organizational buffering logic.

Cheers...\Stef

At 20:21 -0800 3/10/04, Paul Hoffman / IMC wrote:
>At 2:33 PM -0800 3/10/04, Dave Crocker wrote:
>>Paul,
>>
>>PHI> The mail-ng transport protocol should be designed to only know about
>>PHI> a single hop, from sender to recipient. The sender may have multiple
>>PHI> hops to a designated transport agent, and the receiving transport
>>PHI> agent may have multiple hops to a mailstore, but the transport
>>PHI> protocol should not make any accommodation for these additional hops
>>PHI> other than to allow them to add metadata to the transit stream. These
>>PHI> requirements are to make the protocol more sensible and to limit the
>>PHI> responsibility of operators to just what they control.
>>
>>How is this different from the current SMTP model?
>
>In the current SMTP model, I believe we have been restricted from having SMTP options that "speak for" SMTP servers further in the chain. For example, we were prevented from making a "NO UCE" banner because there was no way for the server making that claim to know what SMTP servers behind it would have as policy. Different but just as complex logic was used in 8BITMIME.
>
>I am proposing that we think of transport as just between two transport agents. What the receiving agent does with the message is not part of the protocol. Said another way, the transport protocol should not have rules that tell receiving agents what kind of policy decisions they need to transmit further down the line.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium



<Prev in Thread] Current Thread [Next in Thread>