On 2/1/2004 10:27 AM, Iljitsch van Beijnum wrote:
One approach that may be interesting: today, everyone gets to send
everyone else messages, and every message stands on its own. An
alternative would be to require the sender and the receiver to have
some (trust?) relationship before messages may be exchanged. In such a
setup, relationship establishment would be an integral part of the
Instant messaging services already do this, although they usually also
permit the exchange of messages without a pre existing relationship.
This is one of the alternative trust/policy mechanisms that I envision as
well. It has worked pretty well for ICQ and others, and would be useful
with certain types of email usages (not all of them). So, let's assume
that somebody would want this, and that the mail-ng infrastructure would
need to support it. Let's look at the infrastructure requirements.
First, some caveats:
- ICQ and others partly rely on an admission-control scheme, rather
than a delivery-control scheme. By that I mean, half of the implicit
'security' comes from the fact that an ICQ sender cannot easily send
a message to a person who is not in their address book (it can be
done, but it cannot be done as easily). That part of the control
process is a result of ICQ controlling the client UI. Bootleg or
unauthorized clients are under no requirement to implement the
Internet apps are intended to be developed by a large number of
independent developers. The IETF does not (usually, significantly)
mandate UI considerations. As such, it would be extremely hard to
require any form of admission-control system, and so it could not
be counted on.
- The other half of the filter is in the delivery/fetch sub-system.
ICQ and others have control over the message store, and thus can
do things like delay the display of a message until the user has
chosen to allow it. Rejected messages may be discarded rather
than returned to the sender.
Existing mail models do not have these options. You would need to
implement a negotiation mechanism somewhere between the last-hop
transfer agent the delivery agent, where the mail was queud but
not-quite delivered in order for this to work properly. Requiring
delivery- or disposition-notifications also precludes discarding
messages that are rejected. This is where the bulk of the problem
is, as discussed further below.
- ICQ and others have a single monolithic directory of accounts.
Users can query the directory, review the "business card" objects
in that directory, and add then add the card to the local address
book, or request permission to do so.
Conversely, the email infrastructure does not present any kind
of directory whatsoever, and cannot rely on one. Even if there
was an unavoidable, mandatory directory, it would be federated
and distributed, not monolithic. It could not be easily searched
without a catalog server, and the data in that server could be
outdated, may not carry all of the data (or ACLs), and so forth.
- ICQ and others use a connected model by default, although they
can (and do) support a disconnected model as well (caching the
address book, delivery spooling, and so forth).
Mail must use a default-disconnected model.
Just looking at the major distinctions there (and omitting several minor
ones), it should be obvious that the same seamlessness cannot be provided
in mail. That's not to say that the same mechanism cannot be offered, just
that it will have to be implemented in ways that are fundamentally
different from what the instant messenger crowd can get away with.
There are a huge number of issues to consider when implementing something
like this over email (I started to itemize them but it got so long that
I've yanked the text). For starters, do you reject messages from unknown
senders, temporarily queue the messages until a confirmation (and if so,
do you queue at the delivery server, or at the PC?), what identifier
format do you use (remember that you may not be able to upload a cert or a
vcard at an airport kiosk -- if you even WANT to -- but then you won't be
able to respond to confirmations), what formats do you use to support
legacy clients ("insert identifer between these lines"?) versues formats
to use for modern clients that support the extension (header fields?), and
so forth. Extremely difficult.
In the end, you are probably going to have something where the recipient
can 'confirm' a certain sender as okay to send, with a confirmation
control message being sent to the delivery server that says not to delay
or block messages from that sender (there are other issues here, like
managing confirmations when you are on an airplane), and with a separate
'greeting' message being sent to the original sender that contains your
identifier data. You might also want a separate synchronization protocol
layered on the mail network to keep the address books up to date.
Assuming all of that is what pops out of the design process (which is a
mighty big assumption), what we get is a need for:
- standardized identifiers of some kind
- various control messages
- new MIME types for legacy systems and/or identifier carriage
- layered protocol(s) for the negotiation stuff
- bunch more stuff
and all of that is so you can implement a distributed greylist extension
in your client that can talk to your local delivery server. All such
services would have the same sorts of demands -- we're really talking
about a generic process-to-process tranport service between disconnected
terminal nodes. We should be looking at the minimum stuff needed to
facilitate the development of these distributed applications, which means
data formats, protocols, routing, and so forth.
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/