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.

Subject	Function
remailer-conf or reliable-conf or freedom-conf or remailer-stats	Returns a configuration report which shows what directives and capabilities are supported, and other pertinent information. Not all remailer operators choose to enable every Reliable option detailed in this manual. The remailer-conf information will show you what is supported by the remailer.
remailer-help	Returns the help file for the remailer. Operators sometimes customize help files for their particular remailer.
remailer-key	Returns the remailer keys (Cypherpunk and/or Mixmaster) for the remailer. These keys are used to send encrypted remail requests to the remailer.
remailer-stats	Reliable remailers return a remailer-conf report in response to remailer-stats, which depending on configuration may show the remailer's usage within the last week.

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:

:: [Remailer Directives] [Message Text]

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:

:: [Remailer Directives] ## [Hash Headers] [Message Text]

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:

:: Anon-To: final@recipient.com Latent-Time: +1:00 ## Subject: This is an anonymous message example This is the text of the message to be remailed to the final recipient specified in the Anon-To directive.

The above message instructs the remailer to send the message text anonymously to the final recipient (final@recipient.com) 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.

Notes:

• Some remailers are Mixmaster only, and do not accept Cypherpunk remail requests at all. Be sure the remailer you are planning to use includes cpunk in its capability string.

• Some Cypherpunk remailers are pgponly, and do not accept plain Cypherpunk remail requests. Be sure the remailer you are planning to send a plain (non-encrypted) remail request to does not include pgponly in its capability string.

• If your standard email client supports MIME, be sure that MIME is disabled, and that the outgoing message is plain text. MIME messages sent to a remailer will be silently discarded.

• Some remailers use replay caches and will delete duplicate messages. Thus if you send the same test remail request more than once, you may find that only the first one will yield a response.

To create a PGP-encrypted Cypherpunk remail request, first create a plain Cypherpunk remail request, as shown in the above section. For example:

:: Anon-To: final@recipient.com Latent-Time: +1:00 ## Subject: This is an anonymous message example This is the text of the message to be remailed to the final recipient specified in the Anon-To directive.

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:

-----BEGIN PGP MESSAGE----- Version: 2.6.2 hIkDPRWysueuweUBA+YhW2K6n2PPnFOcZulHzNNdeJ8OxHX5Aq3mbRKBlnogMjkD dr8wzb6yNk0QWxKyUSQUaoluaUKex/oEdXxXBCWLIXuKUebk/0DEL4oMYwPsjekD edm/u8qrJ3CzWDePC4D5EOZ9COkog/02/l6abgt7XNPpJvmyAX+bnwzqVKYAAAC9 IlZteUKkvLyB+PaSu7HbN5VUvJ2VBMPwg7xePKtaKIHjtZyMG6YNg/8qA7LbO4CE D9TwYiWdMTLovGVY2WleWBupeBMiAxtIqQT8IdwGSzzM8w8XWDnRfCVC2S3g9FRP cXm6WHriqbzq5NOHL8Q2dSWNFBp0ZHs1M/AAwtgnABMgMQXlTddo23q3Z+wg5xes N/rFoHp3g4EGbS9mz42cTOeQXGljMG2E1NAdDp3mUqRZLmfkkoF2lMKbBFGW =2NpQ -----END PGP MESSAGE-----

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@address

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:

:: Encrypted: PGP -----BEGIN PGP MESSAGE----- Version: 2.6.2 hIkDPRWysueuweUBA+YhW2K6n2PPnFOcZulHzNNdeJ8OxHX5Aq3mbRKBlnogMjkD dr8wzb6yNk0QWxKyUSQUaoluaUKex/oEdXxXBCWLIXuKUebk/0DEL4oMYwPsjekD edm/u8qrJ3CzWDePC4D5EOZ9COkog/02/l6abgt7XNPpJvmyAX+bnwzqVKYAAAC9 IlZteUKkvLyB+PaSu7HbN5VUvJ2VBMPwg7xePKtaKIHjtZyMG6YNg/8qA7LbO4CE D9TwYiWdMTLovGVY2WleWBupeBMiAxtIqQT8IdwGSzzM8w8XWDnRfCVC2S3g9FRP cXm6WHriqbzq5NOHL8Q2dSWNFBp0ZHs1M/AAwtgnABMgMQXlTddo23q3Z+wg5xes N/rFoHp3g4EGbS9mz42cTOeQXGljMG2E1NAdDp3mUqRZLmfkkoF2lMKbBFGW =2NpQ -----END 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.)

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:

## Newsgroups: alt.a.very.long.newsgroup.domain.name.group,alt. another.very.long.newsgroup.domain.name.group This is the text of the newsgroup post.

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.

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.]

Note: A given remailer may not support all of the directives listed below. Check the remailer's capability string, and send a remailer-conf request for specific information about a remailer.

• Multiple addresses and newsgroups in headers should be separated by commas. Spaces before or after the comma are permissible with Reliable remailers.

• Remailer directives are not case sensitive.

• Any place where a remailer address is required, the short name of any supported remailer may be used. Reliable will expand the name to the full address. For example:

          Anon-To: Base
            would expand to
          Anon-To: remailer@base.xs4all.nl
            and
          Remix-To: random, squirrel, wazoo
            would expand to
          Remix-To: random,mix@squirrel.owl.de,mix@wazoo.com
  

  This is an extended capability.
  

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.

Max-Size
Max-Size is designed for use in reply-blocks, and has no real utility in non-reply-block messages. It instructs the remailer to discard the message if it exceeds the specified maximum. For example, consider the following reply-block excerpt:

:: Anon-To: address@somewhere.net Max-Size: 15

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.

Max-Count
The Max-Count directive is designed for use in reply-blocks. It determines how many messages may be remailed through a given reply-block on any one day. For example, consider the following reply-block excerpt:

:: Anon-To: address@somewhere.net Max-Count: 20

(Shown without required PGP encryption)

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.

Max-Date
The Max-Date directive is designed for use in both reply-blocks and Cypherpunk messages. It sets an expiration date for a message. If the message has expired, it is discarded by the remailer. The date is specified in the same format used in the Date header of email messages. For example, consider the following remail requests:

:: Anon-To: Example1@somewhere.net Max-Date: Thu, 21 Jan 1999 17:00:00 -0800 This example specifies an exact date and time when the message expires. (The day of the week may be excluded.) :: Anon-To: Example2@somewhere.net Max-Date: 21 Jan 1999 This example specifies the last date on which the message may be remailed. After January 21, the message will be discarded. If no time is specifed, no timezone ("-0800") may be specified. When a timezone is not specified, GMT (-0000) is assumed.

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.

Replay caches are particularly ineffective for reply-blocks, because of random elements like Encrypt-Key, which changes the message each time the reply-block is used. Max-Size, Max-Count, and Max-Date provide a way to limit the use of reply-blocks.

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.

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.

There are two ways in which RePGP is performed. The first is called Transparent RePGP, represented by repgp in the capability string. Transparent RePGP, as the name indicates, is transparent to the remailer user. Anytime the destination address in an Anon-To directive is that of a supported RePGP-capable remailer, Reliable will automatically send the message to the remailer in RePGP format. However, not all Reliable remailers support Transparent RePGP.

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.

In addition, Reliable remailers support an extended use of Encrypt-To to specify a chain of remailers. Your message will be PGP encrypted to each remailer in the chain. The last remailer specified must be RePGP capable. For example:

    Encrypt-To: squirrel, random, base

Reliable remailers also accept combinations of Anon-To, Encrypt-To, and Remix-To directives. For example, if both an Encrypt-To and Anon-To directive is present, and the RePGP cannot be performed, the Encrypt-To directive is discarded, and the Anon-To directive takes precedence. On the other hand, if the RePGP is performed, the Anon-To directive is discarded. Please consult the Directive Precedence section for additional information.

Why is RePGP Used?
RePGP improves the security of messages as they travel between remailers. It is an especially useful feature for encrypted reply-blocks. Without RePGP or Remix reply-blocks are more vulnerable because the encrypted reply-block is the same for each message.

For outgoing messages, RePGP is unnecessary, because your remailer client can fully PGP-encrypt the message which each remailer's public key.

How do Reliable Remailers Differ?
Reliable remailers support the ext capability, which means they support the following extended features:

• multiple addresses in the Encrypt-To directive
  
• the keyword "random" to specify a randomly selected remailer
  
• the name of the remailer may be used in lieu of a full address
  
• combinations of Anon-To, Encrypt-To, and Remix-To
  

There are two ways in which Remix is performed. The first is called Transparent Remix, represented by remix in the capability string. Transparent Remix, as the name indicates, is transparent to the remailer user. Anytime the destination address in an Anon-To directive is that of a supported Mixmaster remailer, Reliable will automatically send the message to the remailer in Mixmaster format. However, not all Reliable remailers support Transparent Remix.

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.)

When using a Remix-To directive, be sure the remailer specified supports both cpunk and mix, or the message will be lost.

To disable Transparent Remix and Transparent RePGP, causing the message to be sent without additional encryption, use a Remail-To directive.

In addition, Reliable remailers support an extended use of Remix-To to specify a chain of remailers. Your message will be Mixmaster encrypted to each remailer in the chain. The last remailer specified must support both cpunk and mix. For example:

    Remix-To: marvin, random, replay

Reliable remailers also accept combinations of Anon-To, Encrypt-To, and Remix-To directives. For example, if both an Encrypt-To and Remix-To directive is present, and the Remix cannot be performed, the Remix-To directive is discarded, and the Encrypt-To directive takes precedence. On the other hand, if the Remix is performed, the Encrypt-To directive is discarded. Please consult the Directive Precedence section for additional information.

Why is Remix Used?
Remix improves the security of messages as they travel between remailers. It is an especially useful feature for encrypted reply-blocks. Without RePGP or Remix reply-blocks are more vulnerable because the encrypted reply-block is the same for each message.

For outgoing messages, Remix is unnecessary, because the Mixmaster client can create a fully encrypted Mixmaster chain.

How do Reliable Remailers Differ?
Reliable remailers support the ext capability, which means they support the following extended features:

• multiple addresses in the Remix-To directive
  
• the keyword "random" to specify a randomly selected remailer
  
• the name of the remailer may be used in lieu of the full email address
  
• combinations of Anon-To, Encrypt-To, and Remix-To
  

:: Remix-To: hyper Encrypt-To: hyper Anon-To: hyper :: Anon-To: final@recipient.com This is an anonymous message sent to final@recipient.com through a chain of remailers ending with Hyper.

When a Reliable remailer receives the above message, it will first consider the Remix-To directive (because this directive has precedence). If remix2 is enabled, and if the Hyper remailer is a supported Mixmaster remailer, it will send the message anonymously to Hyper using Remix.

If for any reason the Remix-To directive cannot be performed, the directive will be discarded and the Encrypt-To directive will take precedence. The message will be sent to Hyper with RePGP.

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:

Test-To
Null
Anon-Post-To
Remix-To
Encrypt-To
Remail-To
Anon-To

:: Encrypt-To: base Inflate: 7r :: Anon-To: final@address.com Cutmarks: -----BEGIN GARBAGE----- This message would instruct Reliable to RePGP to remailer@base.xs4all.nl. A random amount of garbage no greater than 7K would be added to the end of the message (within the public key encryption). Base would strip off the added garbage and remail the message to final@address.com.

:: Encrypt-To: Base Rand-Hop: 4r :: Anon-To: final@address.com This message would instruct Reliable to RePGP to remailer@base.xs4all.nl through a chain of between 1 and 4 random remailers. The chain would be PGP encrypted. Base would remail the message to final@address.com.

:: Encrypt-To: replay,bong,base Rand-Hop: 3 :: Anon-To: final@address.com This message would be sent via a PGP encrypted chain of three random remailers followed by replay, bong, and base. Only Base need be capable of accepting RePGP mail.

:: Remix-To: squirrel,random Rand-Hop: 3 :: Anon-To: final@address.com This message would be Mixmaster encrypted via the following chain: random --> random --> random --> mix@squirrel.owl.de --> random The last remailer would remail the message to final@address.com

:: Anon-To: final@address.com Rand-Hop: 1 Encrypt-Key: test ## Subject: Final subject Reliable would remail this message to one random remailer who would remail it to final@address.com. The message would be encrypted (by Reliable) with the passphrase "test". The one random remailer chosen would be Mixmaster if transparent remix is enabled, PGP encrypted if transparent RePGP is enabled, or unencrypted if neither are enabled.

:: Test-To: myemail@address.com Encrypt-Test: reportphrase Anon-To: final1@address.com, final2@address.com, final3@address.com Inflate: 3r Cutmarks: === Jjdfle: Meaningless directive Encrypt-Key: test Latent-Time: 5:00r ## Subject: My Subject From: My Nickname Reliable would process this message fully, analyzing all To headers and performing the ek encryption. The message would be queued for sending, and then would be deleted. Instead of the message being mailed, a test report would be ** sent to myemail@address.com detailing any problems encountered, including any errors, any blocked addresses, and whether the custom From header was accepted. The test report would be encrypted with the passphrase "reportphrase", and would include both the top part of the original test message, and the first 20 lines of the final output message generated. The test report would look something like this (encrypted of course): [The example below was run using a remailer which had middleman enabled, and did not support transparent repgp or remix (so the message was sent to the random remailer (Neva) without encryption). The remailer was set to disallow From headers, and had Latent-Time disabled. It had a destination block set for "*final2*".] This is an automated response to the test message you sent to Example. Your test message results follow: BEGIN: Preprocessing message JD3J9.ML0 at 11-Aug-98 08:34 GMT Remailer Directives: :: Test-To: myemail@address.com Encrypt-Test: reportphrase Anon-To: final1@address.com, final2@address.com, final3@address.com Inflate: 3r Cutmarks: === Jjdfle: Meaningless directive WARNING: Directive (above) not recognized (ignored) Encrypt-Key: test Latent-Time: 5:00r WARNING: Latent-Time directive disabled Hash Headers: ## Subject: My Subject From: My Nickname BEGIN: Examining headers To: final1@address.com: Direct Destination Not Allowed - Middleman Enabled To: final2@address.com: Destination Blocked To: final3@address.com: Direct Destination Not Allowed - Middleman Enabled WARNING: From header stripped BEGIN: Processing Inflation: Adding garbage (2.12k) Encryption: Encrypt-Key Conventional Middleman: Random non-encrypted hop RemailList: RANDOM Build To: remailer@neva.org (hash) Your test message was processed successfully. Queue: Message successfully queued for SMTP. (Your test message will not actually be sent.) Scheduled for sending at: 11-Aug-98 09:47 GMT ============================================================== The first 20 lines of your original test message follows: :: Test-To: myemail@address.com Encrypt-Test: reportphrase Anon-To: final1@address.com, final2@address.com, final3@address.com Inflate: 3r Cutmarks: === Jjdfle: Meaningless directive Encrypt-Key: test Latent-Time: 5:00r ## Subject: My Subject From: My Nickname Reliable would process this message fully, analyzing all To headers and performing the ek encryption. The message would be queued for sending, and then would be deleted. Instead of the message being mailed, a test report would be ** sent to myemail@address.com detailing any problems encountered, including any errors, any blocked addresses, and whether the custom From header was accepted. The test report would be encrypted with the passphrase "reportphrase", and would include both the top part of the original test message, and the first 20 lines of the final output message generated. The test report would look something like this: ============================================================== The headers and first 20 lines of your final output message follows: To: remailer@neva.org From: example@address.com (Example Anonymous Remailer) :: Anon-To: final1@address.com,final3@address.com ## Subject: My Subject Reliable would process this message fully, analyzing all To headers and performing the ek encryption. The message would be queued for sending, and then would be deleted. Instead of the message being mailed, a test report would be ** -----BEGIN PGP MESSAGE----- Version: 2.6.3i pgAAB97J04MiFnIlG+bIL/WvXXj7rzms6ME7nQpnQHwkFNfLzH+Mu6OZiyfI+8b5 nlQSemYW72AiEC/yEr6mTjAvC/QjQfl/VIZqFx9lerZrx8thoQVcYwDwffwM6QrC vZ9ZT/G0oKJW5liNN26dPaNbDAqYs6U1+JEkxScZN18FYLebx7i8Tko9lEMQs4Q4 D9QW7M4Ee6jT09sYbrKRFzWC4vik0k5w0IZaxKshUzptZLocE/405sDTxlFv4vzi 6VdPTWyU6ueToIK6JsaB7FeO4l+B9HQ9rBuwsMoIMfqtCewfG9DOFh2ChIYSEyhy

:: Remix-To: hyper Encrypt-To: hyper Anon-To: hyper :: Anon-To: final@address.com If the receiving Reliable remailer had remix2 or remix enabled, this message would be remixed to mix@sind.hyperreal.art.pl, who would remail it to final@address.com. If remixing was disabled, the Remix-To directive would be deleted, and the Encrypt-To directive would take precedence, and the message would be mailed with repgp to Hyper. However if the remailer did not have remix or repgp enabled, the Encrypt-To directive would also be deleted, and the Anon-To directive would take precedence, causing the message to be remailed unencrypted to Hyper. (If the Encrypt-To and Anon-To directives were omitted, the message would be deleted.)

$remailer{"Example"} = "<example@address.com> cpunk* mix* hybrid* middle* pgp* pgponly* latent* ek* ekx* esub* cut hash post* repgp* repgp2* remix* remix2* reord* ext max test inflt#* rhop#* klen#";

• Reliable treats a Cutmarks directive in a simpler way than some other remailers do. Particularly, other remailers may treat sections following the cutmarks as another remail request. Reliable simply discards any text after the cutmarks.

• If a Reliable remailer does not support ek and a user includes an Encrypt-Key directive, Reliable will discard the message. Other non-ek remailers may remail the message without encryption.

• Reliable remailers treat a Post-To directive as an Anon-Post-To directive. Other remailers may treat a Post-To directive as a non-anonymous posting request.

• Some remailers have a Latent-Time delay maximum of +23:59. Reliable remailers have a maximum of +99:99.

• Reliable accepts spaces before and after comma-delineated addresses and newsgroups. Other remailers and mail2news gateways may not accept spaces in headers or directives.

• Reliable filters directives and final headers, and removes blocked destinations. Other remailers may discard the entire message if a destination is blocked.

• Because Reliable mix remailers support a Cypherpunk/Mixmaster hybrid capability, Cypherpunk directives, such as Latent-Time, are accepted in the final headers of Mixmaster messages. Non-hybrid remailers do not accept directives in Mixmaster messages.

• Reliable remailers support the ext capability, which means that:
  
  • the remailer accepts remailer names in lieu of full email addresses in all directives

  • Remix-To and Encrypt-To directives may contain the "random" keyword

  • Remix-To and Encrypt-To directives may specify a chain of remailers

  • multiple destination directives may be used