RE: [Asrg] Consent Proposal

"Howard Roth" <hroth@tngi.com> Tue, 01 July 2003 17:48 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08844 for <asrg-archive@odin.ietf.org>; Tue, 1 Jul 2003 13:48:49 -0400 (EDT)
Received: (from exim@localhost) by www1.ietf.org (8.11.6/8.11.6) id h5RINQp21852 for asrg-archive@odin.ietf.org; Fri, 27 Jun 2003 14:23:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxsV-0005fW-2x for asrg-web-archive@optimus.ietf.org; Fri, 27 Jun 2003 14:23:19 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09391; Fri, 27 Jun 2003 14:22:57 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vxs8-00055g-00; Fri, 27 Jun 2003 14:22:56 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 19VxrV-00054B-00; Fri, 27 Jun 2003 14:22:17 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VxrX-000553-1N; Fri, 27 Jun 2003 14:22:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19VuSL-0002P9-7h for asrg@optimus.ietf.org; Fri, 27 Jun 2003 10:44:05 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26102 for <asrg@ietf.org>; Fri, 27 Jun 2003 08:44:28 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19Vsab-0002Ji-00 for asrg@ietf.org; Fri, 27 Jun 2003 08:44:29 -0400
Received: from h-d1d1248a.digitalpod.com ([209.209.36.138] helo=yaweno.com) by ietf-mx with esmtp (Exim 4.12) id 19VsaQ-0002JQ-00 for asrg@ietf.org; Fri, 27 Jun 2003 08:44:18 -0400
Received: from apocalypse [206.170.148.241] by yaweno.com (SMTPD32-7.03) id AEF3FB60074; Fri, 27 Jun 2003 00:14:59 -0700
Reply-To: hroth@tngi.com
From: Howard Roth <hroth@tngi.com>
To: asrg@ietf.org
Subject: RE: [Asrg] Consent Proposal
Message-ID: <NDBBKODHMKMGNDLPBHKKAEJCEFAA.hroth@tngi.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <5.2.0.9.2.20030626171332.00bd13e0@pop.pocketmail.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 7bit
Sender: asrg-admin@ietf.org
Errors-To: asrg-admin@ietf.org
X-BeenThere: asrg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=unsubscribe>
List-Id: Anti-Spam Research Group - IRTF <asrg.ietf.org>
List-Post: <mailto:asrg@ietf.org>
List-Help: <mailto:asrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/asrg>, <mailto:asrg-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/pipermail/asrg/>
Date: Fri, 27 Jun 2003 00:18:25 -0700
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Here's an idea about validating a message before I can ever see it.  This
can be considered a consent-based concept, as it can be a parameter at the
ISP end for each mail user. It adds quite a bit of overhead to the mail
server as it requires two additional messages for each one sent.  I see it
being part of the MTA process.  I send a message to someone.  The MTA
replies to the message with a "proof of sender request, " basically a
specially formatted email message that goes back to the server that sent it
based on the return address.  The sender's MTA responds with a "confirmation
request"  if it did send the message and the message is now available for
download based on moving it from the pending directory to a user directory.
If there is no response within a certain period the message is discarded.
It's a similar concept that I use when I get a telemarketer who I may want
to pursue what they are selling.  I ask for their phone number and call then
back. Granted I don't do this very often as I usually tell them to take me
off their call list and hang up.  If this has been mentioned I apologize as
the volume of messages is quite large on this list.

In terms of Yakovs' consent based system:  I like the idea of an ISP form
that allows me to check boxes to deny HTML or non-signed messages.  And
probably enter a few basic filters like deny any message that mentions
Viagra.  Also you could determine what lists to use to deny or accept
messages.  I prefer not to filter messages on my machine, but I don't see
the typical ISP processing all these rules and filters without a substantial
increase in cost of doing business. So I think having something at both ends
makes sense in the short term.  The long term it should be an issue for the
MTA to manage based on some parameters that the user or ISP set.

I like the idea of a white list that is supported by some industry entity
like the DMA.  But I also like the way I can put my phone number in the
DMA's database and all those marketers who subscribe to their service won't
call me.

The bottom line is that consent should be easy for the general user to deal
with and understand.

Howard Roth

-----Original Message-----
From: asrg-admin@ietf.org [mailto:asrg-admin@ietf.org]On Behalf Of Yakov
Shafranovich
Sent: Thursday, June 26, 2003 2:23 PM
To: asrg@ietf.org
Subject: [Asrg] Consent Proposal

I would like to provide a generic proposal for consent-based system as per
charter:

1. Users and/or ISP define rules and filters to filter incoming email.
Rules/filters are decided by end users and ISPs, and are not mandated.
Every user/ISP can define its own policies ranging from banning all email
not digitally signed to blocking HTML.
2. For each email user, the MUA or the ISP maintains a whitelist of trusted
senders, blacklist of blocked senders and a graylist of unknown senders.
Whitelisted senders go the inbox, graylisted senders go to the bulk folder,
and blacklisted senders are either in the spam folder or erased.
3. Whitelists are not only a list of email addresses of trusted senders,
but to avoid sender spoofing also have additional features such as digital
signatures, certificates, passwords, tokens, etc.
4. Additional automatic whitelist rules are defined as such email from
trusted senders (e.g. Habeas) is automatically goes to the inbox unless
blacklisted, etc. C/R systems are also integrated and upon receiving a
positive response automatically whitelist the sender.
5. Additional automatic blacklist rules are defined such as email coming
from known open relays is blocked.
6. Whitelists, graylists and blacklists are stored hashed or encrypted to
protect privacy.

Any thoughts?

Yakov


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg


_______________________________________________
Asrg mailing list
Asrg@ietf.org
https://www1.ietf.org/mailman/listinfo/asrg