Orange Block on Eelbash
No User
First some preliminary evidence:
http://members.xoom.com/eelbashw/psycho.html (Eelbash Homepage).
It saddens me to find out that Eelbash remailer is openly monitoring and
devulging information to the public from what is SUPOSED to be an anonymous
remailer.
Eelbash admin seems not to understand the fundamentals of running a remailer:
1)your remailer WILL be abused and/or used for purposes you personally disagree
with from time to time. DEAL WITH IT: this is called freedom of speech.
2)When this abuse occurs you will recieve complaints or notice it is effecting
overall remailer preformance. You BLOCK the abuse targets from delivery to
cease abuse. This is called keeping your nose clean whilst maintaining system
integrity.
3)You do NOT run SPYWARE (say it 3 times) and call yourself an ANONYMOUS
remailer; PERIOD.
4)If you cant take the heat get out of the kitchen.
That off my chest:
ORANGE will no longer support/accept mail To or From Eelbash remailer. I dont
see ANY other way around this problem then to cut all ties to eelbash in order
to protect the integrity of ORANGE users anonymity and privacy. This is an
unfortunate because I am aware alot of peoples mail will be lost due to this
block. My opinion and instinct is that it is better to have this mail lost
@ORANGE then monitored @EELBASH. On my end: I will post this notice on rem-ops
list, to eelbash admin, and APAS so most remailer users will be aware. This
block is effective immediately and will continue until satisfactory evidence is
provided that eelbash has stopped this incredible farce of a practice for an
anonymous remailer (though I havnt the faintest how this kind of evidence would
be furnished).
- -Orange Administrator
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
iQEVAwUBOV/AwAiZnv2t/C4jAQG9nQgA0eTBQI5CCNHuOPTzQoK/7clgNCrdsQfB
iBowN9ClOfCw7l54Ws1nT0mdzYAN+iNe88oHUvIXWuL0LUDFyNVeQHTK8x3L4Mjn
6Nc27X4Cg99oiFb9qOm09UeuWTVlDpZbZ/4+oOUU786xzNONdY0ZCqfOWFegv3c6
s7GOmKHn6hKAZ2HB0Q40PARrlCH/3nYNMktautAG07WTvw6ET5dY2xwkCwmgb98F
Kc1wj1J+qUOGZPY0G+Zmgi0GBp82PMcMgGwS7AW/JTTMZAl+pE9kgGLiEy28mU2r
xoqMKjuaddmkH8xKgCtxufeS/7jk3cpCxtVvSdGO5LfECY2tjMiiSg==
=GSeF
-----END PGP SIGNATURE-----
---
This message did not originate from the Sender address above.
It was posted with the use of anonymizing software at
http://anon.xg.nu
---
Upset
This message did not originate from the Sender address above.
This message sender's real identity is unknown, unlogged, and
is not replyable via the Sender address above.
------------------------NOTICE---------------------------------
On Sun, 2 Jul 2000, No User <no....@anon.xg.nu> wrote:
|ORANGE will no longer support/accept mail To or From Eelbash remailer. I dont
|see ANY other way around this problem then to cut all ties to eelbash in order
|to protect the integrity of ORANGE users anonymity and privacy. This is an
|unfortunate because I am aware alot of peoples mail will be lost due to this
|block. My opinion and instinct is that it is better to have this mail lost
|@ORANGE then monitored @EELBASH. On my end: I will post this notice on rem-ops
|list, to eelbash admin, and APAS so most remailer users will be aware. This
|block is effective immediately and will continue until satisfactory evidence is
|provided that eelbash has stopped this incredible farce of a practice for an
|anonymous remailer (though I havnt the faintest how this kind of evidence would
|be furnished).
I have a terrible problem to understand how *ANY* mail/post
orange>eelbash or eelbash>orange could put its sender at *PRIVACY RISK*
if orange is not compromised, *even* if eelbash is run by a 3-letter agency
But I see very well that you are going to dump mail that was entrusted to
you,
that *EVERY* mail orange>eelbash or eelbash>orange will be *LOST*
And AGAIN a middleman wants to lecture a non-middleman about how to take
the heat.
That is a bit TOO MUCH
YOU are the one putting the network at risk,
and YOU show poor respect for *legitimate* users
Be sure *none* of my mail will go through a remailer with such an
irresponsible operator like Orange.
You just make me recall MARAA (Misconfigured Anal-Retentive Arick-Admin)
who dumped mail from half a dozen remailers (including Orange at a time)
because he would shoot his own foot with his autoresponder toys.
Can't you just undertstand that your first duty is to REMAIL what it
entrusted to you?
Can't you see that by dumping mail you are CENSORING it in vastly bigger
numbers than any 3-letter agency might dream of.
Can't you see that by dumping mail you are CENSORING it in a 4-order bigger
magnitude than what you sentence eelbash for?)
Anonymous Sender
|It saddens me to find out that Eelbash remailer is openly monitoring and
|devulging information to the public from what is SUPOSED to be an anonymous
|remailer.
A POST is something PUBLIC
A POST-to-be is something PUBLIC
Eelbash did not divulgate *any* information that was not supposed to become
*public*:
a handful of posts with forged names and addresses
And about the PangK-related mess in alt.support newsgroups, there are 3
options:
turn a blind eye and let the remailer be killed
block the NG and let that part of free speech go
fine-tune filters to block unwanted posts
with or without human review (second chance) for posts doomed by
filters
Of course, quite a few here APPLAUDE at "solution" #1 or #2,
until there is no NG or no remailer left
But apparently, 25.000 messages a week are happy with #3
How *weird* that succesful remailers are *systematically* attacked with
that "spying" accusations.....
Hmmmm
"Anonymous Sender" <nob...@mixmaster.shinn.net> wrote in message
news:1be8dd86f2cb1d63...@mixmaster.shinn.net...
> > > ORANGE will no longer support/accept mail To or From Eelbash remailer.
I dont
> > > see ANY other way around this problem then to cut all ties to eelbash
in order
> > > to protect the integrity of ORANGE users anonymity and privacy.
>
> > Say someone sends a message to Eelbash via Orange. Eelbash doesn't like
it,
> > so he posts the anonymized message on his web page. What is exposed, and
> > what does this have to do with you? Keep in mind that all the messages
> > involved are going to Usenet -- meaning, going to be public -- anyway.
>
>
> Precisely!
>
> Thank you for adding some plain old common sense to this discussion, Mr.
Heller.
>
>
I disagree. It is as much about control of the message as anything else.
Without ellbash's actions I and many others would never have seen these
messages. It should NOT be up to the remop to determine the public routing
of any message they receive. They can bucket it if it falls outside certain
parameters - fine with me. But to take control of it and use it for their
own purpose, regardless of where the message was or wasn't going, is
bullshit.
As it stands it seems anyone could have had a problem message hit the
remailer at the same time and quite possibly have been drawn into this with
no just cause whatsoever.
Anonymous
|ORANGE will no longer support/accept mail To or From Eelbash remailer. I dont
|see ANY other way around this problem then to cut all ties to eelbash in order
Anonymous
numbers than any 3-letter agency might dream of?
Secret Squirrel
Anonymous
<nob...@mixmaster.shinn.net> wrote:
>On Sun, 2 Jul 2000, No User <no....@anon.xg.nu> wrote:
>
>|It saddens me to find out that Eelbash remailer is openly monitoring and
>|devulging information to the public from what is SUPOSED to be an anonymous
>|remailer.
>
>A POST is something PUBLIC
>A POST-to-be is something PUBLIC
>Eelbash did not divulgate *any* information that was not supposed to become
>*public*:
> a handful of posts with forged names and addresses
Wrong. He divulged the times when the posts came through the remailer.
Then he alleged that they were all made by the same person.
>
>And about the PangK-related mess in alt.support newsgroups, there are 3
>options:
> turn a blind eye and let the remailer be killed
> block the NG and let that part of free speech go
> fine-tune filters to block unwanted posts
> with or without human review (second chance) for posts doomed by
>filters
>
>Of course, quite a few here APPLAUDE at "solution" #1 or #2,
> until there is no NG or no remailer left
>
>But apparently, 25.000 messages a week are happy with #3
>
>How *weird* that succesful remailers are *systematically* attacked with
>that "spying" accusations.....
True accusations.
We'll see how long eelbash remains "successful".
Anonymous
>"Anonymous Sender" <nob...@mixmaster.shinn.net> wrote in message
>news:1be8dd86f2cb1d63...@mixmaster.shinn.net...
>> > > ORANGE will no longer support/accept mail To or From Eelbash remailer.
>I dont
>> > > see ANY other way around this problem then to cut all ties to eelbash
>in order
>> > > to protect the integrity of ORANGE users anonymity and privacy.
>>
>> S.R. Heller wrote:
>> > Say someone sends a message to Eelbash via Orange. Eelbash doesn't like
>it,
>> > so he posts the anonymized message on his web page. What is exposed, and
>> > what does this have to do with you? Keep in mind that all the messages
>> > involved are going to Usenet -- meaning, going to be public -- anyway.
>>
>>
>> Precisely!
>>
>> Thank you for adding some plain old common sense to this discussion, Mr.
>Heller.
>>
>>
>I disagree. It is as much about control of the message as anything else.
>Without ellbash's actions I and many others would never have seen these
>messages. It should NOT be up to the remop to determine the public routing
>of any message they receive. They can bucket it if it falls outside certain
>parameters - fine with me. But to take control of it and use it for their
>own purpose, regardless of where the message was or wasn't going, is
>bullshit.
>
>As it stands it seems anyone could have had a problem message hit the
>remailer at the same time and quite possibly have been drawn into this with
>no just cause whatsoever.
>
Should also be pointed out that the remop posted the messages in an
html document titled "psycho.html" to demonstrate that he takes sides
in the flamewar to which the messages were a part.
Anonymous
<nob...@remailer.privacy.at> wrote:
>On Sun, 2 Jul 2000 21:01:34 -0400 Anonymous Sender
><nob...@mixmaster.shinn.net> wrote:
>
>>On Sun, 2 Jul 2000, No User <no....@anon.xg.nu> wrote:
>>
>>|It saddens me to find out that Eelbash remailer is openly monitoring and
>>|devulging information to the public from what is SUPOSED to be an anonymous
>>|remailer.
>>
>>A POST is something PUBLIC
>>A POST-to-be is something PUBLIC
>>Eelbash did not divulgate *any* information that was not supposed to become
>>*public*:
>> a handful of posts with forged names and addresses
>
>Wrong. He divulged the times when the posts came through the remailer.
> Then he alleged that they were all made by the same person.
I forgot to add:
Five posts were made. Four with one name attached, a fifth with
another. Eelbash pointed out the times they came through were all
close together, and suggested that it was the same person. He posted
his findings to ALL the newsgroups which both of these screen names
were affiliated to.
What if it was the same person, and that person chooses to post with
two separate names because he/she doesn't want the people in newsgroup
A to know he's a proponent of the subject matter in newsgroup B?
Stephen K. Gielda
nob...@mixmaster.shinn.net says...
> By the act of sifting through his traffic Eelbash has removed the
> "anonymity"
> from his remailer (as he has exposed suposed "from" headers on his web
> page)
> wether they are valid or not is inconsequential the very fact that he is
> willing
> to do this is enough for me to question his motivation for running a
> remailer at
> all. It may not always compromise a users anonymity (depending on chaining
> order)
> but Id rather disassociate my ANONYMOUS remailer from this remailer which
> chooses to
> monitor.
>
>
Actually one should assume that every remailer in their chain is
compromised and take appropriate steps. For example, I don't know you
from adam except for your posts. You say you don't monitor, but there is
no way for me to be absolutely positive of that, nor is there for anyone
else. Always assume all remailers are insecure. That holding true, it
won't matter to a properly sent message.
Eelbash is young and adapting. He needs to find a common ground with his
providers and what they view a remailer should be. Every remop goes
through this, especially those who have their stamp on the final post.
It is not easy in the non-middleman world. Especially regarding Usenet.
The alt hierarchy is out of control and most ISP's do not understand this
and get skittish. Plus Eelbash is being very public about this, that is
in his favor.
Finding that middle ground is very important to the longevity of a
remailer. Solid reliable remailers are the most important, because they
put more variables into the mix, which increases anonymity by resisting
traffic analysis...regardless of monitoring.
Anyway, wait until you step out onto the front lines of Usenet...it's
never quiet and calm like you get being a middleman. :)
/steve
--
Stephen K. Gielda
http://www.cotse.com
The Church of the Swimming Elephant
Have you gone to church today?
Very Upset
<orang...@generalprotectionfault.net> wrote:
|Once upon a time orange admin was a normal remailer user. He
|didnt read APAS or subscribe to the Rem-Ops list, he just checked
|the stats and used remailers as needed. Sometimes the contents
|of his mail were very private, and he trusted the remailers to keep them
|that way. The reputation of most remailers was to do so in the strictest
|of confidence.
ANY mail sent plaintext should be considered "compromised"
*any* 3-letter agency
last link provider
last SMTP provider
anybody sniffing the line
ALL those people AND the last remop have access to this information
If you dont like it: encrypt your mail
|I want mail from Orange to remain 100% anonymous.
Unless ALL remop cooperate, mail will remain anonymous
You might be willing to say "content will stay CONFIDENTIAL"
But that is false because
whatever you do, if it is not encrypted to the recipient
all people above mentioned will have access to it
whatever *anybody* does, if it encrypted to the recipient
nobody will have access to it (besides leakage on recipient's side)
In short,
I would have my mail chained through "FBI-NSA official remailer" without a
heartbeat.
My only concern would be that FBI-NSA might *delete* SOME of my mail
But: you are *deleting* 100% of orange>eelbash mail, aren't you?
Hence my mail has WORSE to fear from YOU than from FBI-NSA
That is why I wont use Orange.
|If eelbash is willing to add "MON" to his cap string I will allow mail "To:"
|eelbash again.
Dont be silly: you run Reliable too and you know it is not possible
But maybe "katherine" will be willing to help modifying the code:
lots of free time since MIRANDA demise
MIRANDA the worst remailer ever
Very Upset
Very Upset
|Yes, the #1 priority of an ANONYMOUS remailer should be ANONYMITY (is this
|such a hard concept to grasp?).
It takes ALL remailers in a chain to COMPROMIZE mail.
It takes ONE remailer in a chain to LOSE mail.
ANONYMITY is achieved by CHAINING
TRANSMISSION is the responsibbility of EACH remop
That is why #1 priority is TRANSMISSION
That is why your action is more despicable and why I wont use Orange
<SNIP already addresed part>
|>Can't you see that by dumping mail you are CENSORING it in vastly bigger
|>numbers than any 3-letter agency might dream of.
|>Can't you see that by dumping mail you are CENSORING it in a 4-order bigger
|>magnitude than what you sentence eelbash for?)
|
|Sorry, that one isnt gunna fly. I am not CENSORING anyone. Censorship is
|the elimination of infomation based on CONTENT. I am defining the
|parameters
You dont LIKE to be called a censor but the result is the same: MAIL is
LOST,
in a 4-order bigger magnitude than what you sentence eelbash for.
You are not a CENSOR-by-CONTENT but a CENSOR-by-DESTINATION
quite a few countries used that technique to the disgust of their citizens
|Its the slippery slope
You disrupt the network because you dont approve of a remop action.
But *any* remailer may (*SHOULD*) be suspected of worse.
Will you break any link with the suspects too?
That is not a slippery slope, it is mere *logic*.
|Id rather disassociate my ANONYMOUS remailer from this remailer
And what if a remop is openly pro-life or pro-choice, pro-war or pro-peace?
What is the list of actions you dont want to be associated with,
and would trigger your breaking links?
|Im sorry to see you take this so personally; Im just
|protecting
|what I feel is Orange users best interests (I hope what any good rem-op
|would/should do).
I can protect myself very well, thank you: by CHAINING
What I am vulnerable to is MAIL LOSS
And you set the most disgraceful and disrupting precedent
by choosing which remailers you accept to work with.
What next: a schism?
remailer network A with remops sharing view aaaa
remailer network B with remops sharing view bbbb
remailer network Z with remops enjoying fishing together
Blocking an @ (or a NG) is a *very* serious decision.
It can be justified only if your remailer is at risk, overloaded or the
like.
NOT because you dislike a person, even worse if it is a remailer.
REMAILING is not built on TRUST (nor affinities, nor..) it is built on
CHAINING
By BREAKING LINKS, you destroy CHAINING, hence you weaken REMAILING.
Hence you EXCLUDE yourself from the community.
Secret Squirrel
|Actually one should assume that every remailer in their chain is
|compromised and take appropriate steps.[ ] That holding true, it
|won't matter to a properly sent message.
Any remailer could (and SHOULD) be suspected of worse things.
But even an *owned* remailer would be useful to the network
What disrupts the network is obsolete keys, HW/SW failures
we don't need *voluntarily* broken links on top
*Voluntarily* breaking a link is the very action
which will exclude *you* from the network
It is the users's responsibility to look at the market
and see what is out there.
Does somebody want to post:
1)To local newsgroups
2)1.000K posts
3)Full From:
4)No disclaimer inside the post
5)No disclaimer in the header
6)Fully anonymously
7)100% reliability
8)Instant transmission
9)From somebody one trusts entirely
10)And possibly a beer for passing by
My advice:
Drop #6 only and post through your usual newsreader
Besides that:
Eelbash gives #2 3 4 6 7, reasonable #1 8 9, not #5 10
Orange gives.... nobody knows, has to have it handled to somebody else
Miranda gives... mail lost
Other remailers.... pick your choice
VERY VERY ANGRY
This message did not originate from the Sender address above.
It was remailed automatically by anonymizing remailer software.
This message sender's real identity is unknown, unlogged, and
is not replyable via the Sender address above.
------------------------NOTICE---------------------------------
|On 3 Jul 2000 10:18:29 -0000, in alt.privacy.anon-server you wrote:
|>My only concern would be that FBI-NSA might *delete* SOME of my mail
|>But: you are *deleting* 100% of orange>eelbash mail, aren't you?
|>Hence my mail has WORSE to fear from YOU than from FBI-NSA
|>That is why I wont use Orange.
|
|Let me get this straight:
I say that deleting 100% of orange>eelbash is quantitatively 10.000
WORSE than exposing 5 POSTS which were supposed to become public anyways.
I say that disrupting the remailer network by ostracizing remops
who do not comply to your ukases is qualitatively even WORSE.
Next, you will ban
Dizum because it blocks too many newsgroups
Shinn because it puts a disclaimer on top of posts
Farout because it puts a disclaimer at bottom of posts
And of course all that on disguise that you want to "protect your users"
|Eelbash is running Frog's "Slippery Slope Rewatchable"
You are after Frog too?
Next is Squirrel, Widow, Austria... all the most popular remailers?
|I don't even know "katherine"
farley <far...@usa.net> wrote in message :
> I'm sorry if I'm seen by some as not standing my ground, but I consider
> truth more valuable than obduracy and Stephen does have point. Honesty is
> maybe THE most valuable thing to have in a remailer
You are a LIAR, as there is a mail between you and katherine in remops list
For me, that finishes the thread and anything else
I advocate remailer operators
not to delete mail from or to orange in any way
but to put it in the random exclusion list
but to exclude it from their personnal cap strings and keyrings
I advocate remailer operators maintening a pinging service
to remove orange from their public cap strings, stats, keyrings
Rogue remops deleting mail according to their little private wars is really
the best daydream fantasy they might have at NSA.
And Orange might very well have that agenda and not only wage his private
war.
He is claiming a bit too loud that he is the "white knight"
And it might not be only to collect funds..................
VERY VERY ANGRY
VERY VERY ANGRY
Anonymous
<nob...@mixmaster.shinn.net> wrote:
>------------------------NOTICE---------------------------------
>This message did not originate from the Sender address above.
>It was remailed automatically by anonymizing remailer software.
>This message sender's real identity is unknown, unlogged, and
>is not replyable via the Sender address above.
>------------------------NOTICE---------------------------------
>On 3 Jul 2000, Secret Squirrel <squi...@echelon.alias.net> wrote:
>|On 3 Jul 2000 10:18:29 -0000, in alt.privacy.anon-server you wrote:
>
>|>My only concern would be that FBI-NSA might *delete* SOME of my mail
>|>But: you are *deleting* 100% of orange>eelbash mail, aren't you?
>|>Hence my mail has WORSE to fear from YOU than from FBI-NSA
>|>That is why I wont use Orange.
>|
>|Let me get this straight:
>I say that deleting 100% of orange>eelbash is quantitatively 10.000
>WORSE than exposing 5 POSTS which were supposed to become public anyways.
>I say that disrupting the remailer network by ostracizing remops
>who do not comply to your ukases is qualitatively even WORSE.
>Next, you will ban
> Dizum because it blocks too many newsgroups
> Shinn because it puts a disclaimer on top of posts
> Farout because it puts a disclaimer at bottom of posts
>And of course all that on disguise that you want to "protect your users"
>
>|Eelbash is running Frog's "Slippery Slope Rewatchable"
>
>You are after Frog too?
>Next is Squirrel, Widow, Austria... all the most popular remailers?
Widow, too, once admitted that it was examining content and filtering
out messages related to a flame war in a particular newsgroup.
Paranoid
|Keep in mind many remailer users dont actively read APAS/remops list and
|wont
|be aware that eelbash monitors/censors content he doesnt like (until a MON
|string
|is added).
Keep in mind no decent (normally paranoid) remailer user will trust a
remailer operator.
The system is not built on TRUST
It is built on LACK of TRUST.
Trying to convince any newcomer he could/should TRUST a remailer operator
is just ANOTHER DISSERVICE TO THE COMMUNITY
ad...@mixmaster.shinn.net.no.spam.to
S.R. Heller <srhe...@oz.net> wrote:
> I'm still waiting to hear how your block against Eelbash protects users from
> being exposed.
I would call it protection again indistriminate content based censorship.
Censorship is far FAR worse in a remailer. Your privacy is almost
guaranteed *if* you chain properly. But, whether your message reaches its
destination is a different story if a remop decides to censor your posts
by the *CONTENT* of those posts. Thats a horrible horrible presidence.
> An article leaves your remailer, anonymized, and goes to Eelbash. What can
> the Eelbash operator do to expose the original sender of that message?
Probably nothing, but the eelbash remop can and did censor posts thru
monitoring.
> Since this is the rationale behind the block, you should remove the block if
> you can't answer the question. Or, you should add "mon" to your capabilities
> string, since you admit that you are filtering messages from a specific
> group of people, i.e., people who decide for themselves whether or not to
> use Eelbash.
Thats just down right absurd. What is this obsession with the "mon" cap
string everyone has? How is filtering a destination monitoring?
ALL remailers can and do filter destinations. Thats not monitoring.
- --
Shinn.net Anonymous Remailer Admin
PGP Key 1 ID: 0xD8D5B063 PGP Key 2 ID: 0x3C41F029
Key 1 fingerprint = C069 47E0 DF19 823F 2E34 393F 8A4E EC97
Key 2 fingerprint = A79A C4D7 F859 2F1D 26BE 5B34 9B34 0B29
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2
iQEVAwUBOWDw/cQaFjc8QfApAQGzOgf+IJzBU1q3KkofXiPs5wlMUW+TRLS9xgC0
HTua7llhrD9hW7oLTm+diKCBY3K22Fxq9eH4FFY9auvU9GYInSw4XhIXpy8vCwH/
tLQCIiCxMaa5mjcpVKVSa4n6yMFN4K84fK5p4a0ayjuJjbqYOyj3aBBP+SFGX2uy
913JtSMdusOV6sfJ3A8JOVP9GY1Ylsi2zPUE9oyFteWzMzS+Yfvu5N+zxdEzT6E/
0BkOAsDfp8RO6f0lFIXs8g7JYarfMlgPA3YbV8pYjZtw+RainiVS+3kKRbOnDgDN
EDKTsoEWqMp857CD7fX/un6Z7daKTK+AJpkUYfSIAtyjy6XRh70meA==
=TWba
-----END PGP SIGNATURE-----
ad...@mixmaster.shinn.net.no.spam.to
S.R. Heller <srhe...@oz.net> wrote:
> On Mon, 03 Jul 2000 20:01:05 GMT, ad...@mixmaster.shinn.net.no.spam.to
> wrote:
>>S.R. Heller <srhe...@oz.net> wrote:
>>
>>> I'm still waiting to hear how your block against Eelbash protects users from
>>> being exposed.
>>
>>I would call it protection again indistriminate content based censorship.
>>Censorship is far FAR worse in a remailer.
> This is our job?
I think you have lost the context of the original post, I made this comment not
the ORange Admin. If not, resume party.
> To take responsibility for the ultimate fate of every
> message that comes through?
We have some responsibilty for the privacy our users. For instance, changing our
keys regularly to prevent attacks, keeping our boxes secure to keep our keys from
being stolen and cracked without our knowledge (imagine if a high percentage of
remailers were totally owned by one party - there would be no privacy) and in
making sure our remailers don't keep logs, that we generate dummy traffic, pool
traffic to help hide it and so on.
You're damn right we have a responsibilty to our users.
> Our job is to deliver the mail and let the user
> protect his own privacy through chaining and encryption.
What if the user screwed up and left some headers in their message that identifies
them? Should we let that through? Do you have any idea how many headers get
filtered in a day by remailer alone that would do wonders towards tracking a user
down? As both a user and remop, I want other remops to take reasonable precautions
to help protect my privacy.
The goal of helping to protect the users privacy is not mutually exclusive with the
goal of delivering mail, except in the cases where the user is OBVIOUSLY shooting'
themselves in the foot. Not every user has a clue like you do. Some users need
help. Now, does this mean that any measure that enhances user privacy is good one?
No. Like I said, reasonable measures. What are those measures? Well, thats what
this discussions are for. I take my cues from the user community. I publish and
talk about what I did to my remailer or will do, and I listen to the users - like
I am right now. :-)
> When someone turns
> out to be a cop, then we block. Eelbash is only a zealous greenhorn.
Perhaps. Like I said, I havent made up my mind on eelbash yet. I would prefer to
address the larger issues here and not merely try to deal with a possible symptom
of a larger problem.
>>Your privacy is almost
>>guaranteed *if* you chain properly. But, whether your message reaches its
>>destination is a different story if a remop decides to censor your posts
>>by the *CONTENT* of those posts. Thats a horrible horrible presidence.
> You want a bad precedent, try remailers blocking remailers. What the hell is
> going to happen to our supposed network if this continues?
Perhaps we will raise the bar and require other remops to stick to their guns
a little more. I dunno yet. Thats what this discussion will hopefully
help lead us to a conclusion on. Perhaps its a bad idea to block any remailer
for ANY reason.
*Is* there any reason to ever block a remailer?
> Don't we have
> enough problems already? Again I ask: is this our job, to decide whether the
> next hop is, in our personal, subjective opinion, "good"?
Well, some remailers are dead - so in the binary case, yes we sometimes have to
drop mail bound for dead remailers to keep our mail queues moving (I once had 5000
messages in my queue for one remailer... in a day. All because that remailer
was dead a s doornail and users were still sending messages to that remailer.
Hell, I *STILL* get email for myriad!)
>>> Since this is the rationale behind the block, you should remove the block if
>>> you can't answer the question. Or, you should add "mon" to your capabilities
>>> string, since you admit that you are filtering messages from a specific
>>> group of people, i.e., people who decide for themselves whether or not to
>>> use Eelbash.
>>
>>Thats just down right absurd.
> I don't care about the stupid "mon". I was trying to make a point. He
> demands that Eelbash add "mon" to protect novice users, I am asking him how
> those novices are supposed to know that he is selectively deleting mail.
In that case then it seems that the way to prevent users from using remailers
altogether is to remove that remailer from the pinger lists. Then the new
users can't send mail thru or to that remailer. I am *NOT* suggesting that
anyone do that with eelbash. At least not yet, as I said before, I'm still
making up my mind over this.
Its the censorship caused by taking a side in a flame war that worries me. I
too had my share of complaints from people whining about fre...@freedom.org,
but being told the same thing, use killfiles, over and over again by me - they
moved on (for now). I'm opposed to taking sides in any debate. Unless its
really clear that the message was a clear death threat, spam or the legitimate
owner of a remailer address has asked for a destination block - I point them
to the wonderful world of killfiles.
Only once was I forced to add in a block on a newsgroup, and in that case I
only did it for a few days due to flooding. Since then I have added better
throttling, which hopefully will prevent flooding and mitigates the need
for any newsgroup filtering. Still, nothing is black and white in the
world of speech. Its always shades of gray unfortunately.
>>What is this obsession with the "mon" cap
>>string everyone has? How is filtering a destination monitoring?
>>ALL remailers can and do filter destinations. Thats not monitoring.
> I know, but we're talking about filtering other nodes in the remailer
> network. You don't see that is a little different?
Of course I see that as different, that was my point. What does mon
have to do with blocking?
> Also, will you be blocking Eelbash?
As I have said many times, I'm considering it - but I definitely have
NOT made up my mind. I do think users, in this case, can make up their
own minds - so I'm not in a rush.
- --
Shinn.net Anonymous Remailer Admin
PGP Key 1 ID: 0xD8D5B063 PGP Key 2 ID: 0x3C41F029
Key 1 fingerprint = C069 47E0 DF19 823F 2E34 393F 8A4E EC97
Key 2 fingerprint = A79A C4D7 F859 2F1D 26BE 5B34 9B34 0B29
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2
iQEVAwUBOWFaasQaFjc8QfApAQGTRgf9Ew5eWKv0ee5ZooaSWsldwc/cjD35eAWN
sCVyFQK+HsDiKP3xIp9wsOq9JlrIYb6Dmejonof4qGzzguWOK2xpO4JFfMxSXgGI
JckSepFrNHilv+AdLUd9F9zZBiwJ+EtFmfdjbdwfDOSx5c+ekn2mVfDXyOU6Z1P0
T1c5kCupaNbdW1IET3HwrhBjE7tc427A0fAcqugSl9eKxbADTykk2TpWtxsummWH
6K+GgKLvJ9jiBxVdvTBTGHy6KhouFbYdrk3E4PgN5/g0bMgAlfJ3Syzr8xmDfsiy
s0Io7h7xGzkKhAralCLKqElOyrSxPowYFNMmFnKzxOdQpBIglU4qmg==
=EJ2m
-----END PGP SIGNATURE-----
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGP 6.5.2
mQENAzlZOxsBbQEIAL0hs2EbjDPlSAJ+7rX1As7g2Iamx8aW5mSEadDPdJYjRWuM
TjC9gqqylRt5GV24eoGCibqQMztfZFF71HKG9pXEMPOTCjaXGPoq9dv/LDxTaqBI
D4SYLdQoZa7cVnvyn3CoU19+r6THr7gE55Pa68zv2mxQSAxe7NmRlJ0arikGSFiA
5a+ILctakIZ28kJZ0STTZFegiU+14TLKEJ16lXKb3+iyYOOfMoNcKt1MBOMX0bmg
Oo7/zhIm7cJkww6C66FBih1wxCiICkzne1oNT3h18TIziSUYENES/R3hKXbGKkoO
3ps9t9qPkLMPiMAFJNIUZ3hhRmX8xBoWNzxB8CkABRG0P1NoaW5uLm5ldCBSZW1h
aWxlciBBZG1pbiA8YWRtaW5AbWl4bWFzdGVyLnNoaW5uLm5ldC5uby5zcGFtLnRv
PokBFQMFEDlZOxvEGhY3PEHwKQEBVJcIAKyYA+kWR5L+V+MysFLozXUfXwD3nPgw
ZCOmBLpmujcc0CFhXWkUijqQ3pe+3fE6QDde9QiQHWJLNzX3jmE0KS/6VGmVkZsc
rsPy1wVZKamSy0l78X2VvCEiYQXhgnABrB6cQ0cbN1fob81leq+zSl6P9Oh1aqZk
/2EPYiNVljnAXndIvQNugb9mR5bJ8jMj/llulmxsZYHXjA23/fQ6NCNrM9Jvuk5e
8K2WyQ9nIC5D+W2s/BOuV/jyoHchrctIx6Rc0Ixu6ixxELjL3hXXCKU+8edzod3D
IkJjmw4x2U5di6jbvEfgbGXxIcd16xMmQRUkudABvgCPAyFNDc6j3iaJASwEEAEB
ABYFAjlZO2EPBmFudGktc3BhbSBrZXkAAAoJEJ5arobY1bBj2eoH/R89DWfvYoqH
Rf+s/X+Fm2XT2c3zVwhHzlf1wPVtpFNbVcyFiAZ0GhHNer61sobQygKsbgpUoAys
HOttCj1rRR4D7Q8tBO777CO+tWB+7B9GwOtNWs/dRgFiiVXYyaP1eCHs3PKfiROH
0VSGvvMVEpvPNgdIQZH6OndCkDlzFpgfOQBhpfJvtCPnK2iWUq+5N19nf4gD6Xyc
xy2rNw3+wk2gOP+A+SINBeknGJuYYKrBDEKrp4UrteSPsq5hN2vjida7nTqxgU1V
r/tDXc5Jp7NSN4szRwtxFd0x4QZDzD7eLk9Lht2m7a999SEl56ApRQ6X//psw8+l
yQGK+boDjAA=
=Qt9y
-----END PGP PUBLIC KEY BLOCK-----
ad...@mixmaster.shinn.net.no.spam.to
Jiggs McManus <nob...@eelknot.com> wrote:
> I need to do some testing with all the Mixmaster remailers. Tests will
> be conducted in alt.test.test.test for anyone interested.
Actually, if you wouldn't mind, a consolidate report to apas (in a different
thread) would be useful for both remops and users. Its always nice to have
outside parties conduct tests on your remailer to make sure its setup
right and bit rot hasn't fubared anything.
- --
Shinn.net Anonymous Remailer Admin
PGP Key 1 ID: 0xD8D5B063 PGP Key 2 ID: 0x3C41F029
Key 1 fingerprint = C069 47E0 DF19 823F 2E34 393F 8A4E EC97
Key 2 fingerprint = A79A C4D7 F859 2F1D 26BE 5B34 9B34 0B29
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2
iQEVAwUBOWFa0MQaFjc8QfApAQHwzAgAnby4qYKKClJLnXQXAWFHMDtf1IUEhk2s
VSQjPWZvlbMziBf3nqk3kuCWF535iR3PpmRVzJMWu+OlMdTAlAAFYxURD8yK7lK9
1D+2NPFwirlFk5lkKWN13eKIbDkFdYSXdLX+y4lGLwCP/zQ2NGFVa6V3FAEjrDEz
Im1sjVgak3JCPo3h2oBctYhMcj1eFOwxQELPBOYqNbe/StjbSxYkG1aPcSW3o5pq
VjyYGtT2YoDLssHcRbzaWpbFv9cXMzkcCmFbudruQF7sTOqH2oQkjmuseFzwHqM/
JZyZjBZZxsHPaWtvRNZ7bI50XmI9USjk+B0dpMhDMc+M1JC52zwLvA==
=Oew7
-----END PGP SIGNATURE-----
ad...@mixmaster.shinn.net.no.spam.to
Nomen Nescio <nob...@dizum.com> wrote:
> Only a third of the posts I sent have arrived, but so far Dizum, Shinn, Squirrel, and Lcs
> have only posted one copy of three identical Mixmaster messages sent to them.
Hurray! Duplicate detection is working! :-)
- --
Shinn.net Anonymous Remailer Admin
PGP Key 1 ID: 0xD8D5B063 PGP Key 2 ID: 0x3C41F029
Key 1 fingerprint = C069 47E0 DF19 823F 2E34 393F 8A4E EC97
Key 2 fingerprint = A79A C4D7 F859 2F1D 26BE 5B34 9B34 0B29
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2
iQEVAwUBOWFa/8QaFjc8QfApAQHAdwgAiBS88Kt3h/QM8gPiGqOtr5SMblvtUvTL
aRCRyeg7zytnRgSrPqlLiDVEqTzdUMey+aOkWB11MTVjj9sCEnkEIK/yEZte3bey
dIIPFPUq5xqzzPmMu0HOl7KRWwJywjir9uOR9JV61UZrTuatSrgw8NJWovsju6bl
5T3+0devJvxAZuazX3hQn7rMKScsUXpYl0qpARqddbkxPIZXArONNMREUlDBOFiy
uJRU6a2lRv/kMN0SwqseJP6jHbZMZH4Ca+LySv8Gwsr5dLUWJHMlOzceNI34kvA4
Z/55K98/k76SjGoNqdhEPH1erG3uPZaWXXYM721T+judDCO6UZ82Qw==
=2o3B
-----END PGP SIGNATURE-----
lcs Mixmaster Remailer
>
> S.R. Heller <srhe...@oz.net> wrote:
>
> > I'm still waiting to hear how your block against Eelbash protects
users from
> > being exposed.
>
> I would call it protection again indistriminate content based
censorship.
its
> destination is a different story if a remop decides to censor your posts
> by the *CONTENT* of those posts. Thats a horrible horrible presidence.
While I agree that content filtering is very dangerous, I do not think
this is the case with the eelbash incident. If I understood it correctly
he set certain specific blocking filters as a reaction to a complaint (as
any remailer operator is entitled to) and THEN published what got caught
in the net. I want to make very clear I believe that publishing the
messages is deadly wrong. It should not have happened. On the other hand,
I do not see the content filtering if we do not count filtering headers.
In case header-based filtering is called content filtering by somebody,
then most remailers, including orange and green, are also guilty.
>
> > An article leaves your remailer, anonymized, and goes to Eelbash. What
can
> > the Eelbash operator do to expose the original sender of that message?
>
> Probably nothing, but the eelbash remop can and did censor posts thru
> monitoring.
>
> > Since this is the rationale behind the block, you should remove the
block if
> > you can't answer the question. Or, you should add "mon" to your
capabilities
> > string, since you admit that you are filtering messages from a
specific
> > group of people, i.e., people who decide for themselves whether or not
to
> > use Eelbash.
>
> Thats just down right absurd. What is this obsession with the "mon" cap
> string everyone has? How is filtering a destination monitoring?
> ALL remailers can and do filter destinations. Thats not monitoring.
I agree. See my rant above. "mon" cap string is a non-sense that has been
re-invented by the orange operator. The idea is quite ridiculous as any
reasonable remailer user must assume that "mon" applies to every single
remailer. This is the sole reason for chaining.
In my opinion, orange wants to put as much distance between himself and
eelbash because he believes eelbash's operator sinned. I agree but I think
that blocking eelbash is not sufficiently justified. In fact, I believe it
does more harm than good. It transpires to: "You users have to make a
choice, either me or eelbash." This is a dis-service to the remailer
community. It adds another pair of entries to broken chains lists, which
are already very unreliable. With every entry, features like rhop are
becoming more and more worthless.
Farout Admin
In alt.privacy.anon-server, Anonymous...@See.Comment.Header (Lucifer)
wrote:
>In article <f5c430e8f219ed53...@mixmaster.shinn.net>
>Anonymous Sender <nob...@mixmaster.shinn.net> wrote:
[...]
>>
>> I may have committed user error as I used two mail2news gateways
>> in my To line - mail...@zedz.net,mail...@anon.lcs.mit.edu
This is the format used by farout in response to a post command.
>I use
>
>To: mail...@anon.lcs.mit.edu
>Cc: mail...@zedz.net
This form works good also. However, if the @zeds was spelled properly, it
would work better.
>Dunno if that's a factor, but I seldom get dupes.
Most of the dups, that I see, are messages hitting the m2n from different
"final" remailers.
Duplicates can only be detected if they go through the _same_ final
remailer, before the gateway(s), where replay dups will be detected on the
remailers input side. The first message received of a series of dups is
the one the remailer sends to the gateway(s), with a unique message-id.
It's up to the news servers to not accept more than one article with a
specific message-id, even when said article is posted via multiple
gateways.
If I do: ->auto->auto->m2n, I should see a duplicate posted for each
time I push the replay button, except for the times that my client randomly
chooses the same remailer for the last auto before the m2n.
If I do: ->auto->remailerX->m2n, I should be able to push the replay
button all day and only one copy will be posted.
- --
Farout Admin PGP-Key: 0x1A542807
PGP-Fingerprint: 9DCA ABB2 936D 5E62 06FD 2267 071E 8F0A
Finger: farout...@nym.alias.net
-----BEGIN PGP SIGNATURE-----
Version: N/A
iQEVAwUBOWI8gsFvBSQaVCgHAQE2XQgAhkBat15LSNFvpNDtlFCTTKSg/j39jck3
S0GxY0LL32bICHdjEngw4OiDy9eWHhLNRzspJFxulPw4QzFVL34RmcMCnjsRIYw2
V9r2yTwDaJB509CNW8pmZS1DDSE+FhELrykKeUhwKY+1+fRnYbAILY+zFbI4CRrS
LW0J07rrlu62bBfWpknTE4hfYuMbwa+/3q2w3IyqOpNQYASVBvcSWhGnF0uq4yzS
yjgjooBEpImlnzWovHPyvqVX38SQGX6Nv3jfR28aIjVfJrOK3XziTzbyhKTDjmxT
LfgYRIHP9TaTjF0pHTMpEFm6chfUk9Cll01S4V5cJk+dvrwS5u0zFQ==
=+Xz6
-----END PGP SIGNATURE-----
~~~~~~~~~~~~~~~~~~~~~
This message was posted via one or more anonymous remailing services.
Any address shown in the From header is unverified.
ad...@mixmaster.shinn.net.no.spam.to
S.R. Heller <srhe...@oz.net> wrote:
> On Tue, 04 Jul 2000 03:30:53 GMT, ad...@mixmaster.shinn.net.no.spam.to
> wrote:
>>We have some responsibilty for the privacy our users. For instance, changing our
>>keys regularly to prevent attacks, keeping our boxes secure to keep our keys from
>>being stolen and cracked without our knowledge (imagine if a high percentage of
>>remailers were totally owned by one party - there would be no privacy) and in
>>making sure our remailers don't keep logs, that we generate dummy traffic, pool
>>traffic to help hide it and so on.
>>
>>You're damn right we have a responsibilty to our users.
> I asked if it we were responsible for the ultimate safety of every message
> that comes through, meaning, not just keep our noses clean -- as in your
> examples -- but somehow deciding whether the next hop was safe enough, and
> the next hop, etc.
Don't you check your keys? To some extent, yes its important to know that
you are talking to the right remailer and that its operating correctly and
securely. In most, if not all cases, there is no need to do more than
make sure the keys are right. Outside of that, users have a responsibility
to determine if the chain they are using meets their security criteria.
Security can sometimes seem at odds with a users goals. As Adam has said,
and I am taking some liberties with his terms, Information security
can be described as arranging for systems to do what is intended
*and nothing else*.
User and system security are not mutually exclusive.
> You say you've got responsibilities, and I can only
> agree, but where does your responsibility end? I say it ends when the
> message 'leaves the building.' Orange thinks it extends into the next hop,
> and if you don't think that next remailer is kosher you should euthanize the
> message for its own good.
Mostly I would agree, however in cases where a remailer is totally compromised
I think all remops have an obligation, as do the pingers, to notify endusers
that a remailer is no longer safe to use.
> All of your examples talk about how each operator should behave in his or
> her own sphere. If agree. Orange is acting based on how another operator
> behaves. I see a difference there, do you? I don't see any basis for any of
> us to say, "Eelbash is your next hop? Your message is better off dead. This
> is for your own good." This attitude reeks of paternalism and Father Knows
> Best. I thought we were against that, but then I'm always surprised at what
> attitudes turn up in this group. I should just stick with "I" and not we.
Like I've said, I have not made up my mind yet on this yet. I'm deeply troubled
by what eelbash is accused of doing and some of things I *think* he's said
(but alot of forgeries have been going around claiming to be from eelbash-
admin, so its hard to say). I'm waiting to hear from eelbash-admin.
>>> Our job is to deliver the mail and let the user
>>> protect his own privacy through chaining and encryption.
>>
>>What if the user screwed up and left some headers in their message that identifies
>>them? Should we let that through? Do you have any idea how many headers get
>>filtered in a day by remailer alone that would do wonders towards tracking a user
>>down? As both a user and remop, I want other remops to take reasonable precautions
>>to help protect my privacy.
> Left some headers in their message? I don't understand. All remailer
> software that I'm aware of completely removes the head and create a new one
> based on the directives in the body. Any headers in the outgoing message
> should have been placed there by the remailer (disclaimer) or the user.
> However, I'll treat the question as hypothetical. Should we let that
> through? Yes. It's their risk to take. Of course, this is a matter of
> personal philosophy.
Apparently some of the clients are putting WAY too many headers in their messages.
And being a remailer user as well as remop, I *want* that added layer of security in
every remailer I use just in case I fuck up. I'm human and I make mistakes, and if
my error log is any indication, alot of other users mess up their messages too.
(for the paranoid, remailers log errors with their systems so we can fix them. Error
logs do not log things like inbound/outbound messages and mine does not even log the
time... which can be a real pain when trying to track down a bug...)
>>The goal of helping to protect the users privacy is not mutually exclusive with the
>>goal of delivering mail, except in the cases where the user is OBVIOUSLY shooting'
>>themselves in the foot.
> Sure, but here's the big question: is it 'shooting yourself in the foot' to
> send a message to Eelbash?
That is the question and I do not have an answer to it yet. What I'm hoping
is that some collective wisdow will come from all this so we have a reasoned
and well thought out answer to that question.
> Is it so potentially dangerous that users should
> be not only warned but stopped for their own good? Orange seems to say yes,
> though he does say he won't block if there is a warning. I say no, on the
> principle that people should be free to make their own mistakes.
Perhaps.
>>> You want a bad precedent, try remailers blocking remailers. What the hell is
>>> going to happen to our supposed network if this continues?
>>
>>Perhaps we will raise the bar and require other remops to stick to their guns
>>a little more. I dunno yet. Thats what this discussion will hopefully
>>help lead us to a conclusion on. Perhaps its a bad idea to block any remailer
>>for ANY reason.
>>
>>*Is* there any reason to ever block a remailer?
> I want to say No, but I can't. There must ultimately be a reason. It occurs
> to me that it would be hard to really know if a remailer was completely
> crooked -- until the subpoenas started rolling in. Still, while I can't say
> never, I can say almost never. Users should be safe to assume that, all
> things being equal, their message will get from A to B. Personally, I think
> we should try to be, as much as possible, just conduits.
I totally agree, which is why eelbashes behavior is so vexing. Getting involved
in a flame war, even if all you do is call one side of it a "psycho" and publish
information that might help to reveal that person real identity is not being
a conduit. So theres my dilema. I always act as just a conduit. Its ethically
consistent with my personal stand on freedom of speech and, thankfully, its also
the safest legal position to take since it doesnt make me a publisher - and so
far that appears to make not liable for what users send thru my remailer.
> That's an ideal,
> not something we will achieve. We take the message in, we pass the message
> out. We don't try to make judgments about the message, good or bad.
Thats pretty much my take on it. (which is why I'm willing to take so much
time thinking and talking about this issue before I drop any mail) However,
there is a principle at stake here, being just a conduit, that eelbash seems
to have breached. So the other issue that needs adressing is what to do
about remops that act as eelbash has. Is this discussion enough? Or do we
need to do more to keep remops honest?
>>> Don't we have
>>> enough problems already? Again I ask: is this our job, to decide whether the
>>> next hop is, in our personal, subjective opinion, "good"?
>>
>>Well, some remailers are dead - so in the binary case, yes we sometimes have to
>>drop mail bound for dead remailers to keep our mail queues moving
> But working remailers vs. not working is a question we ask for the good of
> our queues. That's purely an operational concern. Safe remailers vs. unsafe
> is a question we ask for the good of the users. Orange wants to ask that
> question, I don't -- because what I call safe is not what someone else would
> call safe. How about that ancient PGP key at LCS? Safe?
Point taken. I think the issue with eelbash is one of principle and perhaps
orange is doing us all a favor by taking the heat and drawing much needed
attention to the issue of remop behavior. What do we do if a remop decides
to log everything, make those logs available in real time and even modifies
their remailer to log latency times and so on to help tracking someone down?
Certainly someone could be doing this now. What should be done if a remop
were caught doing that? Would that warrant blocking that remailer? Or
should we just accept that possibility and move on to creating a system
which is not vulnerable to those attacks (in theory the current system
should not be vulnerable to those attacks... but collusion is always an
ever present problem with the current system...)
All thought provoking stuff that certainly has caused me to rethink the
current system. There are weaknesses in it and we need to think about ways
to strengthen the model, IMHO. Be the technical (my preferred approach),
human systems or both.
- --
Shinn.net Anonymous Remailer Admin
PGP Key 1 ID: 0xD8D5B063 PGP Key 2 ID: 0x3C41F029
Key 1 fingerprint = C069 47E0 DF19 823F 2E34 393F 8A4E EC97
Key 2 fingerprint = A79A C4D7 F859 2F1D 26BE 5B34 9B34 0B29
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2
iQEVAwUBOWLXGMQaFjc8QfApAQGGyAf/WcZG1RzC32/0CPvkyocc1yMwJPdOZSLL
os+Jn8t1i9HQ0oxmJW6Eq5TKdqZahY30RNu6yEu8cI6N4kcwOo2vsjhgfnK1QdTH
b1YZp0iQICWn3XTt2UteLzQ+M7r5/e1aZlUx+Sq0Rx6kIMa3u6ALqvLPIsKHKky0
MwB/VujW5FRcYOpLGchiXRjmPc48sFEkOq1vXDhoRZjO9r3FURcu/ctalYSqiwXq
ej4C4iTipyjx4oBNJGqfjHurWCXj4Olfg0Fjj/i+jJ8pT0FYMR6q/hHpXKsvoH7p
/1HukIO4gZ9ezn7HZFxETcXLht4PW+jOn22vSIMdMQM8pmL3o88b2A==
=pHQH
-----END PGP SIGNATURE-----
Secret Squirrel
wrote:
>I would call it protection again indistriminate content based
>censorship. Censorship is far FAR worse in a remailer. Your
>privacy is almost guaranteed *if* you chain properly. But,
>whether your message reaches its destination is a different story
>if a remop decides to censor your posts by the *CONTENT* of those
>posts. Thats a horrible horrible presidence.
Shinn, that's absolutely right. A remailer admin who is going to
censor posts should let all users know what type of posts won't
get through. Of course, the op will probably be shunned to a
degree (and rightly so). Everything about anonymous posting is
about the freedom of an individual to say whatever he/she wants
to say without repercussion. If we can't do that, then what's the
point, and why should users have to worry about what they're
saying anyhow? The WHOLE POINT is not to have to worry about what
you say. For *whatever* reason. A remailer op who doesn't fully
support freedom of speech is a complete oxymoron.
ad...@mixmaster.shinn.net.no.spam.to
Anonymous Sender <nob...@mixmaster.shinn.net> wrote:
>> Everything about anonymous posting is
>> about the freedom of an individual to say whatever he/she wants
>> to say without repercussion. If we can't do that, then what's the
>> point, and why should users have to worry about what they're
>> saying anyhow? The WHOLE POINT is not to have to worry about what
>> you say. For *whatever* reason. A remailer op who doesn't fully
>> support freedom of speech is a complete oxymoron.
> But the concept of 'freedom of speech' has its limitations.
> It's not an absolute.
> i.e. 'You can't yell "FIRE" in a crowded theater.
Sure you can if you think there is a fire.
- --
Shinn.net Anonymous Remailer Admin
PGP Key 1 ID: 0xD8D5B063 PGP Key 2 ID: 0x3C41F029
Key 1 fingerprint = C069 47E0 DF19 823F 2E34 393F 8A4E EC97
Key 2 fingerprint = A79A C4D7 F859 2F1D 26BE 5B34 9B34 0B29
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.5.2
iQEVAwUBOWNPQ8QaFjc8QfApAQFCGAgAm3yl7xKYMj8O5bETCkMDIBvXOrE/weDm
kTL1rMcLwGZIoHn51uWwor3IdInuZclkb4zYpivX7LNWna097Pqn3Lg6PudGdtDq
4y2oljmMgnCsgibd9MFPRZ3MC53oO7i1Gu7tz7DNwMS/dVmrIJg5oMsAnXXzQmfE
/3T1QmaW4dEk01ZvispvTNthbvYIukSv+xuXOlKbyGU5r7IDS75U6EiU4B6Vfzj5
0knKSuH9QRwrvumiJAyWLu/wdOcB6UrxLAL+k8ydHnOh0SgKPHczrMJeGuTiiD9N
bhPRdbjzhwI14JeC2BiQWWOGxYSafIyNLgLKPJY5jWOtR2LEAk1pbg==
=Idid
-----END PGP SIGNATURE-----