Re: [Asrg] VPNs vs consent

Claudio Telmon <claudio@telmon.org> Thu, 02 July 2009 10:57 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 C508A3A6D38 for <asrg@core3.amsl.com>; Thu, 2 Jul 2009 03:57:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.52
X-Spam-Level:
X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=0.199, 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 5lb5p+Kesohh for <asrg@core3.amsl.com>; Thu, 2 Jul 2009 03:57:17 -0700 (PDT)
Received: from slim-2a.inet.it (slim-2a.inet.it [213.92.5.122]) by core3.amsl.com (Postfix) with ESMTP id EDB403A6985 for <asrg@irtf.org>; Thu, 2 Jul 2009 03:56:53 -0700 (PDT)
Received: from 88-149-250-62.dynamic.ngi.it ([::ffff:88.149.250.62]) by slim-2a.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.250.62+voFiPUXqq8d; Thu, 02 Jul 2009 12:57:15 +0200
Message-ID: <4A4C928A.1030904@telmon.org>
Date: Thu, 02 Jul 2009 12:57:14 +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: 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> <4A4B8D9F.9000000@telmon.org> <4A4B8FA9.3080905@mines-paristech.fr> <4A4B9345.8060705@telmon.org> <4A4C901D.3010200@mines-paristech.fr>
In-Reply-To: <4A4C901D.3010200@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: Thu, 02 Jul 2009 10:57:17 -0000

Jose-Marcio Martins da Cruz wrote:

> I have the feeling that this is part of a larger problem which is how to
> inform a border SMTP gateway about caracteristics of final addresses in
> internal mail servers.
> 
> One example we were talking about is just what are the valid internal
> addresses which, with your needs for the consent framework, is a sub
> problem of the larger one.
> 
> For the problem of checking the validity of internal addresses (e.g.),
> there are many solutions, but none of them is perfect.
> 
> Maybe this problem could be taken out of your proposal and handled as a
> global one.

I think you're right, and I actually highlighted this as a "plus" of the
proposal. The ability (in my case for the user) to push some simple
information to the border MTA (in my case, acceptable tokens) so that
messages can be dropped/rejected/accepted earlier, can be very useful
IMHO. In this specific case, messages can be rejected, that otherwise
the final receiver could otherwise only delete from its mailbox.
This should be also what Danny Angus meant in his first message in the
thread.

-- 

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