Re: [Asrg] Adding a spam button to MUAs

Daniel Feenberg <feenberg@nber.org> Fri, 05 February 2010 18:03 UTC

Return-Path: <feenberg@nber.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 ACD723A6C14 for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 10:03:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.442
X-Spam-Level:
X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, UNPARSEABLE_RELAY=0.001]
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 hM+EURjw4UMZ for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 10:03:21 -0800 (PST)
Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by core3.amsl.com (Postfix) with ESMTP id 642073A6C7D for <asrg@irtf.org>; Fri, 5 Feb 2010 10:03:21 -0800 (PST)
Received: from nber6.nber.org (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.3/8.13.8) with ESMTP id o15I49Fe098483 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 5 Feb 2010 13:04:10 -0500 (EST) (envelope-from feenberg@nber.org)
Received: from nber6.nber.org (localhost [127.0.0.1]) by nber6.nber.org (8.13.8+Sun/8.12.10) with ESMTP id o15I2st1022146; Fri, 5 Feb 2010 13:02:54 -0500 (EST)
Received: from localhost (Unknown UID 1079@localhost) by nber6.nber.org (8.13.8+Sun/8.13.8/Submit) with ESMTP id o15I2r6P022143; Fri, 5 Feb 2010 13:02:54 -0500 (EST)
X-Authentication-Warning: nber6.nber.org: Unknown UID 1079 owned process doing -bs
Date: Fri, 5 Feb 2010 13:02:53 -0500 (EST)
From: Daniel Feenberg <feenberg@nber.org>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <Pine.GSO.4.64.1002051247261.16421@nber6.nber.org>
Message-ID: <Pine.GSO.4.64.1002051302160.16421@nber6.nber.org>
References: <20100204232046.53178.qmail@simone.iecc.com> <4B6B5F78.3070607@nortel.com> <Pine.GSO.4.64.1002050659560.5587@nber6.nber.org> <190AE56F-D69E-437F-88D1-E1B373732F44@blighty.com> <Pine.GSO.4.64.1002051247261.16421@nber6.nber.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20100205 #3428449, check: 20100205 clean
Subject: Re: [Asrg] Adding a spam button to MUAs
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: Fri, 05 Feb 2010 18:03:22 -0000

On Fri, 5 Feb 2010, Daniel Feenberg wrote:

>
>
> On Fri, 5 Feb 2010, Steve Atkins wrote:
>
>> 
>> On Feb 5, 2010, at 4:09 AM, Daniel Feenberg wrote:
>> 
>>> 
>>> 
>>> On Thu, 4 Feb 2010, Chris Lewis wrote:
>>> 
>>>> John Levine wrote:
>>>>>> In any case it hardly matters because POP3 and IMAP are completely 
>>>>>> different
>>>>>> protocols with different constituencies. You'd never have a standards 
>>>>>> effort
>>>>>> that lumps them together in a million years, and even if you did you'd 
>>>>>> do
>>>>>> nothing more than needlessly confuse the programmers of their 
>>>>>> respective
>>>>>> code bases.
>>>>> Actually, we've seen a reasonable suggestion a few messages back that
>>>>> would work equally well with POP and IMAP: extract a reporting address
>>>>> from the message and send it an ARF report.  It has the admirable
>>>>> characteristic of being completely agnostic about how the mail is
>>>>> delivered, since there are plenty of delivery techniques other than
>>>>> POP and IMAP, such as WebDAV, uucp (still handy for intermittent
>>>>> connections), fetchmail, and just reading the local mailstore.
>>>> 
>>>> If we want to sidestep the issue of how to deal with senders wanting 
>>>> their FBLs, the very simplest method of all is to have the TiS button 
>>>> send an ARF to a specific address, and let that address figure out 
>>>> everything else.
>>>> 
>>>> I could live with that even in my odd-ball architecture (which probably 
>>>> resembles other very large infrastructures).  I already do that (without 
>>>> the ARF format), and the recipient address has to be manually configured 
>>>> in the MUA.
>>>> 
>>>> I'd only add that I'd prefer _not_ to have to have the user configure the 
>>>> MUA where to send the ARFs to.  The receiving mail server inserts it. 
>>>> Meaning that the MUA has to be able to determine it's valid.
>>>> 
>>> 
>>> I haven't been following this thread very closely, but why not just 
>>> establish a standard role account on the MUAs designated POP or IMAP 
>>> server? Such as arf@pop.example.com? It effectively "preconfigures" the 
>>> MUA since "arf" is standard and "example.com" is already known to the MUA. 
>>> The less configuration the better, I think.
>> 
>> POP and IMAP servers don't receive email. If you're planning on mandating 
>> that all POP or IMAP servers listen on port 587, that's a fairly big 
>> requirement.
>
> Mail to arf@pop.eample.com may go to the host named example.com, or it may go

Sorry, I meant "the host named pop.example.com".

Daniel Feenberg