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

Douglas Otis <> Tue, 23 June 2009 17:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9693328C399 for <>; Tue, 23 Jun 2009 10:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.411
X-Spam-Status: No, score=-6.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wiOAOrGHKEit for <>; Tue, 23 Jun 2009 10:37:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 91B3D28C349 for <>; Tue, 23 Jun 2009 10:37:52 -0700 (PDT)
Received: from [IPv6:::1] ( []) by (Postfix) with ESMTP id 77EBAA9443C for <>; Tue, 23 Jun 2009 17:38:00 +0000 (UTC)
Message-Id: <>
From: Douglas Otis <>
To: Anti-Spam Research Group - IRTF <>
In-Reply-To: <>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Tue, 23 Jun 2009 10:38:00 -0700
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.935.3)
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 17:37:53 -0000

On Jun 23, 2009, at 12:26 AM, Claudio Telmon wrote:
> 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.

Your strategy requires servicing a method that does not depend upon  
"pass-tokens" as a means to obtain them.  The task of collecting  
source specific tokens represents a fair amount of administrative  
effort for both senders and recipients that is likely to be  
problematic.  Not good.

Spitting the email-address onto separate headers is problematic.  In  
addition, what one MTA might understand may not apply to the subsequent.

Review how one might use <local-part>"+"<tags> :

Then imagine this acceptance criteria is combined valid DKIM  
respondent's messages.

As yet a better alternative, to thwart wasted and undesired exchanges,  
an exchange by reference offers an inherent means to authenticate  
sources without cryptography, and avoid undesired exchanges.