Mixmaster

Official Mixmaster Remailer FAQ

Table of Contents

1. Introduction

1.1 Document Audience and Licence

Permission is hereby granted, free of charge, to any person
obtaining a copy of this software and associated documentation
files (the "Software"), to deal in the Software without
restriction, including without limitation the rights to use,
copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the
Software is furnished to do so, subject to the following
conditions:

The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
OTHER DEALINGS IN THE SOFTWARE.

1.2 What's an anonymous remailer?

"A remailer is a computer service which privatizes your e-mail. A remailer is in sharp contrast to the average Internet Service Providers [ISP] which is terribly anti-private. In fact, ISP could equally stand for "Internet Surveillance Point".

"Traditionally, a remailer allowed you to send electronic mail to a Usenet news group, or to a person, without revealing your true name or e-mail address to the recipient. Today, new web-based remailers permit you to send mail using your real name (if you wish), while protecting your email records from the snooping eyes of your Internet Service Provider.

"In the first version of this FAQ (published in 1995), all popular remailers were free-of-charge. Today, a number of services either charge user fees, or support themselves via advertisers.

1.3 Why should I run an anonymous remailer?

• Promote free speech
• Work against oppresive governments
• Help whistleblowers escape retribution
• Promote cryptography and anonymity on the Internet
• Learn more about running a mail server

1.4 History of remailers/cryptography

1.5 Newsgroups/Mailing Lists

1.6 Important Reading

2. Planning

2.1 Requirements

2.1.1 Hardware

2.1.2 Internet Connectivity

2.1.3 Operating System

2.1.4 Software

• For Type I and Type II Mixmaster, if you've got a C/C++ compiler, simply grab the source code off of SourceForge and compile away. This will work on any platform.
• Nym remailers are available only in source code form.
• For those who really don't want to get their hands dirty, web frontends exist:
  • Freedom, a modified version of the original cypherpunk web frontend (used by the GMS/GILC remailer).
  • COTSE

• Multipost

• UNIX:
  • Echolot
  • Pingstats: Requires the least of the three, including no database.
  • remlist
  • rlist

2.1.5 Filesystem/Drive Space

• Type I
  • Program Software: 17 MB
  • Pool: 10-20 MB
  • Database Tables: 2-10 MB
  • Outgoing Mail Spool/Queue: 20-300 MB
  • Grand Total: 49-347 MB
  • Note that it's probably best to have flex room above the large end of the grand total, because you don't want to get caught with a full drive during a surge in message traffic.

2.2 Decisions

2.2.1 Uptime

2.2.2 Middleman

2.2.3 Nyms

2.2.4 Name

2.2.5 Policy

3. Software Configuration

3.1 MTA (Mail Transport Agent)

3.1.1 MS Exchange

3.1.2 Postfix

3.1.3 Qmail

3.1.4 Sendmail

3.1.5 Add-Ons

3.1.5.1 TLS-SSL

3.1.5.2 RBLs

3.2 Downloading Software

3.2.1 Remailers

3.2.1.1 UNIX/Linux/BSD

3.2.1.2 Web Frontends

3.2.2 mail2news Gateway

3.2.2.1 UNIX/Linux/BSD

3.2.3 Pingers

3.2.3.1 UNIX/Linux/BSD

3.3 Installing Software

3.3.1 Mixmaster Remailer

• Ensure that you have a user mix on your system, or some other user that the remailer will run as. You'll want to make sure that this account is particularly difficult to compromise, as any breaches here can lead to serious problems with your remailer. It is suggested that you have either a particularly difficult password or no login capability at all for this account (obviously, the latter would be implemented after installation).
• Download the latest sources from the SourceForge download section. You'll wan to verify that you didn't get a Trojan horse by grabbing the release-signing key from mixmaster.sourceforge.net, adding it to your keyring, and using GPG to verify the file's signature (which you should have downloaded at the same time as the source distribution). Doing this check is as simple as gpg --verify mixmaster-2.x.tar.gz.sig; note that this will only work if your signature file is named , otherwise you'll have to specify the file you're checking. (Note to Lynx users: make sure that Lynx doesn't append a .gz to your sigfile -- it did to mine, and caused me quite a bit of consternation.)
• Unpack them somewhere handy, and then cd over to that directory. (Note that you will want to do the following either as root, to make sure you have proper permissions.) To build the binaries, type ./Install in the directory you unpacked to and follow the prompts:
  • Mixmaster directory?: Where you want all of the Mixmaster files, along with your remailing pool, to live. Probably /home/mix/Mix; make sure that this directory lives on a partition with space as discussed above, and that any parent directories are created (i.e. don't put it in /home/mix if you've not created the mix user).
  • Do you want to set up a remailer?: If you're reading this document, the answer is yes.
  • Do you want to compile the passphrase into the binary?: As the prompt that accompanies this question states, it doesn't make a lot of sense to compile in the passphrase; not only is doing so not more secure than putting it in a configuration file, it causes you to have to recompile Mixmaster if you ever need to change the passphrase. While this is your decision, I would recommend against it.
  • Use source?: If this is your first time installing on this particular system, always answer no; it's best to use pre-installed helper programs. If you've already encountered errors during a previous install (which is much more likely to happen on an odd platform, such as my NetBSD/Dreamcast remailer), select yes and point Mixmaster to the appropriate directory containing the sources you want to use.
  • Install as middleman?: See the middleman section to determine your answer to this question.
  • The e-mail address of your remailer: Self-explanatory.
  • Do you want Mixmaster to send auto-replies to messages it does not understand?: As stated by the propmt, answer No if a human will use the same address as the remailer, Yes otherwise.
  • An address to appear in the `From:' line of anonymous messages: This can be set to any value @your.domain, since mail should never be sent to this address. It is suggested that you use anonymous@, remailer@, nobody@, or some other non-offensive value.
  • Address for complaints to be sent to: This address, on the other hand, must exist, and should be monitored very frequently by a human (or, optimally, forwarded to your primary address).
  • Long name: Simply a descriptive name for your remailer, to appear in log and status messages.
  • Anon long name: The name that appears as the "human" part of the From: in messages from your remailer.
  • A short name to appear in lists: The eight-character-maximum name of your remailer for official lists, such as your mlist.txt, which will be used by other remailers to communicate with you.
  • Accept Mixmaster (Type II) messages?: Unless you have a specific reason otherwise, answer Yes here.
  • Accept PGP (Type I) remailer messages?: This is mainly for backwards compatibility; it is up to you whether to accept old-style messages.
  • Mixmaster will log error messages and warnings. Do you want to log informational messages about normal operation as well?: The answer here is probably yes, particularly if you don't plan on having logs for your MTA, as it is good to have some insight into the operations of your remailer, and these messages will not compromise security.
  • Filter binary attachments?: This is, for the most part, a matter of personal philosophy. Some binary attachments, such as videos, sound files, etc., are good; others, such as malicious executables, are bad. The question you as a remailer operator face is whether you want to attempt to police your service, at the risk of being overly restrictive, or run a free and open service, at the risk of letting harm be done through you. This question is moot if you run a middleman-only remailer, however, as you should then always allow binary attachments, so as not to infringe on those remailers who have chosen to allow them.
  • Allow users to add themselves to the list of blocked addresses?: It is almost always a good idea to answer Yes here, as this allows you to handle abuse complaints more easily and with a greater measure of self-protection (as you can say, "If you don't like my service, simply block yourself from it.").
  • Allow posting to Usenet?: Whether or not you allow newsgroup posting is up to you. Answering "y" causes your remailer to do the posting; "m" sends messages through a mail-to-news gateway; and "n" blocks all newsgroup posting through your remailer.
  • Pool size: As a remailer administrator, you need to decide if you want to lean towards ultra-high-security or speedy service; if you feel like doing neither, simply accept the default of 20. Thankfully, you can change this later to suit your experiences. Note that, in reality, your pool will often exceed the size you specify here; this is not a cause for concern, as long as it does not exceed it greatly (i.e. you do not have 100 messages when you specified 20) such a mismatch might signal a malfunction in your remailer.
  • Mailbox for non-remailer messages: This needs to be set according to the demands of your MTA.
  • Set .forward to the following line: "|/home/alex/Mix/mix -RM" Do that now?: If you are running an MTA which uses the .forward file, answer Yes unless you need to do manual tweaking. If you are running Qmail, set the appropriate .qmail file to this value.
  • Installation should be complete at this point.
• Configure your remailer through the mix.cfg file. Most options should be left alone, as they are the result of what you answered while running the Install script. If you do need to tweak these options, they are documented in the mix(1) manpage. NOTE: On some systems, your manpage may not install properly. If man mix cannot find a manpage, go to the directory with your source distribution, and use nroff -mandoc mix.1 | more to view the manpage. To install it permanently, copy the mix.1 file to your system's manpage directory (typically /usr/local/man/).
• Customize your *.txt files. Go to the directory you installed Mixmaster in and individually edit abuse.txt, blocked.txt, help.txt, reply.txt, and usage.txt to your liking; you probably won't need to do much, as the standard files are very good. Next, sign all of these files, to prove to any recipients of these messages that you are the one who sent them. The typical command is gpg --sign abuse.txt; make sure you replace the unsigned file with the signed one after you've done this.
• Sign your remailer's public key, the adminkey.txt file, using the same procedure as above.
• Setup your remailing strategy. This is controlle through your SENDPOOLTIME, POOLSIZE, RATE, IDEXP, and PACKETEXP values in mix.cfg. The first two values should be set higher for greater latency in your remailer. RATE can be lowered if you are worried about floods; since this determines the percent of messages that go out each mailing, setting a lower number here slows output of messages that have flooded into your remailer. PACKETEXP determines how long you hold onto partial messages while waiting for their other pieces to come in; a long value here is probably good. IDEXP determines how long a list of message IDs is kept, to help prevent replay attacks; while this cannot be set below 5 days, it is probably a good idea to have a low value here, since legitimate messages should have almost no ID duplication.
• How to allow full from: line forging
• How to just configure mix to allow from: nick names (not full from line: forging)
• How to add in a disclaimer to the body of the message if allowing user defined from: lines
• How to prevent any mucking around of the from lines
• How to block headers

3.3.2 Pinger

3.4 Useful System Tools

3.5 Bounce Re-Inject Script

4. Security

4.1 Host System Security

4.1.1 Philosophy

4.1.2 Firewalls

4.1.3 Minimalism/Unnecessary Software

4.1.4 Local Attacks

4.1.5 Patches/Updates/Upgrades

4.2 Key Security

4.3 Logging

4.4 Floods & Spam

4.4.1 MTA

4.4.2 Asian ISPs & Subnet Filtering

4.4.3 Prevent Massive Crossposting

4.4.4 Flood Detection

4.4.5 Duplicate Detection

4.4.6 Blocking Obnoxious Hosts

5. Policy

5.1 Always Have A Posted Policy!

5.2 Responding to Abuse Complaints

5.3 To Monitor Or Not To Monitor?

5.4 Cryptographically Signing Posts & E-mail

5.4.1 How To

• Arrow, a lightweight mail client for X.
• Exmh, X front end for the MH mailing system.
• KMail, KDE's standard mail client.
• Mew, a MIME mail reader for (X)Emacs.
• Mutt, a very popular console based mail reader.
• Pine, another popular console based mail reader. You will need an add-on like pgp4pine.
• Postilion, a next-ish mail application for X.
• Spruce, a GTK+ mail client.
• XFMail, a very powerful MUA for X.

5.5 Changing Remailer Keys

5.6 Legal Links

6. Announcing Your Remailer

7. I'm Being Blocked!

7.1 Static IP

7.2 Dynamic IP

7.3 Dial-Up/POP

Contributors and Contacts

Acknowledgments