Re: [Asrg] A Vouch By Feedback proposal

Alessandro Vesely <vesely@tana.it> Wed, 08 July 2009 07:54 UTC

Return-Path: <vesely@tana.it>
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 440903A6E5F for <asrg@core3.amsl.com>; Wed, 8 Jul 2009 00:54:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.019
X-Spam-Level:
X-Spam-Status: No, score=-3.019 tagged_above=-999 required=5 tests=[AWL=1.700, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
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 TquQmQC2iPnf for <asrg@core3.amsl.com>; Wed, 8 Jul 2009 00:54:13 -0700 (PDT)
Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by core3.amsl.com (Postfix) with ESMTP id 6E5FB3A6E16 for <asrg@irtf.org>; Wed, 8 Jul 2009 00:53:53 -0700 (PDT)
Received: from mach-4.tana.it (mach-4.tana.it [194.243.254.189]) (AUTH: CRAM-MD5 ale@tana.it, TLS: TLS1.0, 256bits, RSA_AES_256_CBC_SHA1) by wmail.tana.it with esmtp; Wed, 08 Jul 2009 09:54:03 +0200 id 00000000005DC036.000000004A54509C.00006034
Message-ID: <4A5450B9.1050306@tana.it>
Date: Wed, 08 Jul 2009 09:54:33 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605)
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> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <4A532344.5010509@tana.it> <4A53AC55.8030801@cybernothing.org>
In-Reply-To: <4A53AC55.8030801@cybernothing.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] A Vouch By Feedback proposal
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, 08 Jul 2009 07:54:14 -0000

J.D. Falk wrote:
>> Vouch By Feedback could be a useful modification of the Vouch By 
>> Reference standard, if it didn't break its installed base.
>
> What installed base?

For one,

  MDaemon mail server software uses the advanced email authentication
  techniques of Vouch By Reference (VBR) and validates and signs
  messages using DKIM, DK, Sender-ID, and SPF.
  http://www.mdaemon.co.nz/Products/MDaemon

>> VBF adds a DNS record pointing from the vouched domain to the vouching 
>> server email address. It could be an RP RR type, where the address is 
>> meant to receive the message/feedback-report (AFR) complaints. Web 
>> is-spam buttons direct reports to the ESP, who should forward them to
>> any sender's vouching service. Clients who implement FBLs might send 
>> them to the relevant voucher directly.
>
> Variations of this theme have been discussed dozens of times, always 
> trying to piggyback on some other technology: SPF (which doesn't make 
> sense), DKIM (which almost makes sense), et cetera.

Basically, it should leverage SUBMIT. While DKIM may sign the From 
or Sender headers, it doesn't assure that the content of that field 
has been authenticated, IIRC. Actully, we need a weaker statement: 
that some of the signed headers has enough information for the 
originating server(s) to recover the authenticated identity of the 
submitter. That allows for anonymous sending.

> The problem, unfortunately, is that the use cases are unclear.  I'd 
> recommend starting by defining those cases -- not merely "I want to send 
> complaints about spam" or "I want to receive complaints so my mail 
> doesn't get blocked," but every possible permutation, end-to-end.

Improper use of TIS buttons was discussed some months ago. "I want 
to ban from sending whoever mailed me this" is the new case for them.

>> Vouchers, in turn, shall forward 
>> reports to the accountable originating ESP. The latter shall ban guilty 
>> users from sending for an amount of time proportional to the number of 
>> complaints. If the voucher sees complaints against users who should have 
>> been banned from sending, it shall suspend its vouching service for the 
>> relevant sender.
>
> Here you're getting out of the technology, and into dictating behavior. 
> I wouldn't be surprised if the agreements between message sender, 
> voucher, and message receiver end up looking something like what you 
> describe, but the technology should be agnostic and let those three 
> parties make any agreement they feel is appropriate for their individual 
> situations.

Agreed. In that respect, a voucher can mandate that behavior even 
using the existing VBR standard. Only the destination of complaints 
deserves further standardization. Standard AFR is on its way, isn't it?

Dictating behavior should be done by lawmakers, of course. However, 
they cannot write the standards, and may encounter difficulties even 
in identifying the items that populate cyberspace. It seems a 
somewhat tighter cooperation is required in order to sort out an 
effective anti-spam regulation.