Lucky Green writes:

A popular remailer will handle some 3,500 messages a day. But this includes intra remailer-network traffic. How many of those messages are messages entering and leaving the cloud is any remailer operator's guess, since current remailer statistics software has no means to differentiate between internal and boundary traffic. Of course any self-respecting TLA would know the those figures that the remail operators themselves are currently unable to obtain.

It's a myth that remailers don't distinguish between inter-remailer and outside traffic. Actually, remailers generally have built-in knowledge of every other remailer, and mail from them is handled specially. The reason is because of flood detection and prevention, which is a feature of modern remailer software. Attacks against the remailer network in the form of message floods have been a common nuisance in recent years. As a countermeasure, current remailer software detects and automatically blocks addresses which provide excessive quantities of mail. Unfortunately, the most common cause of large incoming volumes is that the other sender is itself a remailer. Hence it is necessary to maintain a database of all extant remailers and disable flood detection for those addresses. This is a common practice for remailer operators. It's also one of the main reasons why certain remailer chains "mysteriously" fail to work. With the set of remailers changing frequently, especially in recent months, it takes time, often weeks, before all the remailers get around to updating their databases to reflect the current set of addresses. Until then you have a failure with any chain which goes from a remailer to another remailer which has not yet added it. You end up with these strange situations where A can send to B which can send to C, and C can send to A, but any chain where A sends to C fails. At one time there was a somewhat romantic and idealistic notion that remailers would all operate independently, with no need to be aware of each other's existence. Experience has proven that this is not the case. Remailers do know about each other, they need to know about each other, and they coordinate their efforts via various mailing lists and newsgroups. Given this reality, it is time to consider a different approach to remailers, one in which all remailer operators work together in a peer to peer network. It's crazy for remailers to use RFC2822 email to communicate with each other, with all of its problems with reliability and the many layers of software which mail goes through to and from the remailing functionality. Remailer operators should have permanent encrypted links to one another, with constant (or at least message-uncorrelated) traffic volumes. They can still use latency, message pools, and other features, of course. But when it comes time to deliver messages to the next remailer in the list, that should be done with a reliable and direct connection that doesn't have to depend on the vagaries of sendmail, procmail, Microsoft servers or the many other layers that get in the way. This would both increase the reliability of the remailer network and improve its security by hiding inter-remailer traffic.