Re: [Asrg] VPNs vs consent

Claudio Telmon <claudio@telmon.org> Wed, 01 July 2009 17:44 UTC

Return-Path: <claudio@telmon.org>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B78E3A69C5 for <asrg@core3.amsl.com>; Wed, 1 Jul 2009 10:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.511
X-Spam-Level:
X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AShhCZmBUvaK for <asrg@core3.amsl.com>; Wed, 1 Jul 2009 10:44:13 -0700 (PDT)
Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id D20573A67F6 for <asrg@irtf.org>; Wed, 1 Jul 2009 10:44:12 -0700 (PDT)
Received: from 88-149-250-62.dynamic.ngi.it ([::ffff:88.149.250.62]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.62+5A2eTQ6sXla; Wed, 01 Jul 2009 18:23:59 +0200
Message-ID: <4A4B8D9F.9000000@telmon.org>
Date: Wed, 01 Jul 2009 18:23:59 +0200
From: Claudio Telmon <claudio@telmon.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: Jose-Marcio.Martins@mines-paristech.fr, Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <20090623213728.1825.qmail@simone.iecc.com> <4A41D773.50508@telmon.org> <4A41E506.2010106@mines-paristech.fr> <20090624160052.B5DC62428A@panix5.panix.com> <4A426B9D.7090901@mines-paristech.fr> <4A43618A.6000205@tana.it> <4A437393.3060105@mines-paristech.fr> <212.234.174.167.1726486840.1245941890@webmail.inet.it> <4A439639.9090106@mines-paristech.fr> <4A4A879D.80008@telmon.org> <4A4B76C8.3080602@mines-paristech.fr>
In-Reply-To: <4A4B76C8.3080602@mines-paristech.fr>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] VPNs vs consent
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2009 17:44:14 -0000

Jose-Marcio Martins da Cruz wrote:
> Claudio Telmon wrote:
>> Jose-Marcio Martins da Cruz wrote:
> 
>>
>> I need some more clarification on this, maybe it's just me not knowing
>> enough about MTAs internals. As the border MTA receives a RCPT TO for
>> either of these addresses, it should be able to know if it is a valid
>> address. In my (very limited) experience, this means that each of these
>> addresses mut be defined as a valid address, the MTA doesn't have rules
>> to decide that since jose-marcio.martins_da_cruz is a valid address,
>> jose-marcio.martins must be valid too. So, if each of these addresses is
>> individually defined in some list/database accessed by the MTA, then
>> with the same rules, the related token database should be accessed too.
>> Should an "automatic aliasing" rule exist, then the same rule could
>> exist for the token database. Also, if "somewhere" an alias is defined
>> for an address, then the correspondent database could just be a pointer
>> to the database of the "main" address. This could even implement "chains
>> of aliases" as "chains of pointers to token databases".
> 
> The border MTA surely knows a list of valid addresses, but it may not
> know, all the time, that all this addresses resolve to the same login -
> sometimes some addresses are resolved in the final internal servers.
> 
> But well, you can find some organisations with this kind of thing
> nowadays. Don't know if this shall be taken into account to design
> future systems.
> 
>> I think this is feasible with an appropriate address book manager.
>> Anyway, the load is for the MUA, not for the MTA, so the number of users
>> shouldn't matter.
> 
> Hmmm. If the border MTA accept and the MUA reject by lack of consent, a
> bounce is generated.

Surely, but that's not what I mean. Once the address book manager knows
that it must handle a list of (receiver) addresses aliases that will
share the same tokens, it will push those tokens to the MTA, so that the
MTA will have a valid list of tokens for the various aliases and reject
messages as required.

-- 

Claudio Telmon
claudio@telmon.org
http://www.telmon.org