Re: [Asrg] C/R Thoughts: Take 1

Yakov Shafranovich <> Tue, 13 May 2003 18:13 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id OAA23190 for <>; Tue, 13 May 2003 14:13:57 -0400 (EDT)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h4DHe4e15775 for; Tue, 13 May 2003 13:40:04 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h4DHe4B15772 for <>; Tue, 13 May 2003 13:40:04 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA23168; Tue, 13 May 2003 14:13:26 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19FeJ8-0006Xi-00; Tue, 13 May 2003 14:15:22 -0400
Received: from ([] by ietf-mx with esmtp (Exim 4.12) id 19FeJ7-0006Xf-00; Tue, 13 May 2003 14:15:21 -0400
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h4DHc3B15589; Tue, 13 May 2003 13:38:03 -0400
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h4DHbsB15572 for <>; Tue, 13 May 2003 13:37:54 -0400
Received: from ietf-mx ( []) by (8.9.1a/8.9.1a) with ESMTP id OAA23052 for <>; Tue, 13 May 2003 14:11:16 -0400 (EDT)
Received: from ietf-mx ([]) by ietf-mx with esmtp (Exim 4.12) id 19FeH2-0006WD-00 for; Tue, 13 May 2003 14:13:12 -0400
Received: from ([] helo= by ietf-mx with smtp (Exim 4.12) id 19FeH0-0006WA-00 for; Tue, 13 May 2003 14:13:11 -0400
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
From: Yakov Shafranovich <>
Subject: Re: [Asrg] C/R Thoughts: Take 1
In-Reply-To: <>
References: <>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-MimeHeaders-Plugin-Info: v2.03.00
X-GCMulti: 1
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
List-Archive: <>
Date: Tue, 13 May 2003 14:14:00 -0400

At 10:48 AM 5/13/2003 +0100, Jon Kyme wrote:

> > Per the request to put together ideas regarding C/R systems below is a
> > brief
> > inventory of some possible areas for a C/R standardization effort. I'm
> > not
> > advocating standardization of any of these...but rather identifying areas
> > that to some are obvious.  The MUST, SHALLs, and MAY's can follow later:
> >
>I wonder if there's a case for taking some position on the privacy issues
>involved in CR systems?
>Issues like this:
>Summary: Alleges SpamArrest harvests sender addresses

SpamArrest behavior is no different from a regular MTA operator or an ISP 
harvesting email addresses from all incoming and outgoing email. The only 
difference is since a C/R system must keep a list of verified email 
addresses, this makes it easier.

There are a few additional concerns. For example, the entire "verified" 
sender list as related to a specific email account is essentially a record 
of all people who sent emails to that user (its his address book 
essentially). What keeps the government from issuing subpoena against that 
information or some hacker breaking in and stealing it? I can easily hear 
an industry executive, lets say, being fired for 
flirting with competitors via some email system after Microsoft obtained 
the his verified senders list via a subpoena. Or a Chinese dissedent being 
executed after a government hacker steals his "verified" senders database. 
One other possible concern is the possibility of spammer stealing the 
entire "white list" database. The same concerns also apply to a block list 
that is kept by users. Even though it is possible to avoid SOME issues by 
using a system wide white-list of verified senders instead of user-specific 
white-lists, a block or blacklist must be specific to each user.

A possible way around might be is based on approaches outlined by Peter 
Wayner in his book "Translucent Databases" regarding storing private data. 
Instead of storing the actual email address in the database, we might store 
a one-way hash of it, lets say MD5. When emails are sent and received, the 
sender's email address is hashed and compared against the database. This 
way if anyone ends up wanting to use the database, it would be impossible 
since there will be no email addresses in it. Of course it would still be 
possible to check a specific email address against or use some form of a 
dictionary attack, but that is left to be discussed (using a salt value 
will not help since we are trying to avoid the possibility of someone who 
has access to the database from using the data).

And last, another concern that has been bothering me with C/R, is the 
possible death of anonymous remailers with such system. There are numerous 
one-way anonymous remailers in existence, many of which are 
mixmaster-based. They allow people to send anonymous email one way which 
may be very important for people in countries with oppressive regimes. With 
a C/R system these remailers would essentially be killed unless their 
administrator starts replying to each message individually. Spammers 
currently do not use anonymous remailers (at least I am not aware of it) 
since they have many other ways to send spam. Will they start using them, 
if other tactics will not work?


Yakov Shafranovich / <>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)

Asrg mailing list