Re: [Asrg] VPNs vs consent

Claudio Telmon <> Wed, 01 July 2009 17:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B78E3A69C5 for <>; Wed, 1 Jul 2009 10:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.511
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AShhCZmBUvaK for <>; Wed, 1 Jul 2009 10:44:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D20573A67F6 for <>; Wed, 1 Jul 2009 10:44:12 -0700 (PDT)
Received: from ([::ffff:]) by via I-SMTP-5.6.0-560 id ::ffff:; Wed, 01 Jul 2009 18:23:59 +0200
Message-ID: <>
Date: Wed, 01 Jul 2009 18:23:59 +0200
From: Claudio Telmon <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20090318 Lightning/0.8 Thunderbird/ Mnenhy/
MIME-Version: 1.0
To:, Anti-Spam Research Group - IRTF <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
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-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: 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