|Reliable User's Manual|
Reliable is an anonymous Type I/Type II hybrid remailer which runs on Windows systems. This User's Manual is intended as a reference for users and operators of Reliable remailers. It describes the message formats accepted by the remailer, and details directives which may be used to control how your messages are processed.|
This manual may also be used as a reference for remailers in general. Most of the information in this manual applies to all remailers. However, users should make note of the differences in Reliable remailers.
If you are interested in running a public or private Reliable remailer on your own system, please consult the Operator's Manual in addition to this document. Reliable is designed to be useful as both a public remailer, which accepts messages from remailer users, and as a private local system remailer, which is used by an individual for pooling, reordering, and cover traffic benefits.
Reliable remailers are a Cypherpunk/Mixmaster hybrid. Cypherpunk directives (Latent-Time, Encrypt-Key, etc) can be used with all Mixmaster messages. Both kinds of messages are processed and pooled together. The operator may configure the remailer to accept only Cypherpunk messages, only Mixmaster messages, or both.
Reliable introduces several new remailer directives, and extends upon several existing directives to provide improved reply-block security and remailer reliability. It also includes testing functions which provide a way for users to get feedback on their test messages. This is aimed at reducing the number of test messages required to isolate problems, and provides those new to remailers with feedback on what they are doing incorrectly.
Reliable remailers accept information requests. To request information, send a blank message directly to the remailer address. Place one of the following commands in the Subject of your message. The remailer will reply to your message with the requested information.|
Remailers are used to send anonymous email. To send mail, send a remail request to the remailer. The message in your remail request will be sent anonymously to the address you specify. All original email headers are removed, and the origin of the message is unknown to the recipient.
The simplest kind of remail request is Cypherpunk. Cypherpunk remail requests may be created using any standard email client. (If your client uses MIME, be sure MIME encoding is turned off, or your message may be discarded.) To avoid errors and for greater convenience, consider using a remailer client to create your remail requests automatically.
The following shows the basic format of a Cypherpunk remail request:
The Remailer Directives tell the remailer what you want done with the message. You must include at least one remailer directive to tell the remailer where to remail the message. The blank line before the message text is required.
The following Cypherpunk remail request format shows the additional use of hash headers:
Hash headers are additional final headers you want added to the message, such as a Subject.
The following is an example of a Cypherpunk remail request:
The above message instructs the remailer to send the message text anonymously to the final recipient (firstname.lastname@example.org) with the specified Subject. The Latent-Time directive instructs the remailer to delay the message one hour (which improves security).
When sending a Cypherpunk remail request in a standard email client (not a remailer client), place the remailer address in the To field of the outgoing message. You may leave the Subject blank. Paste the above text into the message body. The "::" line should be the first line of the message.
If the Cypherpunk remailer you are sending your remail request to supports pgp in its capability string, you may encrypt your request with the remailer's PGP public key. In this way your remail request is encrypted from the time it leaves your computer until it reaches the remailer, providing you with greater security and anonymity. Someone intercepting the message cannot see the final destination or the message text. When the remailer receives the PGP-encrypted remail request, it will decrypt it and process the remail request inside it.
To create a PGP-encrypted Cypherpunk remail request, first create a plain Cypherpunk remail request, as shown in the above section. For example:
Save the request above to a file, and encrypt that file with the remailer's public PGP key using PGP 2.6.x or compatible. The encrypted output file will look something like this:
When encrypting, be sure to specify that the output is to be ASCII, and that local line conventions are to be used (-t switch as shown below). Otherwise Reliable may not be able to read your message. For example, if the original request was saved as EXAMPLE.TXT, your PGP command would look like this:
pgp -eat EXAMPLE.TXT remailer@addressThis would produce EXAMPLE.ASC, the PGP message shown above.
You may also use PGP version 5 or 6 to encrypt your message, in which case the above command is not used. Use the PGPTray utility to encrypt the message on the clipboard, then paste it back into your email.
Finally, complete the request by adding the following three lines before the PGP message:
Be sure there is a blank line after the "Encrypted: PGP" directive. Send this remail request to the remailer address. (When sending through a standard email client, be sure MIME encoding is disabled. Remailers will discard MIME encoded messages.)
Mixmaster remail requests must be created using the Mixmaster client. Reliable remailers are compatible with messages created by Mixmaster versions 2.0.3, 2.0.4, and 3. If you are using DOS or Windows, Mixmaster is more readily handled through a remailer client.
To add Cypherpunk remailer directives to a Mixmaster remail request, include them as final headers when creating the remail request. Note that the final headers are seen only by the last remailer in the chain, thus only the last Mixmaster remailer may be given remailer directives. Also note that only Mixmaster remailers which are hybrid support Cypherpunk remailer directives in Mixmaster messages. (All Reliable remailers are hybrid.) Using them with other remailers may result in the directives being visible to the final recipient as final headers. Thus the last remailer in your chain should be hybrid if you add directives.
In addition, hash headers may be placed in the message body of Mixmaster messages. These will be added to the final headers of a message. The primary use for this placement is to bypass the 80 character length limitation of standard Mixmaster headers. Headers placed in a hash section are not so limited. For example, the following message body:
would include an oversize, single line Newsgroups header. The other headers for the message, such as the Subject, would be included as final headers in the Mixmaster client.
The Mixmaster client will create one or more output messages, which are encrypted remail requests. These should be mailed to the first remailer in the chain.
Remailer directives indicate how a message is to be handled, where it is to be remailed, etc. They are not seen by the final recipient of the message.
In Cypherpunk remail requests, remailer directives are placed in the "::" section. A Cypherpunk remail request must include one remailer directive which indicates where the message is to be remailed (e.g. Anon-To; Anon-Post-To; Remix-To; etc.)
In Mixmaster remail requests, remailer directives are optional. They are included as final headers of the message when constructing the remail request using the Mixmaster client. [This is a hybrid capability.]
The following applies to Reliable remailers, and may not apply to other remailers in use.
Final headers are those mail headers which appear in the message sent to the final recipient, such as Subject or Newsgroups headers. In Cypherpunk messages, final headers are added in the hash ("##") section of the Cypherpunk remail request. In Mixmaster messages, final headers may be added either in the Mixmaster client or in a hash section, as described in Mixmaster Message Format.
In general, any headers are permissible. In practice, some headers are disallowed (stripped) from outgoing messages. Send a remailer-conf request to a remailer to determine what final headers are stripped.
The following table lists final headers which have a special function, or are treated differently by Reliable remailers.
Remailers which include the max capability support Max-Size, Max-Count, and Max-Date directives. (All Reliable remailers running version 1.0.f and later support max.) These directives are used to add security to reply-blocks, and to make cpunk messages in general less vulnerable to replay attacks. Max directives place limits on when and how a remail request may be used.
If the length of the decrypted reply-block plus the length of the attached message exceeds 15k (15 x 1024 bytes = 15360 characters), the message will be discarded by the remailer.
Max-Size is used to limit the size of messages which are sent to your reply-block. If fixedsize is not enabled on your nym account, messages may be as large as 1 meg or more. Such a large message can compromise the security of your reply-block because large messages stand out more in traffic. With Max-Size any messages larger than the maximum you define are deleted.
Also, if someone obtains a copy of your reply-block, and tries to trace it by sending large messages through it directly, the Max-Size feature will delete the messages.
If your nym account has +fixedsize enabled, which splits messages into 10K pieces, Max-Size may be set to about 15K. Each time the message is encrypted by a remailer en route, it grows slightly larger. If you have a long chain in your reply-block, you will need to set the Max-Size a few K larger. If you use Inflate directives in earlier remailers in the chain, this will also increase the message size. You can use the Test-To directive in combination with Max-Size to test various combinations.
The above Max-Count directive would limit the number of messages through the reply-block to 20 per day. Any additional messages received would be discarded by the remailer.
IMPORTANT: Your reply-block must be PGP-encrypted to work correctly with Max-Count. If it is not encrypted, every message will be discarded.
Max-Count makes replay attacks on your reply-block or nym account less effective. It is also helpful in addressing the problem of large messages sent to a +fixedsize nym account. Such messages are broken into many pieces.
Use of Max-Count may result in lost mail if the setting is too low for the typical traffic through your account. It also means that a person can effectively disable your account for a day by sending many messages, or a large message (if fixedsize) to your nym account. This is called a denial of service attack. However, many users consider this preferable to replay attack vulnerability.
Note that nym accounts also shut down after a certain number (and amount) of messages, and send the account owner a notice that he must re-enable his account. If your Max-Count reply-block shuts down first, you may not receive this notice. (You will discover the problem if you try to send mail through your account the next day, and those sending mail to your account will receive a message stating that it is disabled.)
Reliable remailers implement the Max-Count feature by hashing the reply-block, and storing a 32 digit hexadecimal number to represent it. Your reply-block is not stored on the remailer.
Note: The Max-Count value is somewhat approximate, and the actual daily maximum may be slightly higher (but not lower). This is done intentionally to thwart traffic analysis. A Max-Count directive of 5 or less is obeyed exactly.
Cypherpunk messages are particularly vulnerable to replay attacks. For example, you send a Cypherpunk message to a newsgroup. If a person suspects you are the sender, and has access to your outgoing mail, he can resend the same Cypherpunk message additional times, and it will appear additional times on the newsgroup.
Some remailers use replay caches which help prevent this, but unlike Mixmaster messages, when a Cypherpunk message expires from the cache, it can be remailed again. This slows down the attack, but does not prevent it entirely.
Max-Date solves this problem by setting an exact expiration date for the remail request, after which it cannot be used to send a message. Max-Date may also be combined with a Max-Count: 1 directive to help insure that a given (PGP-encrypted) remail request is honored only once.
Max-Date may also be used in reply-blocks, in which case it determines when the reply-block will expire. If you change your reply-block once every two weeks, for example, you can specify a Max-Date directive when you create it, so that if someone attempts to use the reply-block after it has been changed (for a replay attack, for example), it will fail.
For best results, use Max directives early in your chain, so that invalid messages are deleted before they compromise later parts of your reply-block.
Although Max directives may be used with hybrid Mixmaster remailers, most Mixmaster remailers by design will not send a given message more than once. (This is true only if the remailer has Packet ID logging enabled, which most remailers do.)
Please consult the Remailer Directives section for additional information on Max directives.
RePGP is a method Cypherpunk remailers may use to send messages to other Cypherpunk remailers. RePGP only applies to Cypherpunk remailer chains. To improve security, the sending remailer encrypts the entire message with the receiving remailer's public key. The message is formatted as a PGP-Encrypted Cypherpunk remail request. The receiving remailer decrypts the message and processes it normally.
Because the original message may already be encrypted, RePGP may result in a message being encrypted more than once. Because of this, the remailer receiving a RePGP message must be capable of recursive decryption. Not all remailers are capable of recursive decryption, thus RePGP is limited to a select set of remailers. To find out which RePGP-capable remailers are supported by a given Reliable remailer, send a remailer-conf request.
Reliable remailers may also create RePGP chains. In this case only the last remailer in the chain need be RePGP-capable. However, all the remailers in the chain must be in the Reliable remailer's list of supported remailers, because Reliable must have the public key of each remailer.
The only way to verify that Transparent RePGP is taking place between remailers is to include a Test-To directive.
The second kind of RePGP is referred to as Explicit RePGP, represented by repgp or repgp2 in the capability string. Explicit RePGP involves the user specifying an Encrypt-To directive in lieu of Anon-To. The Encrypt-To directive contains the address or name of a supported RePGP-capable remailer. If a repgp2 remailer supports the remailer in an Encrypt-To directive, the message will be sent with RePGP. If for any reason the RePGP cannot be performed (because of a missing key, for example), the message is discarded. In this way, Encrypt-To ensures that a message is RePGP encrypted between remailers, even if Transparent RePGP is disabled. However, be sure the remailer supports repgp or repgp2. (If a remailer has Transparent RePGP enabled, Explicit RePGP is also enabled.)
Another use of an Encrypt-To directive is to disable Transparent Remix. Even if Transparent Remix is enabled, the message will be sent only with RePGP encryption.
To disable both Transparent Remix and RePGP, causing the message to be sent without additional encryption, use a Remail-To directive.
Encrypt-To: squirrel, random, basewill cause the remailer to send the message with RePGP to the Base remailer through the PGP-encrypted chain Squirrel --> Random --> Base, where "Random" will be a randomly chosen remailer. (Reliable will expand the remailer names to their full addresses before sending. You may also specify the full address of the remailers.)
Remix, like RePGP, is a method Cypherpunk remailers may use to send messages to other Cypherpunk remailers. Remix only applies to Cypherpunk remailer chains. The message is formatted as a Mixmaster message for greater security. The receiving Cypherpunk remailer must support both cpunk and mix to be eligible as a Remix recipient. This remailer will decrypt the Mixmaster remail request and process the Cypherpunk remail request contained within it.
The only way to verify that Transparent Remix is taking place between remailers is to include a Test-To directive.
The second kind of Remix is referred to as Explicit Remix, represented by remix or remix2 in the capability string. Explicit Remix involves the user specifying a Remix-To directive in lieu of Anon-To. The Remix-To directive contains the address or name of a supported Mixmaster remailer. If a remix or remix2 remailer supports the remailer in a Remix-To directive, the message will be sent in Mixmaster format. If for any reason the Remix cannot be performed (because of a missing key, for example), the message is discarded. In this way, Remix-To ensures that a message is Mixmaster encrypted between remailers, even if Transparent Remix is disabled. (If a remailer has Transparent Remix enabled, Explicit Remix is also enabled.)
To disable Transparent Remix and Transparent RePGP, causing the message to be sent without additional encryption, use a Remail-To directive.
Remix-To: marvin, random, replaywill cause the remailer to send the message through the Mixmaster chain Marvin --> Random --> Replay, where "Random" will be a randomly chosen remailer. (Reliable will expand the remailer names to their full addresses before sending. You may also specify the full address of the remailers.)
For outgoing messages, Remix is unnecessary, because the Mixmaster client can create a fully encrypted Mixmaster chain.
Reliable remailers support the ext capability, which indicates that multiple destination directives are accepted. For example, consider the following Cypherpunk message:
If for any reason both the Remix-To and Encrypt-To directives cannot be performed, the Anon-To directive will take precedence, and the message will be sent to Hyper without additional encryption.
Combinations like the above example allow a user to specify Explicit Remix to remailers which have Transparent Remix disabled. In addition, if the remailer cannot perform the Explicit Remix, the message is not discarded, but is remailed in the less secure way.
In some cases it is desirable to have the message discarded. For example, if you don't want a message sent without Remix for security reasons, you can specify just a Remix-To directive. In other cases it is convenient to enable Explicit Remix without having the message discarded in the event the message cannot be remixed.
Directives may be placed in any order (although for best results, a Test-To directive should always be placed before other directives). Their order of precedence is as follows:
blocked destinations, those destinations are removed from the directive. If the directive is then empty, it is removed, and another directive, if any, takes precedence. If no valid destination directives remain, the message is discarded.
The following are example messages which may be sent to Reliable remailers. Note that some directives may not apply depending on configuration.
Depending on configuration, Reliable remailers may support any of the following capabilities. An asterisk ("*") in this example remailer capability string indicates it is an optional function which the remailer operator may or may not choose to enable.
Remailer Capability Indicators
Other capabilities which may appear in capability strings, but which should not be associated with a Reliable remailer, include:
Other Capability Indicators
With several exceptions, the information in this manual applies to all remailers. At the time of this writing, Reliable remailers differ from other remailers in the following ways:
If you need to know what software a remailer is running, try sending a remailer-conf or freedom-conf request.