[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: remailer delays
- To: [email protected]
- Subject: Re: remailer delays
- From: [email protected]
- Date: Fri, 4 Feb 1994 13:29:34 -0800
- Comments: This message is NOT from the person listed in the Fromline. It is from an automated software remailing service operating atthat address. Please report problem mail to <[email protected]>.
-----BEGIN PGP SIGNED MESSAGE-----
Brian Beker asked,
"The last two messages I've sent through remailers have taken upwards of
two days to arrive at their destinations. Parallel messages sent
directly arrived immediately.
The two remailers are Hal's and rebma.
What is making this happen? Is it related to all the recent PGP FAQ
traffic? Which remailers if any are not suffering from these lags?"
I am not using remba at all, not even pinging it. The last three days
have seen the "Bomb me!" request dwindle to about 5-6 a day. Hal's ("shell")
is working without a glitch. That leaves remba. If I can get my list of
remailer details completed, people like you with specific needs (today you
want speed) will be happier. The fast remailers that I am using and have
had NO problem with are:
@remailers = (
"[email protected]",
"[email protected]",
"[email protected]",
"[email protected]",
"[email protected]",
"[email protected]",
"[email protected]",
"[email protected]"
);
These are not necessarily the most secure ones, but they are all pingable
with variable 5 minute to 1 hour delays for the pings to come back. If speed
is of concern, these are your remailers. cicada and pmantis are also quite
fast but are not meant for what I need them for. I am very sensitive to
kicking mailers off my list if I cause a problem, even once. The merde and
dis.org remailers often add an hour delay, seeming to batch things out.
jarthur is often ~10 minutes, but just as often an hour.
- From my incomplete List:
Remailer Fast? OpLog SysLog Subj Batch RD NL CPU Phys PGP BitB
-------- ------ ----- ------ ---- ----- -- -- --- ---- --- ---- ----------
bsu-cs + ? ?/? + ? ? ? ? ? 23a ?
catalyst + N? SM/MQ - - ? - PA M 23a -
choas + ? ?/? + ? ? ? ? ? - -
cicada ++ ? ?/? - - - - ? ? - -
dis.org -/-- ? ?/? - ? ? ? ? ? 23a ?
extropia +/? ? ?/? + ? ? ? Pr? ? 23a ?
jarthur +/-- St SM/MQ? - ? ? ? Un ? 23a -
menudo -- ? ?/? - t1 ? ? ? ? - ?
merde -/-- ? ?/? - ? ? ? ? ? - ?
penet.fi -- St ?/? - t? 24 + Pr H - -
pmantis ++ ? ?/? - ? - - ? ? - -
qwerty + C SM/MQ - - - - PA M 23a +
rosebud ++/- ? ?/? - - - ? ? ? 23a ?
remba ? ? ?/? ? ? ? ? ? ? 23a ?
shell ++/+/- St ?/? - ? ? ? ? ? 23a -
soda ++/- St+? ?/? - ? ? ? ? ? -
Subj: Strips Subject header?
NL: Non-linear remailing? 123->231.
RD: Random delay added (max, in hours)?
Batch: Batched remailing? t2 means twice daily. n5 means after 5 messages.
CPU: Pr = private. PA = account on public access machine. Un = university.
Phys: Physical security of the CPU, especially at night. H/M/L.
BitB: BitBucket feature?
Fast?:
++ <5 min
+ 5-10 min.
- ~10-30 min delay
-- pinging isn't practical due to long delays
+/- sometimes +, sometimes -
Normal internet mail delays are common, and are not equivalent in the two
directions between any two remailers. Mail still gets through.
OpLog:
F: full copies of all mail is archived. My large volume mailing should
help put a stop to this.
St: Stats logs of when mail was remailed.
St+: Stats logs of when and where mail was remailed.
St-: simple counter.
N: operator keeps no logs.
SysLog:
SM: sendmail logs of when and where mail was exchanged. Root access.
MQ: mailqueue accessible by anyone on the site. Could make logs.
-Nik (Xenon)
-----BEGIN PGP SIGNATURE-----
Version: 2.3
iQCVAgUBLVJ3RwSzG6zrQn1RAQEfFQP/Rkt6bVBWCetn4YH/dm7LJ+EhAia+NXDy
EutlgmKJKXPc2eh3pypVb0cxdlMr/dOidXrTY3LzCF4iHOc7/l1FNegkbrJltf9R
+rOHyh23FDnQZE8NIxq9KLr++iUxMFsq8UfmNy+Z5ojMh2Nc+54CBSHoAMMEryPG
oEOu5i3jK08=
=nfRB
-----END PGP SIGNATURE-----