1995-01-19 - Re: Anti-Spam Methods

Header Data

From: “L. McCarthy” <lmccarth@ducie.cs.umass.edu>
To: cypherpunks@toad.com
Message Hash: 7ffd9200d5b8f37d82ad613d495f62e96c36244291062fba0f64ab6b54b0c90c
Message ID: <199501191035.FAA07879@bb.hks.net>
Reply To: N/A
UTC Datetime: 1995-01-19 10:30:36 UTC
Raw Date: Thu, 19 Jan 95 02:30:36 PST

Raw message

From: "L. McCarthy" <lmccarth@ducie.cs.umass.edu>
Date: Thu, 19 Jan 95 02:30:36 PST
To: cypherpunks@toad.com
Subject: Re: Anti-Spam Methods
Message-ID: <199501191035.FAA07879@bb.hks.net>
MIME-Version: 1.0
Content-Type: text/plain


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

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

Nathan Zook writes:
> Ivan Boskey?  (sp)

"Boesky"

[...]
>      We are capable of controlling mail bombs, for instance, in the
> following way:
>  
>      Take an incoming message, capture From: line.  Strip header.  MD5 body.
> Add to sorted table [From: MD5(message) date].  Check for repetition of
> first two fields.  If reps = 1, forward message.  If reps = 2, send message
> to From:  "Possible error.  Two copies of message <message> received."  

We were just discussing this on the remailer operators' list. Homer was
mulling over sending an automatic acknowledgement of each article submitted
for anon posting. I pointed out that From: lines (and even From lines) are 
notoriously unreliable. For example, in the Scythe spam, the articles were
ostensibly from various people @crl.com. Autoacks might have raised the ire
of plenty of people, but wouldn't have reached the real perpetrator.

> If reps = 0 mod 5, send letter to postmaster@From:.  "Possible mailbomb or
> spam.  <reps> copies of <message> received from <From:> at your site in the
> past week." Clear table of entries more than a week old every midnight.

This would necessitate keeping full logs of all traffic passing through the
remailer for up to a week. Speaking only for myself, I can't imagine adopting
such a remailer policy. YMMV.

>      If all remailers did this, then no matter where the net was entered,
> the messages would be rejected.  And spammers/bombers would be spamming/
> bombing their own postmaster.  

Again, in a forged-spam case like Scythe, the spammers/bombers would be
inducing the remailers to spam/bomb some arbitrary postmasters -- perhaps even
the remailers' postmasters -- as a side effect.

A "call-back" scheme might, however, be used to verify an originator's 
address. In this scheme, when a remailer receives a message for remailing, it
generates a few lines of random garbage and associates them with the message.
These lines are sent, along with a hash of the original message, in a brief 
ack message to the address in the From: line of the message. The headers of 
the message are discarded. When the remailer receives a message with a 
Callback: header, it checks the reply against the table associated with the 
current message pool. If a match is found, the associated message is marked 
ready for remailing. After a fairly short period, a message which still hasn't
been marked for remailing is deleted.

With chaining, more record-keeping by the remailers would be needed. The
remailers can't automatically honor all callbacks from other remailers, 
because wise forgers would simply forge their mail so it appeared to originate
from some known remailer address. So each remailer would need to keep (for a
brief period) a hash of each message it remails, in order to decide which
callback queries to answer. A list of current remailers could be used to
winnow out messages which are not being remailed to other remailers, and hence
need not be hashed and kept.

This protocol would aid a remailer operator who decided to trace a spam in
progress, because it should prevent spammers from forging their messages.

Couple this with mandatory appending of encrypted reply blocks, and the
release valve of two-way communication might be opened. Legal proceedings
obviously can't be brought successfully against anonymous parties, so 
achieving common carrier status is about the only antidote to that problem
I can foresee at the moment.

I'm thinking about working on code to implement some of this stuff in existing
remailer software, so I'm especially interested in hearing objections, flames,
suggestions, encouragement, etc. about it. I've spent a while contemplating
the wants and needs of prospective benign remailer users -- market research,
if you will. At this point, I think patching together various pieces of
existing remailer technology might greatly improve the attractiveness of the
c'punks style remailers.

 -L. Futplex McCarthy; PGP key by finger or server   "The objective is for us 
  to get those conversations whether they're by an alligator clip or ones and 
  zeroes. Wherever they are, whatever they are, I need them." -FBI Dir. Freeh

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

iQCVAwUBLx4/Tmf7YYibNzjpAQGcHgP+Nmo+c/Cfdul7HsZGOXR+cP+rmAVP1tRB
6PZcm/PDycd9HBTYqhraPsmwn7OGbqnWTeF0O5AitGSnwdG5o8+sSdUJ+KfJ1AcQ
tcyBFlvk9Rh/UIuzksUOeY935CVMA0nEmiXLoyJnnpiRoThctd/yILd8V+qiQ1pK
46j6Y7WeK5E=
=vUEc
- -----END PGP SIGNATURE-----
- ---
[This message has been signed by an auto-signing service.  A valid signature
means only that it has been received at the address corresponding to the
signature and forwarded.]

-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Gratis auto-signing service

iQBFAwUBLx5AZCoZzwIn1bdtAQE70wF/dta1dAuc7yWpkqkK2asa+9V/H3zN/cPI
vGyOSZMIvRCcAGLgSCUwZes+e3l7ETnZ
=2HOy
-----END PGP SIGNATURE-----





Thread