Anonymous Servers - Minion Q's

Author

Minion Q's

nobody@firenze.linux.it

2007-03-26, 1:16 am

Deuxpi Admin

2007-03-26, 1:16 am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Not being an expert I'd like to understand how what seems
> like a simple mail transaction would not be handled by
> a remailer?

The Mixminion network uses its own protocol for message transport. Nodes that
are "middleman" don't need to use SMTP at all. So, no SMTP = middleman.

> There's one that always shows George Orwell even if the
> config page says from headers are supported, it's
> mixmaster.it I think but I haven't been able to isolate
> which minion node nick it goes under.

I'm not sure I'm following...

> Does anyone know of a stat page such as the mixmaster
> echelot ones where mixminion headers mail/usenet would
> be listed as applicable using this method? (I know usenet
> support is still lacking).

The best thing yet is <http://privacy.outel.org/minion/>

> In the wishlist dep. I'd like to invite the operators
> to swing the [Anon] who@wherever to who@wherever [Anon]
> for better sortability in mail/news readerware.

The way the software works now, it's this or nothing...

> In the same vein, please reduce/kill the text-body
> disclaimers which are a real pain for persons reading.
> I understand the frustrations concerning frivolous
> bitchmessages! Could a link to a complaint web-FORM not
> be used instead of the usual abuse@herethere? Such a
> form could autofilter incomplete complaints with no
> message ID etc. Just a thought :-)

Well... Mixminion is in development, so you should not be using it for anything
serious. Also, I think the current system (meaning Mixmaster) for dealing with
abuse works OK. Most people reporting abuse don't even seem to read the mail
headers and just email every address they can think of.

- --
Deuxpi Admin <deuxpi-admin@deuxpi.ca>
http://www.deuxpi.ca/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGBuYDzQ0RLMqB8s4RAlUUAJwMZo0uB8Gp
g5kGWdt00AL1UPE8iQCdEH3A
guAYjOz8pAKD/Q+C6u1XMCE=
=ZuOW
-----END PGP SIGNATURE-----

nobody@firenze.linux.it

2007-03-26, 1:16 am

This is a Type III anonymous message, sent to you by the F.L.U.G.
(Firenze Linux User Group) mixminion server at firenze.linux.it. If
you do not want to receive anonymous messages, please contact antani-
admin@firenze.linux.it. For more information about anonymity, see
https://remailer.firenze.linux.it or
https://e-privacy.firenze.linux.it.

-----BEGIN TYPE III ANONYMOUS MESSAGE-----
Message-type: plaintext

Deuxpi Admin wrote:
>
> The Mixminion network uses its own protocol for message transport. Nodes that
> are "middleman" don't need to use SMTP at all. So, no SMTP = middleman.

Thanks, I didn't know the middleman concept still existed
in the mixminion network.

It's not as much of a problem as it is with mixmaster where
only a few allow from headers. Almost all minion servers
accept them and show the header the same way i.e. for a
supplied from header of mehere@thisnet the delivered header
is [Anon] mehere@thisnet <nobody@pboxlevel3.homelinux.net>
but one or two embed so that the delivered header becomes
[Anon] mehere@thisnet <@anon.lcs.mit.edu <"anon"@sli.mine.nu>>
This last one is too long and becomes truncated anyway.

The two types end up in (Thunderbird) message lists like
[Anon] mehere@thisnet &
[Anon] mehere@thisnet <@anon.lcs.mit.edu

There is not so much a need to specify an exit point using
mixminion and I was only tooling around with the -P "*1,final"
format to systematically test the final output from each.

With a -P "*2" the process will handle the middleman issue
transparently (I presume).

>
> I'm not sure I'm following...

I still need to pin down which one it was, but its config
showed "Allow-From: yes" as I think they all do but a
supplied from header like mehere@thisnet got replaced with
George Orwell. Even tried putting it into quotes but it
done did it again.

>
> The best thing yet is <http://privacy.outel.org/minion/>

I'm using it.

>
> The way the software works now, it's this or nothing...

Ergo, wishlists.

>
> Well... Mixminion is in development, so you should not
> be using it for anything serious.

I'm not, but I decided to get my feet wet (as it seems
poised to replace mixmaster) and it's working quite well
otherwise, amazingly well. But then mixmaster has never
been anything but beta either :-)

> also, I think the current system (meaning Mixmaster) for dealing
> with abuse works OK. Most people reporting abuse don't even
> seem to read the mail headers and just email every address they
> can think of.

Sure, we all know the associated headaches, and that's even
before the anti-anon trolls get in on the act. Which is
exactly part of the point, if usenet readers get ticked off
at seeing all these disclaimers that surely can't help in
the PR department.

As I said, it's just an idea. I would reduce the currently
standard 10 line disclaimer to a single one at the bottom
(below the sig if there is one)

"Anonymous-III. Click this to report complaints"

which would be a link to a web-form that needs (and gives)
specifics and keeps bouncing until it gets them, until the
complainee gets fed up, or until the cows come home. I would
even include the 'courtesy' of automated email validation
also using mixminion whereby they would have the 'opportunity'
to receive yet another anon message to confirm ..much the
same way that listservers do.

While I'm here....

Anyone know how to get mixminion to accept accented
characters in the subject header?

TIA
-----END TYPE III ANONYMOUS MESSAGE-----

Deuxpi Admin

2007-03-26, 1:12 pm

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> It's not as much of a problem as it is with mixmaster where
> only a few allow from headers. Almost all minion servers
> accept them and show the header the same way i.e. for a
> supplied from header of mehere@thisnet the delivered header
> is [Anon] mehere@thisnet <nobody@pboxlevel3.homelinux.net>
> but one or two embed so that the delivered header becomes
> [Anon] mehere@thisnet <@anon.lcs.mit.edu <"anon"@sli.mine.nu>>
> This last one is too long and becomes truncated anyway.
>
> The two types end up in (Thunderbird) message lists like
> [Anon] mehere@thisnet &
> [Anon] mehere@thisnet <@anon.lcs.mit.edu

I guess the developers were trying to find a header style that would
make every remailer operator feel comfortable. The side effect is that
it may have rendered the whole thing useless...

I'm just wondering... Would the benefits of having custom From headers
much less important if there was a secure and easy to use Nym
architecture? I think this is a goal for Mixminion.

> I still need to pin down which one it was, but its config
> showed "Allow-From: yes" as I think they all do but a
> supplied from header like mehere@thisnet got replaced with
> George Orwell. Even tried putting it into quotes but it
> done did it again.

Finally, found it. It's "xbox", and it will remix the messages through
the Mixmaster network:

Delivery/SMTP-Via-Mixmaster/Server='george'

So the Mixmaster remailer (george) did it, and the "Allow-From: yes"
option is quite meaningless in this context.

> Sure, we all know the associated headaches, and that's even
> before the anti-anon trolls get in on the act. Which is
> exactly part of the point, if usenet readers get ticked off
> at seeing all these disclaimers that surely can't help in
> the PR department.
>
> As I said, it's just an idea. I would reduce the currently
> standard 10 line disclaimer to a single one at the bottom
> (below the sig if there is one)
>
> "Anonymous-III. Click this to report complaints"
>
> which would be a link to a web-form that needs (and gives)
> specifics and keeps bouncing until it gets them, until the
> complainee gets fed up, or until the cows come home. I would
> even include the 'courtesy' of automated email validation
> also using mixminion whereby they would have the 'opportunity'
> to receive yet another anon message to confirm ..much the
> same way that listservers do.

This is what the Mixminion spec has to say:

2.4. Abuse prevention

Right now, we have some vague ideas about users emailing admins to
get themselves blacklisted. This should be specified and
automated.

Additionally, there are probably some other means of preventing
abusive behavior. If these don't make it into the specification,
they should at least appear in a best-practices document.

[3Aug: Dybbuk says he will specify cookie opt-out protocol.]

The spec acknowledges that the situation is far from ideal, and I
think the abuse protocol specification is still missing. I like the
idea of a "cookie" that may assure that the user cannot file a
blacklisting request without some evidence. It gets a bit more
complicated when you add mail2news gateways to the problem.

Once the user has a valid "cookie" it does not matter if the request
is done by email or from a web gateway. It is just safe to assume that
the user has access to email.

> Anyone know how to get mixminion to accept accented
> characters in the subject header?

In Python 2.5, you may use something like...

- -----BEGIN QUICK HACK-----
import email.header

def encode_subject(subject, charset='iso-8859-1'):
h = email.header.Header(subject,
charset=email.header.Charset(charset))
return str(h)
- -----END QUICK HACK-----

- --
Deuxpi Admin <deuxpi-admin@deuxpi.ca>
http://www.deuxpi.ca/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFGCAW9zQ0RLMqB8s4RCHkBAJ4qc8uHakfI
pRw28aNTIwDAM6ZQXwCeJZxG
gHM20erc900IO9WPwsROzXM=
=L6FF
-----END PGP SIGNATURE-----

nobody@winstonsmith.info

2007-03-28, 1:12 pm

This is a Type III anonymous message, sent to you by the Mixminion
server at winnie.winstonsmith.info. If you do not want to receive
anonymous messages, please contact winnie-admin@winstonsmith.info

-----BEGIN TYPE III ANONYMOUS MESSAGE-----
Message-type: plaintext

Deuxpi Admin wrote:
> ...
> I'm just wondering... Would the benefits of having custom From headers
> much less important if there was a secure and easy to use Nym
> architecture? I think this is a goal for Mixminion.

This is over my head & I don't really know what I'm talking
about. Ingeniuous and obviously inoperable alias From: headers
have been used since before the advent of anonymizers. For
times when open/anon response to an anon message may be desired,
I've never needed/used any nym remailers but as I understand it
SURBS will work with mixminion usenet as well as email once
usenet support is integrated.

> Finally, found it. It's "xbox", and it will remix the messages through
> the Mixmaster network:
> Delivery/SMTP-Via-Mixmaster/Server='george'
> So the Mixmaster remailer (george) did it, and the "Allow-From: yes"
> option is quite meaningless in this context.

Thanks very much! It sure looks like I would have needed much
more 'time' to nail this one :-)

>
> 2.4. Abuse prevention
>
> Right now, we have some vague ideas about users emailing admins to
> get themselves blacklisted. This should be specified and
> automated.
>
> Additionally, there are probably some other means of preventing
> abusive behavior. If these don't make it into the specification,
> they should at least appear in a best-practices document.
>
> [3Aug: Dybbuk says he will specify cookie opt-out protocol.]
>
>
> The spec acknowledges that the situation is far from ideal, and I
> think the abuse protocol specification is still missing. I like the
> idea of a "cookie" that may assure that the user cannot file a
> blacklisting request without some evidence. It gets a bit more
> complicated when you add mail2news gateways to the problem.
>
> Once the user has a valid "cookie" it does not matter if the request
> is done by email or from a web gateway. It is just safe to assume that
> the user has access to email.

As an end user (usenet) I am first interested in my 2 needs
for anonymity and threadabilty (reader friendliness). Second
I unconditionally support and sympathize with the needs of
server operators without whom I couldn't do it easily. From
my own perspective I have no interest in complainers except
maybe acceptance of a person's right to blacklist himself.

>
> In Python 2.5, you may use something like...
>
> -----BEGIN QUICK HACK-----
> import email.header
>
> def encode_subject(subject, charset='iso-8859-1'):
> h = email.header.Header(subject,
> charset=email.header.Charset(charset))
> return str(h)
> -----END QUICK HACK-----

I know no Python, but make rudimentary bash scripts like

#!/bin/bash
/home/xyz/min/bin/mixminion send \
- -t mail2news-20070326-alt.test@anon.lcs.mit.edu \
- -P "*2,winnie" \
- --input=/home/xyz/min/infile/source.txt \
- --from="nospam@no.org" \
- --subject="Re: Minion Q's" \
- --references="<eu90is\$k6o\$1@bananasplit.info>" \
- --in-reply-to="<eu90is\$k6o\$1@bananasplit.info>"

How could I do the same in bash or must I run mixminion
from Python? Don't really need more learning curves but
if there's no other way then...

Thanks very much.

-----END TYPE III ANONYMOUS MESSAGE-----

Deuxpi Admin

2007-03-29, 1:13 am

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> How could I do the same in bash or must I run mixminion
> from Python? Don't really need more learning curves but
> if there's no other way then...

It is probably not possible to encode a string in quoted-printable directly from
bash, but a little bit of PERL can do the job:

#!/bin/bash
/home/xyz/min/bin/mixminion send \
-t mail2news-20070326-alt.test@anon.lcs.mit.edu \
-P "*2,winnie" \
--input=/home/xyz/min/infile/source.txt \
--from="nospam@no.org" \
--subject="=?iso-8859-1?q?`echo "Re: Minion Q's" | \
perl -pe 'use MIME::QuotedPrint; $_=MIME::QuotedPrint::encode($_);'`?=" \
--references="<eu90is\$k6o\$1@bananasplit.info>" \
--in-reply-to="<eu90is\$k6o\$1@bananasplit.info>"

If you have a problem (like me) with UTF-8 being passed to PERL and getting
weird things on output, it gets ugly fast:

--subject="=?iso-8859-1?q?`echo "Re: Minion Q's" | \
perl -pe 'use MIME::QuotedPrint; require Encode; \
$_=MIME::QuotedPrint::encode(Encode::dec
ode_utf8($_));'`?="

Sorry for the mess

- --
Deuxpi Admin <deuxpi-admin@deuxpi.ca>
http://www.deuxpi.ca/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFGCwbMzQ0RLMqB8s4RAuVTAJwPkvGwmu4B
bh7p0cCnV4lAjLAmfgCYuOK6
5RqQlu0AbLjsphF553bfkA==
=2Slm
-----END PGP SIGNATURE-----