Re: [Asrg] request for review for a non FUSSP proposal

Claudio Telmon <> Tue, 23 June 2009 07:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 024983A63EC for <>; Tue, 23 Jun 2009 00:26:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.559
X-Spam-Status: No, score=-0.559 tagged_above=-999 required=5 tests=[AWL=0.160, 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 A2zwe7PzV7xM for <>; Tue, 23 Jun 2009 00:26:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3D4F43A6922 for <>; Tue, 23 Jun 2009 00:26:29 -0700 (PDT)
Received: from ([::ffff:]) by via I-SMTP-5.6.0-560 id ::ffff:; Tue, 23 Jun 2009 09:26:43 +0200
Message-ID: <>
Date: Tue, 23 Jun 2009 09:26:42 +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] request for review for a non FUSSP proposal
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: Tue, 23 Jun 2009 07:26:34 -0000

Douglas Otis wrote:
> Claudio,
> An alternative for tokens would be to offer message links.  Rather than
> sending messages, a reference to a message is exchanged instead.  The
> link format associated with the message should allow recipients a means
> to know who issued the message.  This would eliminate a need to track
> delivery status.  Unless the recipient follows the link, the message
> would not be considered delivered.  Receiving MTAs could offer a menu to
> allow recipients a means to automatically fetch messages from specific
> links as a method to save time when online, especially when dealing with
> slow uplinks.  This mode of operation might be globally used to ensure
> compatibility with existing MUAs or domains that don't support this mode
> of exchange.  Importantly, this method would not represent a major
> change in how email is currently handled, however authentication would
> become inherent with the transfer.

This seems to mix Internet mail 2000 with the consent framework. You
suggest to put the token in the link, so that the receiver's
notification agent can perform the same selection as the receiver's MTA
in my proposal. While this would be possible, goals are different and
implementations seem to be independent. It should work, from a technical
perspective. However, Internet mail 2000 already has its own deployment
issues, so mixing the two things seems to increase the deployment
difficulties, which are already high.


Claudio Telmon