OmniMix • Tutorial • Remailing • Remailer Chains

As each remailer is an autonomous anonymization unit, which remixes all items in its message pool, the decision upon the remailer chain is decisive for an efficient outcome, concerning reliability as well as anonymity.

The anonymity is predominantly determined by the length of the chain, strictly speaking by the size of the lined up message pools. If for example you select a chain of 4 remailers, each of them with a message pool size of 100, in theory your message can hide among 100⁴ (100 million) others. The only problem with such a calculation is, that there aren't that much messages in the system, and yours may get mixed with identical others over and over again, an important reason to attract new users in order to raise the overall message volume. To increase traffic and fill their pools up to the critical level within a reasonable amount of time aiming at an acceptable latency, remailers currently have to launch dummy messages. But those are an insufficient substitute, as they are discarded in the end at some remailer and don't add to the output of the whole system. That's why only an increase of real messages would allow to reduce the overall latency of the remailer network, one of its most evident handicaps.

Remailers aren't always as reliable as we would like them to be. Even with all statistics up-to-date, the next moment one of them may unpredictably sustain damage with that service disruption leading our messages straight to Nirvana. In such a situation only an alternative pathway could help. You may already have seen the 'Rnd' button in the chain selector window. By pushing it, a remailer named '*' (asterisk) is added to the chain. This 'wildcard' advises Mixmaster/Yamn to select a remailer for that position on a random basis. Using wildcards improves secrecy, as each message gets its individual route, so that following the traces and blocking messages becomes more difficult. If you send multiple copies of a single message, it also provides them with different delivery paths, which increases the chance of success even with some invalid remailers in the network. But it isn't a cure-all. Even if you make your chain consist of nothing but wildcards Mixmaster/Yamn determines one and the same exit remailer for all copies, as this measure is necessary to prevent from multiple deliveries. Only a single final (exit) remailer is capable of keeping a record of the messages already delivered suppressing all copies, that arrive later on. However, one sole point of delivery means a lack of redundancy, and, being out of service, the message gets lost. That may be one reason to predefine a remailer beyond reproach for that purpose (like '* * * dizum'). Further reasons for selecting a specific exit remailer can be found in the chapter about 'From' headers.

To restrict the targeted random remailers according to your needs you're allowed to set preconditions within the Mixmaster/Yamn configuration file 'mix.cfg'/'yamn.cfg'. The relevant parameters are:

MINREL	The minimum reliablity Mixmaster/Yamn demands from a remailer to be chosen randomly, in % (will be ignored if no reliability information is available). Default: '95' Example: 'MINREL 96'
RELFINAL	The minimum reliability for a remailer to be randomly chosen as the final hop, in %. Mixmaster/Yamn will choose the most reliable remailer if no remailer reaches the minimum. Default: '98' Example: 'RELFINAL 99'
MAXLAT	The maximum latency Mixmaster/Yamn will accept for a remailer to be chosen randomly, in hours. Default: 3 Example: 'MAXLAT 1'
DISTANCE	The distance after which a remailer can be selected again in a chain. 0 is a pure random selection. 20 means previously-used remailers will not be selected again. Default: 4 Example: 'DISTANCE 20'

Here's a proposal for your OmniMix related Mixmaster configuration file (lines with a preceding '#' are interpreted as comments):

--------------------------------------------------------------------------------
# mix.cfg  -  Mixmaster configuration file
# auto-created by the OmniMix proxy server

NUMCOPIES                                6
CHAIN                          *,*,*,*,*,*
MINREL                                  97
RELFINAL                                99
MAXLAT                                   1
DISTANCE                                20
--------------------------------------------------------------------------------

Newer OmniMix versions allow to modify those parameters directly (tab 'State Int') without having to use a file editor.

A further problem are remailers run by notoriously unreliable individuals or those known for spying into their traffic. Beyond that, with groups of remailers run by a single operator or an alliance of associates you may end up with a chain of servers administered by a single entity able to completely unfold your message. OmniMix shows consideration for such threats by banishing unwanted remailers from your chains and avoiding critical constellations, which is done by altering the Mixmaster statistics files accordingly. The 'Starex' list at the 'State Int' -> 'Mixm T2'/'Yamn' tab is the place where you define your remailer exclusion rules. You have two choices. To forbid the usage of single servers as random remailers add list entries containing one name each. In 'Block' mode the remailer is deactivated completely, whereas in 'Middle' mode it only isn't allowed to act as an exit remailer. On the other hand associated remailers have to be grouped in a single line separated by blanks. For each transmission only one remailer of each such group is randomly activated and all others are suppressed in order to evade sequences of related remailers. In 'Block' mode the 'lucky' one out of the group that makes it is allowed everywhere in a chain, in 'Middle' mode it again is degraded to middleman. For deactivating a rule select 'Ignore'.

To comply with the mentioned restrictions Mixmaster needs adequate statistics files. So be aware not to present 'mlist2.txt' stats-version 2.0 files, which can't be interpreted, but data in 'mlist.txt' version 1 format. Otherwise Mixmaster doesn't complain either, nevertheless the resulting chains don't meet your rules. For Yamn on the other hand it has to be a 'mlist2.txt' stats file.

It's impossible to suggest an optimum chain length, as too many factors, like the risk of some remailer(s) being compromised, influence the security, and with extreme chain lengths the reliability may become intolerable. While a 3 hop chain seems to be more than sufficient for everyday private usage, even 5 routers may be unsuitable for some kinds of critical corporate communication. So the decision has to be made on an individual basis.