I think that there's a reasonable compromise in here somewhere. It might even address some other concerns that people could have about the costs of running remailers, e. g. storing a zillion messages for 24 hours. How about something like this: - The remailer is configured by its maintener with a maximum desireable time delay and a maximum desireable message queue size. People who do not like the values selected are free to shop elsewhere :-) - When a message arrives, it is assigned a latest output time based on the time that it is received, the remailers maximum desireable time delay and a random factor. - When the remailer's message queue size is greater its maximum desireable size, the message due to be sent next is sent regardless of its latest output time. - When a message's latest output time arrives, it is sent regardless of the remailers message queue size. You might even want to have some other remailer configuration parameters, like: - a maximum number of messages sent out during some arbitrary time interval (message/minute, e. g.) - a minimum interval between messages being sent. These two examples might force the queue size to be considerably larger than its maximum desired size during usage peaks. None of this addresses a situation where a single message is received during an arbitrarily long time period, although none of the other proposals addresses that situation. Although I can imagine how Mallet might abuse this if he coudl control the remailer's net connection, personally, I don't think that it's a problem that merits much consideration. In the absense of a suitably powerful Mallet or other serious networking problems, it's likely that such a situation is just an indication that the remailer isn't very popular. BTW, what possible benefit is there to knowing that a particular message was sent by a particular remailer? As a recipient, should I `trust' a remailer more than I trust, say, a digitial signature from the sender? Could someone describe a situation where this would provide useful information? In other words, why *not* simply encode with the recepient's public key and restrict the usage of the remailer's private to decoding incoming messages? Rick