1997-12-02 - Re: Pasting in From:

Header Data

From: Charlie Comsec <comsec@nym.alias.net>
To: remailer-operators@anon.lcs.mit.edu
Message Hash: 6d38487c9e402b3d0a6d523c3ff1ce3c44665a28dadfbacaba53ace03d686e3a
Message ID: <19971202170009.20761.qmail@nym.alias.net>
Reply To: N/A
UTC Datetime: 1997-12-02 17:13:22 UTC
Raw Date: Wed, 3 Dec 1997 01:13:22 +0800

Raw message

From: Charlie Comsec <comsec@nym.alias.net>
Date: Wed, 3 Dec 1997 01:13:22 +0800
To: remailer-operators@anon.lcs.mit.edu
Subject: Re: Pasting in From:
Message-ID: <19971202170009.20761.qmail@nym.alias.net>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----

- -----BEGIN PGP SIGNED MESSAGE-----

stewarts@ix.netcom.com wrote:
 
> >(I would like to see Cc: and Bcc: being allowed to be pasted in also).
>
> At minimum, addresses in Cc: and Bcc: need to be checked against
> blocking lists, and it's probably worth checking the number of
> names in the list against some threshold - especialy Bcc:s,
> which tend to be popularly used by spamware.

As long as blocking requests are authenticated with some sort of "cookie"
token scheme, that would be acceptable.  That goes for INDIVIDUAL blocking
requests.  Somewhat more discretion ought to be used for requests to block
an entire domain. That should probably only be done upon request from the
"postmaster" at that domain, and when an entire domain is blocked, that fact
should probably be announced in advance, publicly, in alt.privacy.anon-server to 
inform users in that domain who might not have been made aware of the action and
who might need to recreate 'nym reply blocks, etc., before their incoming mail
gets embargoed.

For example, if I had a 'nym with a reply block that directed replies to my
e-mail account at work (I don't, BTW), and my employer decided that it no longer
wanted its employees to be able to receive anonymous e-mail, then it would only
be polite for the employer to notify the employees well in advance of that
policy change.  But in case the employer failed to do so, a public notice should
also be made.

In fact, I'd say that domain-wide blocking requests should only be accepted from
"postmaster" or one of the contact addresses listed with InterNIC for that domain.
One large ISP, for example, allowed a user (who was not an employee nor a
representative of the ISP) to sign up for the user ID "abuse".
 
> >I would also like to see From: pasted in.  In fact I can see no
> >purpose to restrict what can be pasted in, other than to reduce
> >complaints to the remailer operator possibly.
> 
> Too easy to be abused by forgers, as are Reply-To: and Sender:.

I'm not sure what the actual use of a "Sender:" header is, but pasting in a
"Reply-To:" header is not technically forgery, since it does not imply where
a message came From:.  It is only a suggestion where replies should be
directed.  When the From: and Reply-To: lines both exist, but differ, most
software gives the user an option of which address to reply to.  Thus, in the
final analysis the person replying makes and is responsible for the decision
as to where to send his reply.
 
> >My software shows be all headers.  I am not sure what other software
> >would do, probably, only display the first From field (the remailers).
> >  
> MSMail and other closed systems are generally quite arrogant
> about only showing you the mail headers they "know" you want to see,
> and discarding the rest, whether that's what you want or not.
> Lots of mail clients only show you one From:, either discarding  
> others or making them available in a "Show all headers" mode.

All the more reason to only allow pasting in the replacement mode.
   
> There are other remailer-like systems that provide mailboxes
> for anonymous retrieval; I think Jenaer does something like that.
> And then of course there are hotmail and juno :-)

That doesn't solve the problem of how to post with a NON-replyable
pseudonym, though.  It has been suggested that the practice of pasting in
a From: header should not be allowed because it is subject to abuse and
that this can better be accomplished through a 'nym server.  But if the
person doesn't want e-mail replies, why should a 'nym server be burdened with
maintaining a reply mechanism that the 'nym owner doesn't want to use?  Even
if the reply block is redirected to /dev/null@somedomain.com, handling
replies, incoming mail bombs, etc. is unnecessary work.

The fact that the remailer net has implemented source-level blocking upon
request means it already has more safeguards in place against "forgery" than
90% of the ISPs have.  It's quite ironic to see people like Gary Burnore
complain that allowing a remailer user to set an arbitrary From: is "abusive"
when the ISP he (and you) post from, Netcom, allows that very thing.

There are actually two valid reasons I can think of to paste in a From: header:
One is to post "from" a pseudonym without having to go through the 'nymserver.
For example, to make posts and send correspondence when the 'nym server is down
or to be able to post from a non-secure site without having to compromise
security by making one's PGP secret keyring accessible at that site.

The second reason would be to post using a non-replyable pseudonym.  Many
newsreaders gather only the headers of Usenet messages and list them by their
Subject: and From: lines.  Without the ability to set a From: line, one's posts
to a thread are indistinguishable from all the other ones from 
"nobody@replay.com".  If I want to call myself "Santa Claus", it's far easier
to paste in a "From: Santa Claus <sclaus@northpole.gov>" than to go to the trouble
of creating a replyable 'nym at a 'nym server just to put something recognizeable
in the From: header.

The problem with eliminating any feature that gets abused is that it's an open
invitation for someone to deliberately abuse it just to get it eliminated.
Whenever possible, a solution should be sought which eliminates abuse while still
allowing legitimate use.

- - --
Finger <comsec@nym.alias.net> for PGP public key.

- -----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBNIQzwwbp0h8ZvosNAQFLpgf+LS9VIGvUV3JKRHp+/ZtoRUkhNgH0h2Jg
tr/5gazeo+k0EHnaA/jvdnZ2HKSSkKguXaAnzejBnTtfvfQa38GcWBZsve/4fC9e
YAv80++wGj/0RhgwNEp8ovm57u5KQmybOqxmfeQ8H/cc8jyfhZEBGb2sxIbqvze5
NvzMGUHpKfUfduxo+kGeoOPOO+CkpM1sd5RmFSPojd6DgG3gNELjLD1jWLpZT7BC
YlBOJFh39ibssjQQO1lcLokdgqlDLQZWx1Lar9fyuWHlO5z+2wKkI+MICMkF32YE
dd3sPuhZxEGZGHyV+gybqm961G/7VctAXWrKlXuELb1HYUpsSkU+GA==
=Q+h9
- -----END PGP SIGNATURE-----

~~~
This PGP signature only certifies the sender and date of the message.
It implies no approval from the administrators of nym.alias.net.
Date: Tue Dec  2 17:00:03 1997 GMT
From: comsec@nym.alias.net

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQEUAwUBNIQ+mE5NDhYLYPHNAQHVxQf3Y3DTPTUfLoQ/4qMM4Dxn58WS3zGQQpG3
+R6nVXONkQ5NpkSEdhoJDA8ANU9Xf/Bd0o1WtVhoTzutqULMUQjKKPKUtda/rxHh
IkhgeFHuTq8jYfLso0MQkWFDGusd3BKacChKF83Rp0s6lOUZw0gr+ejVQNK6jLR6
PCzu5arH+X5y/4kRL12mLk/q72wW6ghN28b/9ogL+P8dWVfQjpSkJBA77OX4bQqE
2EixaU9xOwUOcBWnvmukXaPZF2PQ99MGOVQ9xZrdP6TSpWcmgbW1gg0xBPn6uCkl
VD/TWTnCGMF86n0La85nx8/ypR6GxpyrcSrBpdkUdhgU61xmNXyS
=aLBH
-----END PGP SIGNATURE-----






Thread