TRIPOLI -- An Empowered E-Mail Environment Putting E-Mail Users in Control While Enhancing Security and Controlling Spam

[Dave Farber <dave () farber net>]

An Empowered E-Mail Environment
Putting E-Mail Users in Control
While Enhancing Security and Controlling Spam

Overview
Version of May 7, 2003

Lauren Weinstein ( lauren () PFIR ORG )
Co-Founder
PFIR - People For Internet Responsibility
WWW.PFIR.ORG

This document ( http://www.pfir.org/tripoli-overview ) is a work in
progress, and is subject to change at any time as this project develops.

Background 

The e-mail systems and environments currently in use throughout the
Internet, and to a great extent on intranets and local systems, are in many
respects based upon software and architectures that were initially defined
in the early days of the ARPANET more than 30 years ago. The relatively low
volume and essentially benign environment of ARPANET e-mail were very much
different from the situation that typical e-mail users face today.

Problems of e-mail spam, forgery, scams, nasty executable attachments, and a
range of other costly, annoying, and productivity-decimating aspects of
e-mail have become increasingly prominent as the Internet has been
commercialized and grown rapidly to its current ubiquitous state.

Underlying structural and procedural limitations in the current e-mail
environment thwart most attempts to solve many of these problems. For
example, most anti-spam filters simply file spam away for review after it
has already been delivered, allowing massive delivered spam volumes to
continue growing unabated. Attempting to assign a cost to some or all
messages sent -- as a proposed anti-spam measure -- appears unworkable from
a practical standpoint and would bring a range of undesirable consequences.
Other anti-spam techniques, such as "challenge-response," suffer from a
variety of usability problems and result in additional wasted e-mail traffic
from the challenge and response messages. Meanwhile, most current and
proposed anti-spam laws have been so poorly structured that they not only
are unlikely to significantly reduce spam, but also may actually increase
its volume by "legitimizing" aspects of the practice.

Additionally, reasonable control over critical e-mail functionalities has
been difficult for e-mail users themselves to assert. The lack of basic
security (especially the lack of generally implemented encryption and even
rudimentary authentication) has left most users' e-mail highly vulnerable.
Increasingly, Internet service providers (ISPs) are asserting short-sighted
controls and restrictions over the methods and means that users may employ
in transmitting and receiving e-mail.

For example, many ISPs require users (especially typically residential
"dynamic IP" users) to route all of their e-mail through the ISP's servers,
introducing an additional layer of inflexibility, potential failures, and
security violations. An ISP's anti-spam efforts also can have the effect of
greatly reducing users' e-mail flexibility. For example, blocking of SMTP
(TCP/IP port 25) is not only a very poor anti-spam procedure, it also
prevents e-mail users from establishing direct e-mail connections to other
sites and operating their own e-mail message transfer agents (MTAs)
independent of their ISP's often overloaded, limited, and poorly-secured
servers. 

Introducing "Tripoli"

The time has come for defining a new architecture and environment for e-mail
transmissions. This architecture, while primarily designed for use on the
Internet, would also be applicable to intranet and local e-mail
environments. This architecture would require no breakthroughs and could be
built using existing functionalities already present in the public domain or
otherwise available for free use.

To a significant extent, the environment envisioned could be implemented as
extensions to existing software systems. For example, software systems such
as "Sendmail", "Exim", MS Exchange Server, and other MTAs, could be extended
to provide the functionality required by this environment. Similarly,
existing message formats and underlying transport mechanisms as defined by
various relevant RFCs (RFC 822, etc.) could be used and extended as
necessary. 

This document describes an e-mail architecture and its operating environment
herein referred to as "Tripoli" (from "Triple-E", for Empowered E-mail
Environment). 

The discussion of Tripoli that follows is not intended to propose any
specific software packages, products, or services, nor is it an
implementation guide. Rather, it is hoped that this overview may lead to the
development of practical solutions to a range of e-mail problems, that can
be effectively implemented by the global open source community.

Tripoli is predicated on the concept that the primary empowerment of e-mail
should be placed in the users of e-mail systems, not in governments or ISPs.
And more specifically, the receiver of e-mail should have greater
empowerment and control than the sender of e-mail, in nearly all situations.
The Tripoli environment visualizes a "parallel" e-mail system that could
operate alongside the existing SMTP e-mail environment for the indefinite
future. Users would be free to receive and send e-mail in either or both
environments. ISPs/relays would similarly be free to choose as to which of
these environments (or both) that they wished to support. It is likely that
over time there will be a migration to the Tripoli environment and a
withering of the existing e-mail environment, but this is not required to
gain many of the benefits of Tripoli.

Tripoli would be implemented in a phased approach that would allow the use
of unmodified user e-mail software during the transition period. It is
anticipated that all e-mail within the Tripoli framework would be encrypted
by default, initially at least within the MTA to MTA level (irrespective of
any IP-level encryption that may or may not be available). To the extent
that users do not use external relays, all Tripoli traffic including message
bodies, headers, and envelopes could be encrypted. In situations where
external relays are in use, the message envelope will need to be
unencrypted. 

Unmodified user e-mail software may be unable to receive or send encrypted
Tripoli e-mail directly, but Tripoli-enabled relays could send and receive
fully encrypted and certified Tripoli traffic between site MTAs. Over time,
as users' software is enabled with the appropriate Tripoli encryption and
authentication capabilities, end-to-end transparent and automated encryption
in this environment would become standard.

The Tripoli environment anticipates a flexible ports definition system
designed to thwart unreasonable attempts to inappropriately control users'
e-mail. In particular, the method of choosing Tripoli e-mail communication
ports would be fully negotiated, even falling back to "http" port 80,
"https" port 443, or other generally accessible ports as necessary, and
employing difficult to block protocol methodologies. It is a basic tenet of
Tripoli that control over e-mail must be imparted to users and not ISPs, so
long as users are not genuinely interfering with ISP operations.

Welcome to the "PIT"

A key aspect of the Tripoli environment is the concept of a third-party
certified, encrypted authentication token that would be cryptographically
linked with every e-mail message. Within the Tripoli architecture, this
token is referred to by the acronym "PIT" (Payload Identity Token,
henceforth referred to as "Pit") and is at the core of Tripoli. The Pit
contains all of the certified information necessary to authenticate the
associated message payload. The sorts of information within the Pit include
authenticating identity information, special or extra capability data, the
level of identity authentication in force for this particular Pit and its
associated message payload, and potentially a wide range of other related
data to be defined in a continually extensible manner.

The Tripoli Pit concept does not require that all senders' messages be
authenticated to the same level. It would be completely possible for a
sender to generate a message (and associated Pit) that was not fully
authenticated or that even was anonymous (within the bounds of associated
MTAs/relays and the underlying Internet or local operating system
environments to offer anonymous messages or transport parameters).

It is recognized that there are important situations where it may be highly
desirable to receive e-mail from poorly-authenticated or completely
unauthenticated sources, for example, in the case of a whistleblower
submission address, government agencies, or a range of other situations.

Under the Tripoli framework, receivers of e-mail could choose to accept such
messages, but they would not be required to accept messages that did not
meet the authenticated identity requirements that they have specified.

This level of control would extend upwards in a fully-operational Tripoli
e-mail environment from user systems to both sending and receiving system
MTAs and relays. ISPs operating Tripoli-capable relays might choose to
prohibit the sending or reception of e-mail that did not meet specific
authentication criteria (either generated by their subscribers or directed
to their subscribers), most typically as an anti-spam measure.

Note however, that users would always be free under the Tripoli framework to
operate their own MTAs to establish direct end-to-end e-mail connections,
which would establish their own levels of acceptable authentication and
related parameters, irrespective of an ISP's choices in this regard.

For example, if an ISP implements authentication rules that effectively
prohibit spam, their subscribers who still wish to receive spam e-mail (for
some perverse reason) would still be able to do so by operating their own
MTAs and not making use of the ISP's relays, assuming that any legal,
Tripoli-certified spam senders actually existed (which in the evolving
anti-spam legal environment may be a doubtful proposition).

Pits and their associated messages would be delivered to MTAs and/or users
as two separate but connected transactions. The Pit for a given message
would be delivered first, then (on the already open TCP/IP connection) the
associated message would normally be transmitted. Rejection of a given Pit
by a recipient would trigger the immediate end of the connection, and the
actual associated message would in this case never be sent to the recipient,
and so would not consume the network bandwidth and system resources that
would otherwise have been devoted to sending the message data or processing
that message data by the receiver.

The bottom line is that users will always be able to use Tripoli to define
the levels of authentication they require in the e-mail that they are
willing to receive, and to operate their own MTA environments if they so
desire. The Tripoli Pit authentication and certification (see below)
structure will help ensure that Tripoli e-mail relays can be operated safely
by both ISPs and individuals without the spectre of problems created by open
or misconfigured relays that are present in the currently existing e-mail
environment. 

Pit Certification 

For Tripoli Pits to be useful resources for e-mail processing and handling,
it is absolutely critical that they be certified by external, third-party
certification entities. Without certification by trusted third-parties, such
an authentication system would be useless since it could not be trusted to
provide accurate and valid authentication data.

It is anticipated that all Pits considered acceptable by the vast majority
of all Tripoli-compliant software user would be digitally signed by one or
more designated, trustworthy, third-pary authorities who would be delegated
the power to certify the validity of identity and other relevant information
within Pits. 

In a fully operational Tripoli environment, it is likely that various
encrypted certification information relating to the generation and
processing of Pits might be cached in various locations around the Internet
for reliability and performance purposes.

It is anticipated that in most cases, in order for the sender of an e-mail
message to become initially certified by a Pit Certification Authority
(PCA), the sender would need to first formally accept Terms of Service (ToS)
that may well prohibit the sending of spam, and equally importantly, would
authorize the certification authority to "downgrade" the sender's
authentication certification in the case of spam or other ToS violations.

It is also expected that PCAs operating in a responsible manner will make
reasonable efforts to verify the provided e-mail address and identity of
applicants, avoid issuing many multiple accounts to a single entity that
could be used for spamming, and take other reasonable steps aimed at greatly
reducing the likelihood of e-mail abuse. PCAs should also have (probably as
part of their ToS) an explicit written policy regarding the handling of spam
abuse reports and the procedures for dealing with spammers or other e-mail
abusers (e.g., Pit downgrades, etc.) that fall within their sphere.

It is anticipated that some PCAs may wish to establish mechanisms
(third-party or proxy registrations, etc.) for dealing with certification
applicants with special needs for identity protection (e.g., human rights
groups operating in "hostile" areas, etc.). However, it is crucial that such
"anonymous" applications be limited only to those with a verifiable and
genuine need, and that the manner in which such "anonymous" registrations
are handled is fully spelled out in public ToS documents.

If a previously certified sender was found to be sending spam in violation
of a ToS that prohibited such material, the related PCA would be able to
downgrade all Pits certified by that PCA which are generated by that sender.
The downgraded Pits would indicate that sender's violations and enable
Tripoli e-mail receiver systems to make appropriate decisions regarding the
acceptance of further e-mail from that sender. In extreme cases, a PCA may
decide (if allowed by their ToS) to discontinue any further certification of
an offender's Pits.

It is of course likely that e-mail from senders whose Pits have been
downgraded for spamming would be blocked by most Tripoli MTAs/relays and
users. Spammers would of course be free to continue using the existing
non-Tripoli SMTP-based non-authenticated e-mail network to the extent that
they are able to do so and remain unprosecuted. Their potential audience
through that channel will presumably decline precipitously over time.

It is not planned to try mandate that PCAs operate in any particular manner,
though recommendations for best practices are likely to be issued. In
theory, it might be possible for almost any entity to set itself up as a
PCA, and attempt to operate in a slipshod manner with a poor or nonexistant
ToS and other undesirable operational practices. Similarly, spammers could
theoretically try to self-certify their own Tripoli Pits.

In practice, PCAs, spammers, or anyone else operating in such antisocial
manners would find their influence and functional capabilities to be
extremely limited. Only those Pits that have been certified on a third-party
basis by well-known PCAs who act responsibly will be generally accepted by
the user community and so be enabled as valid authorities in typical user
and relay Tripoli configurations. Still, relays and users who really wished
to do so would still be free to accept Pits from other, unsavory sources.

Again, the overriding principle in Tripoli is that the receiver of e-mail
makes the decisions and decides which messages they are willing to receive.
Senders of e-mail are free to try proceed as they wish, but their ability to
have their messages transmitted, received, and read will be ultimately
controlled by e-mail receivers and readers.

The economic basis under which Tripoli PCAs might operate is not a focus of
this document. One possible funding model might be for the senders of e-mail
messages to pay a small flat-rate annual fee for the privilege of having
their Pits certified. But there is no requirement that PCAs be funded in any
particular manner, nor that they be for profit, nonprofit, or any other
particular business structure. Successful PCAs, whether defined in terms of
making money, providing free or charitable public e-mail services, or
whatever, will be determined by the community of e-mail receivers who will
have the final say over which PCAs will be successful, and which will be
largely or completely ignored.

Making Tripoli Happen

The preceding lays out only the very basic framework of the conceptual
Tripoli Empowered E-mail Environment. This structure could be extended and
expanded greatly in many ways to provide all manner of authentication,
assurance, and user controls over their e-mail -- key functions that have
been missing from the existing Internet and related e-mail systems -- while
also providing a means for the control of obnoxious materials such as spam.

The actual implementation of Tripoli systems in the phased approach
suggested should be relatively straightforward at least in its initial
stages. Obviously, as extensions and extensibility are exploited, this could
become a decidedly nontrivial project, but ultimately very much worth the
effort. A framework such as this may provide the only practical mechanism on
which to build e-mail systems that are useful and productive for their users
rather than increasingly obnoxious nightmares.

Unless the open source communities and related public-interest organizations
take up this challenge, we will all likely be faced with mandated e-mail
structural changes which will be proposed by ISPs, national governments, and
other entrenched interests, which will almost certainly be in direct
conflict with the best interests of the public at large.

None of the above is presented as absolute answers to the extremely complex
and controversial problems surrounding e-mail. This is merely the beginning
of a process. However, it is hoped that the Tripoli concept can contribute
to a better e-mail future. Your comments, questions, and discussion are
eagerly invited at:

tripoli-info () pfir org

Thank you. 

-------------------------------------
You are subscribed as interesting-people () lists elistx com
To manage your subscription, go to
  http://v2.listbox.com/member/?listname=ip

Archives at: http://www.interesting-people.org/archives/interesting-people/