MIT LCS: Human Impact: Perspective *Pages 1--19*
The Design, Implementation and Operation 
of an Email Pseudonym Server 


David Mazi` eres and M. Frans Kaashoek 
MIT Laboratory for Computer Science 
545 Technology Square, Cambridge MA 02139 


Abstract 
Attacks on servers that provide anonymity generally fall into two categories: attempts to 
expose anonymous users and attempts to silence them. Much existing work concentrates on 
withstanding the former, but the threat of the latter is equally real. One particularly effective 
attack against anonymous servers is to abuse them and stir up enough trouble that they must 
shut down. 
This paper describes the design, implementation, and operation of nym. alias. net, a server 
providing untraceable email aliases. We enumerate many kinds of abuse the system has weath-ered 
during two years of operation, and explain the measures we enacted in response. From 
our experiences, we distill several principles by which one can protect anonymous servers from 
similar attacks. 


1 Introduction 
Anonymous on-line speech serves many purposes ranging from fighting oppressive government 
censorship to giving university professors feedback on teaching. Of course, the availability of 
anonymous speech also leads to many forms of abuse, including harassment, mail bombing and 
even bulk emailing. Servers providing anonymity are particularly vulnerable to flooding and 
denial-of-service attacks. Concerns for the privacy of legitimate users make it impractical to keep 
usage logs. Even with logs, the very design of an anonymous service generally makes it difficult 
to track down attackers. Worse yet, attempts to block problematic messages with manually-tuned 
filters can easily evolve into censorshipó people unhappy with anonymous users will purposefully 
abuse a server if by doing so they can get legitimate messages filtered. Nonetheless, careful design 
can make a large difference in how well an anonymous server resists abuse. 
This paper describes our experience in designing, implementing, and operating nym. alias. net, 
an email pseudonym server. Nym. alias. net allows anyone to create an email alias without revealing 
his identity. Such an alias, called a nym (short for pseudonym), appears as an ordinary email 
address to the rest of the world. 


>>From Proceedings of the 5th ACM Conference on Computer and Communications Security, 1998. 


1 
1
Anonymous services get used for more and less popular reasons. Protecting unpopular speech 
is one of the fundamental purposes of anonymity. However, certain types of use can either force 
an anonymous server to shut down or else destroy its utility to other people. We classify such 
use as abuse. Our experience with nym. alias. net shows that controlling abuse is as important as 
protecting the identities of anonymous users. Both considerations should play a central role in the 
design of an anonymous server. Moreover, since people invent very creative forms of abuse, one 
must actually deploy an anonymous server to measure its viability. 
This paper tackles the question of how to build anonymous servers that can survive in the real 
world. Our ideas apply equally to systems based on more advanced theoretical work (such as [1, 
3, 6, 10, 12]), but such systems would likely not work with off-the-shelf software. Consequently, 
they would draw fewer users and fewer attacks of the kind we are concerned with studying. 


1.1 History and usage 
Nym. alias. net began operation in June 1996. To facilitate use of the system, we soon contributed 
support for it to the premail package, which provides encryption for popular Unix mail readers. 
Since then, others have built several DOS and Windows programs for managing nyms. Two other 
sites currently run our server software. 
The anonymity of our users and the lack of mail logging make it impossible to know exactly 
how heavily the system is used. However, the number of active accounts has remained between 
2,000 and 3,000 over the past 18 months. Statistics from the back end of our server suggest that the 
nyms on the system receive over 1,000 email messages per day. From the size of a replay cache the 
system keeps, we estimate that users send over 500 messages per day from nym addresses. Finally, 
Usenet search engines reveal many news postings from nym. alias. net addresses covering a large 
number topics. 
We sent a survey to users of nym. alias. net asking them why they use the service. The sur-vey 
encouraged people to answer as frankly as possible, and to reply anonymously. We received 
over 200 replies listing a wide range of uses. The reasons can broadly be categorized in order of 
decreasing need for privacy: 


 In countries with oppressive governments, people use nyms to make public political state-ments, to hide the identities of their
 correspondents, and to encrypt the contents private mail (particularly when exchanging mail with people who don't use encryptio
n). 


 In more tolerant political environments, many people use nyms for purposes that might other-wise lead to embarrassment, harassm
ent, or even loss of their jobs. These include discussing alcoholism, depression, and being a sexual minority, as well as meetin
g people through per-sonal 
ads. A few people said they had used nyms to blow the whistle on illegal activities. 
Others express radical political views through nyms, while still others use them to fight 
harmful cults. Finally, a small minority of respondents admitted to using nyms for more 
legally marginal purposes, including discussing marijuana cultivation, publishing programs 
to exploit security holes, virus development, and software piracy. 


 In companies that monitor email, some people report using nym addresses to encrypt all mail they receive before it enters the c
ompany. Nyms also keep the addresses of correspondents 
2 
2
out of system log files. Some people similarly use nyms because they distrust their Internet 
service providers. 


 Some people worry that seemingly innocuous Usenet posts will have unforeseen future ram-ifications. One response described a jo
b interview at which the candidate's Usenet posting became a topic of discussion. 


 Some nym users simply want their statements to be judged on their own merit. These peo-ple fear their reputations would bias re
aders for or against any messages bearing their real addresses. 
 Finally, a surprisingly high number of people just use nym. alias. net for a free email ad-dressó either to avoid junk email by
 changing addresses frequently, or to keep a permanent address when switching Internet service providers. The fact that people u
se nyms without 
needing the privacy speaks well for the reliability of the system. 
Of course, though we asked users to be frank, those who abuse the service had little incentive to 
answer our survey. 


1.2 Design goals 
We designed nym. alias. net with three goals: to build a real system that would see real use (and 
abuse) by people outside of computer science research, to protect the secrecy of users' identities in 
the face of compromised servers, and to provide a robust email service people can rely on. 
We achieved the first goal, attracting users, by building on existing infrastructure. To use 
nym. alias. net, one only needs a copy of PGP [15], the most widely used encryption program. 
Moreover, nym. alias. net exploits a preexisting network of anonymous remailersó servers that strip 
identifying information from mail and forward it, after optionally decrypting, encrypting, or de-laying 
it. While a clean-slate pseudonym server design would have permitted greater security at an 
equal level of deployment, it would also have enjoyed considerably less acceptance. 
To achieve the second goal, preventing compromised servers from disclosing users' identities, 
nym. alias. net uses the anonymous remailer network as a mix-net [4]: It forwards mail received 
for a nym to its final destination through a series of independently operated remailers. Only by 
compromising multiple remailers can one uncover the full path taken by such a message. Thus, 
even the administrators of the nym server have no way to expose the identity of someone making 
proper use of the system. 
The third goal, reliability, we achieve through solid software and redundancy. The nym. ali-as. 
net software itself is carefully written and does not lose mailó a claim substantiated by people 
using the server for permanent email addresses. One of the authors of this paper actually uses a 
nym as his primary email address for all correspondence about the server. Reliability does become 
more of a challenge when messages travel through many remailers. However, as described later in 
Section 3.3, nym. alias. net can lessen this problem with redundant messages. 


3 
3
1.3 The rest of this paper 
In the rest of this paper, we describe the nym. alias. net pseudonym server and few related services 
the machine provides. We then discuss several kinds of abuse nym. alias. net has weathered. In 
each case, we explain how the machine fared and what changes, if any, we made in response to 
the abuse. Finally, we classify the abuse of anonymous services into three general categories, and 
suggest principles by which one can develop solutions. 


2 Related work 
Our work on nym. alias. net was largely motivated by the problems of previous unpublished anony-mous 
mail systems. A good summary of past and present systems (including nym. alias. net) can be 
found in [8]. 
The first email pseudonym system open to the public was anon. penet. fi. Penet kept a database 
linking real and pseudonymous email addresses. It replaced a user's real email address with her 
pseudonym in outgoing mail, and routed incoming mail received for a pseudonym back to the 
appropriate address. 
Unfortunately, penet did not use encryptionó all messages went over the network in cleartext 
and were vulnerable to eavesdropping. Moreover, by design, the operator of the service knew the 
identities of all users. Only one machine needed to be compromised to violate the privacy of every 
user on the system. Penet also severely restricted the size and number of messages any given user 
could send, and imposed a delay of several days on any pseudonymous communication. These 
properties protected the system from abuse at the cost of usefulness. Finally, penet automatically 
provided double-blind communication. This could potentially cause users to send pseudonymous 
email unknowingly (particularly to pseudonymous mailing list subscribers), and thus to reveal their 
identities through the context of a message not intended to be pseudonymous. 
Penet shut down most of its operation when the operator faced the risk of having to turn the 
user database over to authorities. It later shut down completely when it became overloaded with 
unsolicited commercial mail. 
Type-1 anonymous remailers, also called cypherpunk remailers, were developed to address 
many shortcomings of the penet system. Type-1 remailers have public keys with which incoming 
messages can be encrypted. A message can be sent through a chain of type-1 remailers, having 
been successively encrypted for each one. Each remailer in a chain knows only the identity of 
the previous remailer and the next. Type-1 remailers alone serve mostly for anonymous, rather 
than pseudonymous mail. However, they do allow messages to be sent to unknown destinations. 
As described later, nym. alias. net exploits this property to provide email addresses to users whose 
identities it does not know. 
The alpha. c2. org pseudonym server provided untraceable pseudonyms through type-1 remail-ers, 
and was part of the inspiration for nym. alias. net. However, alpha was vulnerable to replay 
attacks, did not use public keys to identify pseudonyms, did not provide forward secrecy of mes-sages 
received for pseudonyms, could not tolerate an unreliable type-1 remailer network, developed 
serious reliability problems of its own under high load, and finally was shut down for using too 
much CPU time. 


4 
4
Type-2 or mixmaster remailers [5] offer several improvements in security over type-1 remail-ers. 
These improvements in general make hop-by-hop traffic analysis considerably harder. They 
include fixed size messages, replay detection, and better reordering of messages at remailers. Type-2 
remailers do not, however, allow replies to unknown destinations, and thus cannot be used to 
provide pseudonyms. 
Experimental versions of the type-2 remailer have incorporated hash cash [2], a scheme that 
deals with service abuse; it allows providers of unmetered Internet services to charge for usage 
in burnt CPU time. Hash cash requires users of a service to find partial hash collisions under a 
cryptographic hash functionó an expensive operation that can be efficiently verified. Hash cash 
has the potential to limit certain kinds abuse to free anonymous servers. 
Babel [9], an anonymous remailer developed at IBM Zurich Research Laboratory, incorporates 
a number of features to foil traffic analysis. Unlike nym. alias. net, Babel provides a distributed 
architecture with no central server maintaining nyms; instead, each email message includes spe-cially 
encoded instructions for how to respond through the remailer network. The disadvantage of 
this approach is that a person who receives such email must to understand how to use encryption 
software. Nym. alias. net has no such requirement. Accounts at our server behave like regular email 
accounts. Users responding to email from a nym account can do so using a standard mail reader. 
Our survey shows that many users consider this an important feature. 
Recently, some systems have provided anonymity in areas other than email, including interac-tive 
network connections [14] and web browsing [13]. Anonymous web browsing should allow 
pseudonymous email though web-based email providers. We don't know how many people are 
using it for that purpose, or what kind of abuse, if any, these systems have suffered from. 
An interesting question is whether users have the right to anonymity. The question is complex 
and its answer is likely to vary from country to country. In the Unites States, there is no law making 
services such as nym. alias. net illegal. In fact, there have been a number of court cases that link 
anonymous speech directly to freedom of speech, in particular for political anonymous speech. 
However, whether the U. S. constitution directly protects anonymous communication is an open 
legal question. This paper does not address this question; we point the reader to Froomkin [7] on 
the legal issues of anonymous on-line speech. 


3 Pseudonym server 
This section describes the workings of the pseudonym server. The nym. alias. net help file [11] 
gives more complete details of the system's operation, including down-to-the-byte descriptions of 
message formats. For those wanting even more detail, we have always made the system's source 
code freely available for use and inspection. 
Nym. alias. net uses a type-1 remailer network similar to Chaum's mix-nets [4]. A mix is a 
computer that forwards batches of messages, using encryption to conceal the relationship between 
incoming and outgoing ones. Mixes can be cascaded so that multiple mixes must be compromised 
to expose the path of a message. While type-1 remailers do not offer the full security of mixes, 
they do permit the nym server to send mail to users without knowing their real email addresses. 


5 
5
3.1 Nymserv 
The pseudonym server consists principally of the program nymserv, which is invoked by the system 
mail software (e. g., sendmail or qmail) whenever it must deliver mail to an address at nym. alias. net. 
Nymserv, in turn, remails messages addressed to nyms in such a way that they will eventually reach 
the owners of those nyms. A few reserved addresses cause special processing of incoming mail. 
For instance, to send email from a pseudonymous address, one sends it through send@ nym. a-lias. 
net. Requests to create and delete nyms go to config@ nym. alias. net. Of course, 
any mail sent to an unused address at nym. alias. net will bounce as usual. 
Nymserv keeps three pieces of information on file for every nym: a public key, a reply block, 
and some configuration data. The public key authenticates messages from the owner of the nym. 
All mail sent from a nym address must be signed by that nym's private key, as must requests to 
delete a nym or modify its configuration settings. By default, nymserv also encrypts any mail 
sent to a nym with that nym's public key. This ensures the forward secrecy of remailed messages; 
someone who compromises the server and learns that a nym forwards mail to a news group still 
cannot recover the contents of previously received messages. 
The reply block contains instructions for getting mail from the nym server to the owner of a 
nym. These instructions are successively encrypted for a series of type-1 remailers in such a way 
that each remailer can only see the identity of the next hop. The innermost encrypted instructions, 
visible only to the last remailer, contain the final destination of mail sent to a nym. 
While people generally choose their real email addresses as a final destination, they can alter-natively 
use broadcast messages pools such as the Usenet group alt. anonymous. messages. Sending 
mail to a newsgroup that propagates to so many machines makes it virtually impossible to track 
a user down from a reply block alone (though most news servers keep logs that will permit one 
confirm a guess about the identity of a nym). 
Thus, one need never communicate directly with nym. alias. net to use a pseudonym. Digital 
signatures prove the authenticity of messages to the server, allowing them to come from anywhere. 
In particular, requests to create nyms and send mail from them usually arrive through a chain of 
anonymous remailers. Likewise, mail sent sent from the server to a user leaves through a chain of 
anonymous remailers. The nym server administrators have no easy way to find the real identity of 
someone using the service in this way. 


3.2 Reply block details 
Reply-blocks use type-1 remailers to conceal the destination of mail messages. A type-1 remailer 
message begins with a preamble specifying the email address of a next hop. This preamble can also 
contain a delay time, a symmetric encryption key, and mail headers like Subject and Newsgroups 
to paste into the remailed message. Type-1 remailers strip identifying headers from any mail they 
receive. Then, depending on the preamble, they can conventionally encrypt everything after a 
marker line, paste mail headers, and delay messages. Finally, they forward messages onto their 
next hops. Every type-1 remailer has a public key. The beginning of a type-1 remailer message or 
the entire message may be encrypted with the remailer's public key. This allows the nym server to 
construct valid type-1 messages by prepending an encrypted reply block to a mail message received 
for a nym. Symmetric encryption below the reply block makes it difficult for eavesdroppers to 


6 
6
correlate incoming and outgoing messages at a remailer. PGP is used for both the public-key and 
symmetric key encryption. 
Figure 1a shows the process of creating a reply block with two hops. The user encrypts her 
real email address, usr@ a. com, and a symmetric key, "key1," with the public key of remailer 
rem@ b. edu. She then prepends the address of that remailer and another key, "key2," to the 
resulting cyphertext and encrypts that with the public key of a second remailer, rem@ isp. nl. 
Finally, she prepends rem@ isp. nl and a third key, "key3," to the second cyphertext. In all cases 
she has specified a random delay of up to one hour. 
Figure 1b shows the encryptions undergone by a message delivered to a nym with this reply 
block. Nymserv always starts by adding some explicit context to any message it receives, including 
the name of the pseudonym receiving the message (not necessarily obvious from the message 
itself), the date, a unique identifier, and a disclaimer. It then digitally signs the message with its 
own private key and encrypts the message with the nym's public key. It prepends the reply block 
to the resulting cyphertext, and feeds the result to a type-1 remailer running on the local machine. 
That remailer then super-encrypts the message with "key3," randomly delays it for up to an hour, 
and forwards it to rem@ isp. nl. rem@ isp. nl in turn super-encrypts the message with "key2," 
delays it, and forwards it to rem@ b. edu, which likewise super-encrypts the message using "key1" 
and sends it on to the user. 
Figure 1c shows the actual data sent across the network when a nym with this reply block re-ceives 
mail. One can immediately see that the security of the system is far from optimal: Identical 
reply block cyphertexts travel across the network each time a particular nym receives mail. Mes-sages 
crossing the network have non-constant size. Nothing prevents message replays or reuse of 
inner reply block cyphertexts; an attacker can grab a reply block cyphertext off the network and 
reuse it to send either a huge message or a large number of small messagesó facilitating hop-by-hop 
traffic analysis in either case. This was the price we paid to attract real users. 
Nonetheless, the secrecy of nyms doesn't entirely depend on type-1 remailers. One can still 
achieve strong privacy through broadcast message pools. Thus, nym. alias. net does permit virtually 
untraceable nyms, albeit inefficiently and inconveniently. More importantly, most attacks on reply 
blocks, though theoretically possible, are beyond the means of the nym server operators. Even in 
cases where we might actually have wanted to trace a nymó for instance when a very distressed 
sounding teen-ager discussed suicide in a newsgroupó revealing the person's identity was never an 
option. Thus the weaknesses of type-1 remailers have probably had little effect on our experience 
of running the server. 


3.3 Reliability, replay and redundancy 
Nym. alias. net's pseudonym server does not lose mail 1 . The machine has a good network con-nection 
and high uptime, and the nymserv software has proven robust. The same cannot, unfor-tunately, 
be said of all anonymous remailers. Remailers come and go, often with little warning. 
A large number of independently run remailers give users more options for remailer chains, but 


1 We must mention a single, painful, and glaring exception to this statement. An Internic billing error for alias. net 
led to the disappearance of the entire domain for a period of several weeks. The authors have no affiliation with 
alias. net beyond having use of the nym. alias. net host name, and consequently could do nothing to hasten resolution of 
the problem. We nonetheless continue to believe that nym servers should in principle be highly reliable. 


7 
7
PGP encrypt for rem@ b. edu 
PGP encrypt for rem@ isp. nl 


Anon-To: usr@ a. com 
Latent-Time: +1: 00r 
Encrypt-Key: key1 Latent-Time: +1: 00r 


replyblock-1 


Anon-To: rem@ b. edu 
Encrypt-Key: key2 
Latent-Time: +1: 00r 
Anon-To: rem@ isp. nl 


Encrypt-Key: key3 
replyblock-2 


a. Steps performed by a user to construct a reply block with two hops 


Message 


cyphertext-A 
sign, encrypt w. 
nym public key 


PGP encrypt w. 
symmetric key3 


PGP encrypt w. 
symmetric key2 


cyphertext-A 


cyphertext-B 
PGP encrypt w. 
symmetric key1 


cyphertext-B 


cyphertext-C 


Pseudonym Server: rem@ isp. nl: rem@ b. edu: 


b. Encryptions performed on messages at each remailer 
cyphertext-A cyphertext-B 
replyblock-1 replyblock-2 


Pseudonym Server rem@ isp. nl rem@ b. edu usr@ a. com 


cyphertext-C 


c. The actual data that traverses the network 


Figure 1: Forwarding messages to anonymous users 
8 
8
not everyone willing to run a remailer can do so reliably. ISPs sometimes shut down customers' 
remailers when controversial usage surfaces or traffic levels get too high. "Disposable remailers" 
running on free email services like juno. com periodically exceed their mail quotas. Disks fail in 
cases where operators avoided backing up private keys. Machines crash when remailer operators 
have gone on vacation and no one else has access to the machine. In short, what's good for security 
may hurt reliability. Pseudonym servers should therefore tolerate an unreliable remailer network. 
Two types of mail risk getting lost in the remailer network: messages from users to the nym 
server, and those from the nym server to users. Redundancy can address both risks. Nymserv keeps 
a replay cache to thwart certain attacks, but this cache additionally allows users to send duplicate 
copies of any message to the nym server. Nymserv also permits pseudonyms to have multiple 
reply blocks, which lets users receive several copies of mail to their nyms through distinct chains 
of remailers. 
Attackers may try to replay old configuration messages or cause duplicate copies of outgoing 
mail. Nymserv consequently keeps a replay cache of all such messages (i. e. anything sent to 
config@ nym. alias. net or send@ nym. alias. net). Both types of message carry PGP 
signatures. Nymserv caches the MD5 hash of these signatures to detect replay. It will process 
the same message twice only if the user has signed it twice. Fortunately, the replay cache need 
not grow without bounds. PGP embeds a date and time in every signature. Nymserv discards 
incoming messages with signatures older than a week and those dated too far in the future. It can 
therefore delete any MD5 hashes corresponding to signatures more than a week old. Note that 
configuration requests and and outgoing mail, while both signed by the user, have distinct message 
formats nymserv cannot confuse. A "config" or "send" request delivered to the wrong address does 
not affect the replay cache. 
As mentioned above, nyms can have multiple reply blocks. To increase reliability, more than 
one reply block can deliver mail to the nym's owner. Since nymserv adds a unique identifier to 
each message it remails, client software can easily discard the duplicate messages generated by 
such a scheme. Of course, not all reply blocks have to go to the nym's owner. Some may simply 
discard mail after passing it through a chain of remailers. Such "fake" reply blocks can increase the 
average number of remailers an attacker must compromise without incurring the reliability penalty 
of lengthening the real reply block. 


3.4 Miscellaneous features 
Users may abandon nyms without deleting them, or even lose nym private keys. In such cases the 
nyms may nonetheless continue to receive mail. Indeed, they will likely do so given the pervasive-ness 
of unsolicited commercial mail. To detect abandoned accounts, then, nymserv keeps track of 
the date on which it last verified a valid PGP signature by each nym's private key. We consider an 
account idle if we see no evidence of the existence of its private key for 90 days. Idle accounts 
receive a warning message every 10 days for 30 days, after which the software deletes them. 
Finally, nymserv also functions as a finger daemon. Nym owners can optionally publish their 
nym PGP keys in their finger information. 


9 
9
3.5 Related servers 
While nymserv provides the core functionality of nym. alias. net, several related servers on the 
machine deserve mention. A type-1 remailer, remail, functions as the back end to nymserv and 
the first hop in every reply chain. A mail-to-news gateway, mail2news, allows posting to news 
groups from nyms and anonymous remailers (though it has plenty of non-anonymous users, too). 
smtpd, a custom-built mail server, handles connections from remote mail clients and helps control 
abuse. Finally, nym. alias. net runs an ordinary type-2 remailer. This remailer processes over 500 
messages a day and can be used as a final hop for mail sent to config@ nym. alias. net and 
send@ nym. alias. net. 


4 Attacks and Abuse 
Attacks on anonymous servers generally fall into two categories: attempts to expose anonymous 
users and attempts to silence them. Most existing work on such systems concentrates on with-standing 
the formeró the more important of the two to resist. In practice, however, the threat of 
the latter is equally real. Users of an anonymous service often express unpopular opinions, which 
incite efforts to silence them or even shut down the service. One of the most effective means of 
closing an anonymous service is to abuse it. If, by abusing the service, one can stir up sufficient 
trouble, people will eventually no longer tolerate its existence. 
This section discusses many forms of abuse we have anticipated and encountered while running 
nym. alias. net, and gives solutions we have implemented or envisaged to counter the abuse. In 
designing solutions, our goal was to avoid blocking problematic messages with manually-tuned 
filters. Such filters would constitute censorship, make us liable for messages we did not block, and 
even provide incentive for abuse. Other remailers' experience has shown that people unhappy with 
anonymous users will purposefully abuse a server if by doing so they can stop legitimate messages. 


4.1 Harassment 
Virtually every anonymous remailer periodically gets used to send offensive or harassing email to 
someone who does not want to receive it. The sender of such messages can never be tracked down, 
but the recipient of the mail can be blocked from receiving any further anonymous correspondence. 
Such blocking is known as destination-blocking. 
Rather than manually process requests to be blocked, we implemented a destination-blocking 
scheme for our type-2 remailer that requires no intervention on our part. When a user x@ y. com 
sends mail to dstblk-request@ nym. alias. net, the system first sends mail to a few ad-dresses 
like owner-x@ y. com to try to reach the list administrator in case x@ y. com is a mailing 
list. Each message is sent from a unique address containing random data. If someone replies to 
any of the mail messages, x@ y. com gets blocked. Otherwise, if all the messages bounce, another 
message is sent to x@ y. com asking the user to confirm the block request. This lets users block 
their own addresses, but requires the consent of mailing list administrators to block mailing lists 
from receiving anonymous mail. 
Surprisingly, despite being prepared to apply this blocking system to nymserv, it has never 
proven necessary. In two years of operating the pseudonym server, we have not destination-blocked 


10 
10
a single person. Most content-based complaints we receive about nym addresses concern postings 
to public forums such as Usenet news groups. People sometimes ask us to terminate nym accounts. 
However, messages from a troublesome nym user always come from a particular email address. 
This makes them easy to ignore with news reader killfiles. We believe that canceling accounts of 
obnoxious users would only make matters worse by driving them to post in other ways less easily 
filterable. We therefore have never closed a nym account. 


4.2 Exponential mail loop 
Nyms can have multiple reply blocks. Since the nym server does not know where any of the reply 
blocks point, two of a nym's reply blocks could very well point back to the nym itself. Such 
a configuration causes an exponential mail loop. To prevent such loops from overwhelming the 
server, nymserv limits the amount of mail a nym can receive each day. It keeps a running count of 
the total number of message chunks remailed for each nym in the current 24-hour period. When 
a nym with  reply blocks receives a message 


 bytes long, that nym's chunk count increases by  
          . If a nym's chunk count ever exceeds 512, nymserv disables the account: No more mail can be sent from the account, an
d any mail to the nym bounces. The user then receives a warning that the account has been disabled. At that point the user must 
wait a day and send a PGP 


signed configuration message to the pseudonym server to reenable the account. 
Nym. alias. net never suffered from an exponential mail loop. We anticipated the attack and built 
message limits into the first version of the software. Unfortunately, message limits do open nym 
users to a denial of service attack: An attacker can disable a nym by flooding it with messages. 
Fortunately, someone maliciously flooding the system with messages cannot easily remain anony-mous, 
so such behavior can be dealt with as a traditional denial of service attack. As described 
in Section 4.4, our mail server also offers some protection against such mail bombing. Finally, 
message limits can actually increase security in some cases. Someone wishing to confirm a guess 
about the identity of a nym could otherwise attempt to fill up the real person's mail box by flooding 
the nym. 


4.3 Bulk mailing 
Early on in the history of the nym server, someone mailed some sort of chain letter pyramid scheme 
to tens of thousands of users. While we received a number of angry complaints to postmaster, the 
effects did not seem particularly bad. Enough angry people sent mail to the pseudonym itself that 
the chunk count exceeded the daily limit and nymserv disabled the account. Those complaining to 
the sender may have been satisfied to see their complaints bounce back with the message "account 
disabled." The disabled account probably appeared more like the result of a policy decision than 
an incidental consequence of exponential mail loop protection. 
Some weeks later, a nym user filled up the mail queueó the area on disk where the server tem-porarily 
stores mailó with a number of 25 Megabyte outgoing mail messages. The messages con-tained 
a single line of text, repeated over and over. Such messages compress extremely well when 
encrypted with PGP, so anonymously mailing them as cyphertext to send@ nym. alias. net 
did not pose any problems. Because a full mail spool disrupts service for other users, we modified 
nymserv to prevent a repeat of the incident: We began counting outgoing message chunks, per 


11 
11
recipient, against the daily limit. This change also prevents the kind of bulk emailing done for the 
pyramid scam. 


4.4 Mail-bomb 
Every once in a while, someone decides to send as much mail as possible to an address at nym. ali-as. 
net. The perpetrator of such a mail-bomb can easily generate messages at a faster rate than the 
system can process them. Serious delays and overloading can therefore result, not to mention un-desirable 
consequences from actually processing all the messagesó often an advertisement going 
to tens of thousands of news groups. 
To prevent mail bombs, we limit the rate at which any given person can send mail to the server. 
Of course, we must do so without compromising people's privacy. Users of nym. alias. net may 
never have to send mail directly to the machine, but many do so anywayó for instance when re-questing 
help files from autoresponders or using our type-2 remailer as the first hop in a chain. We 
therefore cannot keep a database file with per-user message counts, as such a file might acciden-tally 
get copied, backed up, or leaked, and at some later point provide a list of potential users of 
the system. We can, however, use short-term sender statistics to limit incoming mail rates if we 
keep those statistics in memory and out of the file system 2 . 
These limits are enforced by the mail server we built, smtpd. Smptd uses non-blocking I/ O 
to handle all connections from remote mail clients in a single Unix process. This structure makes 
sharing data structures across client connections trivial. It also makes the overhead of accepting 
network connections considerably smaller than for traditional servers that create one process per 
connection. Smptd imposes per-sender and per-host quotas on mail deliveries, periodically decay-ing 
usage counts to permit a steady but controlled inflow of messages. When clients exceed quotas, 
the server returns temporary error codes. This ensures that large but short bursts of traffic do not 
cause any lost mailó only delays. The server also limits the number of recipients per-message to 
5, as mail-bombers will try to generate many copies of a message for each one they have to transfer 
over the network. The Internet mail protocol, SMTP, specifies a minimum limit of 100 recipients 
per message, but imposing a limit of 5 doesn't seem to cause problems so long as attempts to 
deliver more only result in temporary error codes. 
In practice, these simple limits on mail traffic have proven quite effective. When mail-bombs 
come from different sender addresses, they usually come from one or a small number of machines 
running special mail bombing software. When mail-bombs come from a large number of hosts, 
they typically originate from a large service provider like aol. com. Such providers apparently 
make it more difficult to forge sender addresses. Sometimes mail-bombs get relayed through other 
people's mail servers. In such cases, the perpetrator cannot feel back pressure from our mail quotas; 
instead, the relay machine's mail queue simply fills upó perhaps not inappropriate punishment for 
running an open mail relay. 


2 This information must reside other places in memory, anyway. Moreover, we consider an adversary unlikely to 
seize our machine and pore over the swap partition for information just recently available through network eavesdrop-ping. 


12 
12
4.5 Reverse mail-bomb 
One day, we started receiving many complaints of the form, "I don't want to use your system, 
leave me alone," and "Why do you keep sending me this crap? I didn't request it." It turns out that 
someone was mounting reverse mail-bombs against people he did not likeó forging hundreds of 
messages from his victims' email addresses to help@ nym. alias. net, an address that replies 
to any mail with a copy of the nym. alias. net help file. 
Without logs, we had no idea who was sending the forged help requests. Moreover, we certainly 
did not want to keep the kind of databases necessary to implement any kind of one copy per 
email address per day policy. We solved the problem simply: We modified nymserv to quote the 
headers of any mail sent to the autoresponder and send them back with the response. This informed 
victims of the reverse mail-bomb attack of where the forgeries were coming from, and let them deal 
directly with the administrators of those machines. The reverse mail-bombs subsided soon after 
this change. 


4.6 Encrypted mail-bomb 
We don't know if this attack has occurred, as victims would not know to complain to us. Someone 
could create a nym with a reply block pointing to a victim's email address and subscribe that 
nym to some high-traffic mailing lists. The victim would subsequently receive large numbers of 
PGP-encrypted messages through the remailer network. 
We discourage this abuse by requiring users to confirm reply blocks. When a user submits 
a new reply block as part of account creation or reconfiguration, nymserv sends a confirmation 
request to the user via the new reply block, embedding a nonce in the Reply-To address. The new 
reply block does not become active until the user replies to the confirmation request. This scheme 
is not fool-proof, as the user must only confirm one reply block in a set of several. However, we 
suspect this confirmation process complicates encrypted mail-bombs enough that other misuses of 
the system become easier. Victims can always get destination-blocked at the last type-1 remailer 
in a reply block, if necessary. 
Reply block confirmation has an added benefit. Users often submit reply blocks without testing 
them, and sometimes those reply blocks don't work. If nymserv requires reply block confirmation, 
it can garbage-collect new accounts with unconfirmed reply blocks after only a week, rather than 
waiting 120 days. Users who reconfigure working accounts with broken reply blocks can also 
continue to receive mail with the old reply block. 


4.7 Creating many accounts 
One evening we noticed a large jump in the number of nym accounts. A small script confirmed 
that about 80 recent accounts had just been created with the same PGP key. We worried that an 
attacker might try to create a huge number of accounts, maybe even running the file system out of 
i-nodes (each account requires 3 files). At this point, we began requiring reply block confirmation, 
which apparently slowed the person down enough that the problem did not continue. 
We don't consider this line of attack particularly worrisome, however. First of all, with avail-able 
software, PGP key generation requires CPU time and manual attention. Thus, people creating 


13 
13
many accounts will tend to use the same PGP key for all of them, making the accounts easily de-tectable. 
Moreover, if necessary, a more challenging reply block confirmation process could thwart 
an automated attack with multiple PGP keys. For instance, to require manual intervention, confir-mation 
requests could contain a GIF image of the confirmation nonce (perhaps in an OCR-proof 
font) rather than an ASCII representation. 


4.8 Spam 
Given the complexity of decrypting nym mail without good client software, many nym users 
begged us to do something to reduce the amount of unsolicited commercial email or spam they 
received. Of course, we couldn't filter mail based on content, as this would amount to censorship. 
However, we tried several approaches with some success. 
First, we added a per-account configuration option, nobcc (no blind carbon copies), that tells 
nymserv to reject all messages delivered to a nym but not addressed to it. Many bulk emailers send 
spam through mail relays. They try to get as many recipients as possible out of each copy of the 
message they must transmit. Thus, the headers they send usually do not reflect all the recipients. 
People using nobcc have expressed much enthusiasm for the option and reported a 90% or better 
reduction in spam. Unfortunately, one cannot subscribe to mailing lists from a nym with nobcc set, 
as mailing list headers reflect the address of the list rather than that of the subscribers. 
Second, we tried throttling the flow of spam. We created a number of "spam-trap" accounts on 
the nym server, and then began posting news articles from some of them. Mail delivered to a spam-trap 
account caused the mail server to delay future messages from the same sender by returning 
temporary error codes. This scheme had the nice property of making it virtually impossible to 
send mail to every single nym on the system. The delays would add up and eventually cause 
messages to bounce. We now believe this approach was a mistake, however. Someone sent mail 
to a spam-trap account through a remailer, and suddenly mail from the remailer started getting 
delayed. Fortunately, we caught this before losing any mail and disabled the mechanism. 
Third, we modified our smtpd to refuse mail it cannot bounce. The server attempts to verify the 
sender address before processing the sender's mail. It does so by performing a hostname lookup 
on the sender address. If it gets a temporary error from the Domain Name System (DNS), it returns 
a temporary error code. If it gets a permanent DNS error, it returns a permanent error code. An 
examination the spam-trap logs around the time of the change indicates this may have reduced 
spam by 30ñ 50%, though we did not calculate an exact number. 


4.9 Spam-baiting 
Interestingly enough, the worst problems we ever encountered resulted from spam mail that never 
even passed through nym. alias. net. One fantastically effective way to receive spam is to post to a 
newsgroup such as misc. entrepreneurs, biz. mlm, or alt. sex. erotica. marketplace. A single article in 
one of those newsgroups can bring the sender dozens of unsolicited commercial email messages 
in the weeks to come. 
One day, someone apparently resolved to drive away non-spamming customers of what he 
or she considered spam-friendly Internet service providers, and to do so with spam. The person 


14 
14
somehow obtained lists of customers, and started posting spam-baitó forged news articles from 
those customers' addresses in the newsgroups most likely to draw spam. 
The attacker forged the articles through our mail-to-news gateway, which allowed anonymous 
remailers to set their own From headers 3 . To add insult to injury, this person created From lines 
with fake names, for instance: 


From: customer@ isp. under. attack 
(Myà ISPà spamsà Ià shouldà switch) 


Which sometimes resulted in personalized spam messages with lines like: 
Dear Myà ISPà spamsà Ià shouldà switch, 
People became furious, but did not initially understand what had precipitated all this spam. 
Bulk emailers do the best they can to conceal their electronic identities, so victims could not easily 
complain to the senders of the spam. When someone finally did figure out what was going on, 
people turned on the remailer and mail-to-news gateway operators with a vengeance, and began 
bombarding us with complaints. Then, someone developed a daemon that automatically alerted 
victims of spam-bait to the situation, and incited them to action against the remailers. Curiously 
enough, these alerts were sent anonymously through the remailer network. Some remailers shut 
down because of too many complaints. Eventually, people started calling the official technical 
contact of our network to complain. Then they started calling him at home, in the middle of the 
night. At that point, we modified our mail-to-news gateway so that anonymous articles could not 
carry arbitrary From headers. 
The perpetrator of this spam baiting was not yet through, however. Having lost the ability 
to paste From headers, the person began posting long lists of email addresses in the bodies of 
anonymous mail messages. Though people reacted angrily to this, too, these messages seemed to 
draw much less spam. We couldn't very well censor people posting lists of email addresses, so we 
reacted by posting more invalid addresses to those newsgroups than the spam-baiter was posting 
valid ones. Eventually the spam-baits subsided. 
Was this really an attack against bulk emailers, or could it possibly have been intended to close 
down remailers? We cannot answer this question. One of the most vocal critics of remailers during 
this period had a history of digging up and publishing private information about people he did not 
like. As a consequence, he frequently met with anonymous criticism in public forums. This person 
demanded we filter all news articles containing his email addressó allegedly to reduce the amount 
of spam he received. Of course, such a filter would also have had the effect of blocking anonymous 
followups to his postings. Coincidence? Either way, this story drives home the point that abuse is 
one of the most effective attacks on an anonymous service. 


4.10 INN exploit 
One day, someone posted the news article shown in Figure 2. This malformed control message 
exploits a bug in the Unix news server software INN to mail a copy of the system's password file to 


3 Anonymous remailers allow users to paste arbitrary headers into outgoing mail, but not to modify the standard 
ones. Pasting a From header has the bizarre effect of creating a message with two From headersó something illegal 
for news articles. Our mail-to-news gateway simply removed all but the last From header of news articles. 


15 
15
From: root@ ed. com 
Newsgroups: alt. test 
Control: newgroup 
'/ usr/ bin/ sed:-n: '/à#+/,/à#-/ p':${ ARTICLE}|/ bin/ sh' 
moderated 
Date: 9 Aug 1997 03: 00: 01 -0700 
Message-ID:  
Apparently-From: root@ ed. com 


#+ 
/bin/ cat /etc/ passwd | /bin/ mail voodoo@ nym. alias. net 
#-Figure 


2: This article collected the password files of news servers running INN. 
voodoo@ nym. alias. net. The article was neither posted through an anonymous remailer, nor 
through our mail-to-news gateway. (In fact, our mail-to-news gateway disallows newgroup control 
messages.) The first 512 news servers to receive the message probably mailed their password files 
to that address without incident, but then the exponential mail loop defeater kicked in and disabled 
the account. Subsequent password files then began bouncing back to news server administrators, 
some of whom were shocked to learn of the existence of a service like nym. alias. net. 
While it's unfortunate that the pseudonym server participated in such an attack, the perpetrator 
didn't need nym. alias. net to steal the password files. He could instead have posted the stolen 
passwords to a newsgroup or mailed them to an unmoderated mailing list. At least the pseudonym 
server encrypted the password files before forwarding them on, so that only the owner of voodoo 
could read them. 


4.11 Child pornography 
Our worst nightmare came true. Someone allegedly posted child pornography from a nym. The 
FBI contacted us. They sent us a subpoena. We complied, and disclosed the reply block for the 
nym. Of course, a reply block doesn't necessarily give one the identity of a user. What we turned 
over to the FBI can only have helped them if they used it to issue more subpoenas. 
The experience was not as bad as we had feared. The FBI did not seize our equipment. They 
did not threaten us or try to intimidate us. They did not ask us to start keeping logs, or try to 
convince us to shut down. We feared child pornography more than anything, but this happened and 
nym. alias. net survived. 


5 Discussion 
The types of abuse faced by anonymous servers fall roughly into three categories: conventional 
attacks, content-based abuse, and overloading. We discuss each type of attack in turn and suggest 
general principles that we have developed to deal with them. 


16 
16
Conventional attacks apply equally to machines without anonymous services. They include 
SYN bombs, mail bombs, and any attempts to exploit vulnerabilities in the server's operating 
system. Conventional attacks can be dealt with through conventional means, with the slight com-plication 
that anonymous servers may lack system logs. 
What cannot go into logs may go elsewhere. When missing logs present a problem, one 
should try to record equivalent information where it can be retrieved in case of abuse but will not 
hurt the privacy of users. We did precisely this to solve the reverse mail-bomb problem of Sec-tion 
4.5: We couldn't log the source help requests, so we instead started returning the information 
with the help file. 
Avoid censorship. Content-based abuse consists of anonymously antagonizing people to turn 
them against the service providing the anonymity (whether justifiably or not). The first solution 
that comes to mind for fighting content-based abuse is often censorship. Unfortunately, no prac-tical 
way of censoring anonymous servers exists. Manually inspecting anonymous traffic requires 
too much effort, and probably calls for judgements beyond the competence of the administrators. 
Automatic filters can simply be circumvented by abusers once they understand the blocking cri-teria. 
Moreover, filters risk blocking traffic from legitimate users. When people make unpopular 
statements through a server, this incidental blocking of legitimate users can actually provide an 
incentive for abuse. Finally, in the United States, censorship opens service providers up to legal 
liability for content they do not block. 
Make it easy for people to filter anonymous messages. Of course, no one has the right to 
force himself on unwilling listeners, whether anonymously or not. Thus, a provider of anonymous 
speech must help unwilling recipients avoid anonymous messages. With email, one can accomplish 
this by clearly labeling anonymous messages and providing automated destination blocking, as 
described in section 4.1. In public forums such as Usenet, anonymous messages should have some 
property that lets people easily ignore them automatically with mechanisms such as killfiles. 
Keep the filtering secret from the attacker. In either case, someone engaging in content-based 
abuse should have no way to know who ignores what messages. Otherwise the perpetrator 
can try to work around whatever mechanisms people use to ignore him. 
Interestingly enough, the nym. alias. net pseudonym server has received considerably less abuse 
than our anonymous type-2 remailer. In fact, after two years of operation we have still not needed 
to implement destination blocking in nymserv. We can in part attribute less abuse to greater com-plexity 
of using the service, but good software does now exist for creating nyms. Pseudonymity 
may also just be a less appealing tool for harassment than anonymity, particularly since one can 
filter one pseudonymous user without filtering them all. 
Anonymous servers also face the threat of being anonymously overloaded, for instance with 
bulk email or Usenet posting. Abuse involving large amounts of traffic differs from content-based 
abuse in two ways: First, techniques such as destination blocking and killfiles can no longer ad-equately 
resolve the problem; considerably many resources may still be wasted. Second, it is 
difficult to remain anonymous while overloading a server. During a mail-bomb attack, for exam-ple, 
even without mail logs, one can list open network connections and conclude that the site with 
20 connections is the one causing trouble. 
Recent history may suffice to prevent overload. Servers can prevent overloading by applying 
back pressure to aggressive clients. Because knowlege of current and very recent activity suffices to 
detect network overloading, anonymous servers need not sacrifice privacy to apply back pressure. 


17 
17
Smtpd, the mail server described in Section 4.4, exemplifies this fact. Though we keep no mail 
logs, smtpd keeps recent usage statistics in memory and uses them to limit the rate at which any 
given client can send mail. We found single-process, non-blocking network servers particularly 
amenable to this application, as they are highly efficient and permit easy sharing of data accross 
connections. 
Put the human in the loop. Where direct network connections are not involved, demands can 
be imposed on clients to slow them down. For example, we would like it to remain hard for abusers 
to create huge numbers of pseudonyms. Currently, the nym creation process is slow enough and 
(thanks to PGP) requires enough human intervention that the difficulty has remained sufficient. 
Should the situation change, however, we could increase the burden of creating a pseudonym by 
charging hash cash. Ultimately, however, the most effective currency in which to charge for open 
services is human effort. When simpler techniques fail, this may be accomplished by requiring 
people to type in confirmation texts from images of OCR-proof fonts. 


6 Conclusion 
In practice, anonymous servers face more serious attempts to silence users than to expose them. 
Anonymous users can be silenced through denial of service attacks, which can be more difficult 
to prevent or stop in the presence of anonymity. A particularly vicious form of attack involves 
abusing anonymous servers until they must shut down. Nonetheless, we have run a pseudonymous 
email service for two years and easily survived the abuse. 
We conclude that abuse must be factored into the design of any anonymous server, but the 
problem is not insurmountable. A variety of techniques can be used to slow down abusers or force 
them to reveal their identities. 


Acknowledgements 
We thank the many people at MIT who have actively supported nym. alias. net. There are few places 
in the world where one can count on such generous support. 
We would also like to thank all those who have taken news feeds from nym. alias. net, making 
our mail-to-news gateway such a fast and reliable way of posting to Usenet. 


18 
18
References 
[1] Masayuki Abe. Universally verifiable mix-net with verification work independent of the 
number of mix-servers. In EUROCRYPT 98, May 1998. 


[2] Adam Back. Hash cash. From http:// www. dcs. ex. ac. uk/~ aba/ hashcash/. 
[3] David Chaum. The dining cryptographers problem: unconditional sender and recipient un-traceability. 
Journal of Cryptology, 1( 1): 65ñ 75, 1988. 


[4] David L. Chaum. Untraceable electronic mail, return addresses, and digital pseudonyms. 
Communications of the ACM, 24( 2), Feb 1981. 


[5] Lance Cotrell. Mixmaster and remailer attacks. From 
http:// www. obscura. com/~ loki/ remailer/ remailer-essay. html, 1995. 


[6] Shlomi Dolev and Rafail Ostrovsky. Efficient anonymous multicast and reception. In Ad-vances 
in Cryptologyó CRYPTO '97, 1997. 


[7] Michael Froomkin. Flood control on the information ocean: Living with anonymity, digital 
cash, and distributed databases. U. Pittsburgh Journal of Law and Commerce, 395( 15), 1996. 
http:// www. law. miami. edu/~ froomkin/ articles/ ocean1.htm. 


[8] Ian Goldberg, David Wagner, and Eric Brewer. Privacy-enhancing technologies for the Inter-net. 
In COMPCON '97, February 1997. 


[9] Ceki G® ulc® u and Gene Tsudik. Mixing E-mail with BABEL. In Proceedings of the ISOC 
Symposium on Network and Distributed System Security, February 1996. 


[10] Markus Jacobsson. A practical mix. In EUROCRYPT 98, May 1998. 
[11] David Mazi` eres. Instructions for nym. alias. net. Available by finger or email autoresponder 
from help@ nym. alias. net. 


[12] Charles Rackoff and Daniel R. Simon. Cryptographic defense against traffic analysis. In 
Proceedings of the 25th annual ACM Symposium on Theory of Computing, pages 672ñ 681, 
1993. 


[13] Michael K. Reiter and Aviel D. Rubin. Crowds: Anonymity for web transactions. Technical 
Report 97-15, DIMACS, April 1997. 


[14] Paul F. Syverson, David M. Goldschlag, and Michael G. Reed. Anonymous connections and 
onion routing. In Proceedings of the 18th annual Symposium on Security and Privacy, pages 
44ñ 54, Oakland, CA, May 1997. IEEE. 


[15] Phil Zimmermann. PGP: Source Code and Internals. MIT Press, 1995.