|Please visit PFIR Forums for ongoing discussions regarding this project and related issues!|
||TRIPOLI Project Press Release|
TRIPOLI: An Empowered E-Mail Environment
Putting E-Mail Users in Control
While Enhancing Security and Controlling Spam
Version of January 30, 2004
Lauren Weinstein ( firstname.lastname@example.org )
PFIR - People For Internet Responsibility
Executive Summary and Philosophy
The Internet in general, and e-mail in particular, have reached a critical set of crossroads where the decisions we make today regarding their structures and operational environments are likely to directly impact billions of persons around the world for decades to come. E-mail, once a toy for technologists, is rapidly becoming integral to all manner of personal, business, governmental, and all manner of other communications in our everyday lives. So it's not surprising that the scourge of unsolicited bulk e-mail and its related scams, frauds, and just plain obnoxiousness is currently in the crosshairs of so many in the global Internet community.
But while so much of the focus has been on short-term mechanisms of spam control of inherently limited effectiveness, it is frequently forgotten that the problems of spam are primarily an artifact of more fundamental inadequacies in our e-mail systems -- systems that were not designed with today's Internet environment in mind.
For example, spam is at its heart a problem because the recipients of e-mail do not in most cases have sufficient control, security, and privacy regarding the e-mail that they receive. However, it would be an egregious error to assume that all users of e-mail have the same concerns or standards regarding e-mail reception decisions. While there are some persons willing to receive fully anonymous e-mail from any source, at the other end of the spectrum we will find individuals, organizations, and others who would prefer to demand total authenticated knowledge of the source and sender of every e-mail message, and who would apply stringent limits on the messages they'd be willing to receive. And of course there will be those individuals and groups who will have different requirements in these regards at different times depending on a variety of circumstances.
While an array of "solutions" for dealing with the problems of spam have been proposed and in some cases implemented, by and large they have either been ineffective, overly limited in their effective scope -- or most worryingly in the case of many current proposals -- of a centralized nature, inappropriately ceding e-mail decision-making, security, privacy, and other control issues to ISPs, rather than to e-mail users themselves.
Tripoli proposes a framework for the compatible resolution of an array of problems associated with e-mail today, including privacy, security, and of course spam, in an integrated fashion. Tripoli would be implemented in a backwards-compatible manner, building upon existing software tools and mail transfer protocols where possible. All Tripoli specifications and protocols will be non-proprietary and freely available for use. Critically, Tripoli is structured in such a manner that decision-making power rests with the individual users of e-mail, rather than on ISPs or other authorities.
Tripoli envisions an e-mail environment where users are empowered to make their own decisions regarding the types of e-mail and the levels of authentication on e-mail senders that they wish to enforce. The Tripoli architecture is decentralized so that authentication and mail categorization decisions can be individually controlled and/or delegated as users wish, without the necessity of locking users into paying for expensive conventional public key certificates.
In addition to the goal of improving e-mail users' control and improving their experiences with e-mail, Tripoli also addresses other fundamental deficiencies in the existing e-mail environment. Privacy and security through sophisticated yet practical encryption systems are considered to be intrinsic capabilities of Tripoli. By taking the novel approach of separating the actual e-mail message itself (including both header and message body) from authentication and related e-mail categorization information -- what Tripoli calls the "PIT" concept -- Tripoli brings with it a number of other important benefits.
E-mail that does not meet individual users' acceptance criteria can be rejected based on analysis of each message's PIT before the possibly voluminous body of the e-mail itself has been transmitted. With the increasing size of e-mail messages that now may include very large attachments, this capability is crucial to avoid the network being saturated with e-mail messages that would otherwise be fully transmitted and received only then to be discarded.
Many users, not wishing to deal individually with the detailed policy and technical details of spam control, authentication, and other Tripoli-related configurations, may wish to delegate some or all of the nitty-gritty technical and policy aspects of these issues to particular outside individuals, organizations, or other entities that are individually trusted in this regard. Tripoli envisions that such delegations (when desired) could be individually selected by users as they see fit depending upon their own proclivities and world views.
In this regard, an important facet of the Tripoli PIT concept is that the decision-making processes regarding mail acceptance, authentication, security, etc. can be safely delegated without exposing the actual content of messages themselves to the delegation entities. Spam control, authentication, and other processing decisions could be made based on the information in the encrypted PITs which must be accepted prior to their cryptographically linked message contents been transmitted. The delegation of authority to decrypt and process message PITs does not necessarily imply the ability to decrypt the associated messages themselves.
Spam control should not require that ISPs be able to decrypt either the body or the headers of their customers' e-mail messages without those users' explicit permission, nor that ISPs should be able to dictate how users choose to route or process their e-mail. It is in the interest of all e-mail users -- regardless of whether they are individuals, businesses, non-profit organizations, governmental entities, or others -- that they be able to fully control how their own e-mail is handled.
Most proposals to alter the architecture of e-mail in an attempt to combat spam, particularly those presented by various ISP and other Internet-related industry groups, generally would impose some sort of "top-down" e-mail control structure on users, dictating how users' e-mail would be handled and the sorts of authentication criteria and requirements that would be imposed. Often these plans would also have the effect of binding users ever more tightly to their particular ISPs, rather than providing flexibility and decision-making capabilities to users themselves.
If we allow e-mail users to be shackled into architectures that are dictated and controlled from on-high, we will have abdicated one of the Internet's most fundamental principles and benefits, that of providing users with the maximum possible flexibility to make their own decisions regarding the ways in which they wish to use the Internet and its applications. Tripoli postulates a possible framework that would preserve this fundamental principle while providing practical solutions to protect both users and the Internet itself not only from spam, but also from the security and privacy specters of today's existing e-mail environment as well.
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 such as viruses and worms, plus 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 frequently result in additional wasted e-mail traffic from the usually unanswered challenge messages and the resulting reject e-mail! 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.
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).
This discussion of Tripoli 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 would be desirable that all e-mail within the Tripoli framework be encrypted by default whenever possible, 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 envisions 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 information and 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 Information Token) 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.
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. Recipients of e-mail will be free to specify varying authentication requirements for different classes of e-mail. For example, it would obviously be reasonable in at least some cases to require a higher level of authentication for received e-mail that involves business communications, as opposed to personal e-mail. It would also be completely possible for users to willingly accept e-mail that has been certified by one or more PCAs as being non-spam, without necessarily requiring that authentication identity information related to that e-mail be provided as well. This same flexible, user-controlled authentication environment will also be highly significant in deterring major classes of e-mail forgeries, scams, viruses, worms, and related vermin.
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.
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.
All PITs considered acceptable by the vast majority of Tripoli-compliant software in use would presumably be digitally signed by one or more designated, trustworthy, third-party entities 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.
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 presumably first need to formally accept that PCA's 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.
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 important that such "anonymous" applications be limited 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. PCAs could be large or small organizations, or even respected individuals. 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: