Re: [Asrg] VPNs vs consent

"Claudio Telmon" <> Thu, 25 June 2009 14:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 356FE3A6AA0 for <>; Thu, 25 Jun 2009 07:59:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.151
X-Spam-Status: No, score=-0.151 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_33=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3YZyd5M64Db8 for <>; Thu, 25 Jun 2009 07:59:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D16313A68C8 for <>; Thu, 25 Jun 2009 07:59:53 -0700 (PDT)
Received: from ::ffff: ([::ffff:]) by via I-SMTP-5.6.0-560 id ::ffff:; Thu, 25 Jun 2009 16:58:10 +0200
From: "Claudio Telmon" <>
To: Anti-Spam Research Group - IRTF <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Thu, 25 Jun 2009 14:58:10 +0000
X-Mailer: NGI Webmail
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Subject: Re: [Asrg] VPNs vs consent
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To:, Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Jun 2009 14:59:55 -0000

> Da: Jose-Marcio Martins da Cruz <Jose-
> But also I have many **shared** identities. These identities correspond to email addresses 
>   (administrative or not) which resolve to many people. I can hardly see some kind of 
> management of *shared consent* for these addresses.

If you mean by shared consent that all receivers must agree on consent, I think it can' t be done in a usable way. However, shared addresses usually mean that the consent of one of the receivers suffices. Then, from a technical perspective, it can be partially done. Anybody can distribute tokens for the address, and upload them to the MTA database. Since it is the MTA database that matters for filtering, messages will be properly accepted/rejected. Should a token need to be invalidated, any of the receivers should be able to do it, even if the token is not in his7her address book, again because its the token on the MTA that matters. However, they will need to cooperate in order to understand e.g. whose system has been compromised, since only one will probably have associated the token to an address. 
The main problem is, probably only one of the receivers will have a proper token for answers, unless some shared repository is implemented. I didn't consider this issue.

Claudio Telmon