Re: Why are we here? What are our goals?

On 1/30/2004 5:03 AM, Florian Weimer wrote:

> Nathaniel Borenstein wrote:

>>	-- enhanced tracing mechanisms
> 
> I don't think tracing is *that* important.  It works rather well
> already, as long as we stay within the mail domain.  The trouble starts
> when a media boundary is crossed (regular SMTP server vs. trojan mail
> relay), and this is not something that can be cured within the system.

It's solvable to the point that people can set their filters to a level
they are comfortable with. Using something like domain-based sender
certificates means that problematic sources can be filtered easily (to the
extent that they don't have a zillion domains). Meanwhile, recursive host
signatures means that any of the hosts in the path can also be verified
and filtered. Other markers can indicate other kinds of events, such as
the presence of an SMTP gateway, the number of hops, and so forth. With
enough markers, people can filter according to their tolerance levels,
which means that the problem becomes solvable even if there is no single
mechanism that will 'cure' the problems inside the protocol itself.

> 	-- favor connected over disconnected operation

> The first part is quite controversial, of course.  However, I don't
> think it's a good idea to optimize for disconnected operation at this
> time.  The number of users who write messages off-line *and* have some
> mechanism for unattended, automatic delivery (e.g. period UUCP call-out)
> is negligible; it doesn't make sense to optimize the protocol for them.
> Most off-line message composers explicitly trigger and attend the
> dial-out operation that delivers their email.

Off-line composition isn't the problem so much as the fact that the
messaging network is larger than the Internet itself. For example, a
cellular PDA and a node on a DECnet network can exchange mail via some
kind of private gateway, with none of the nodes ever being connected to
the Internet proper. So we pretty much have to assume that the terminal
nodes (the mailboxes and users) are disconnected.

However, it is also possible to assume that there will either be a
temporary state of transient connectivity for either the nodes or a
gateway at some point (necessary for transfer, obviously), and to move
certain kinds of connected operations to that stage. In particular,
validation operations can be performed at the connecetd stage, with the
recipient either fetching the data it needs, or applying out-of-band
trusts to a gateway partner. For example, an inside host might only get
mail from a single outside gateway, so all verification could be done by
the outside host and the inside host explicitly trusts the outsider.

But again (and more importantly), the terminal nodes of the messaging
network (the mailboxes and processes) would be disconnected from each
other. That has to be the default assumption.

> A separate routing protocol adds a lot of complexity, but I think we
> need it, for better error handling, load balancing and more efficient
> forwarding (by re-routing the message to the new destination, especially
> important if we support binary transport).

Agreed.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/