Re: [Asrg] Adding a spam button to MUAs

Dave CROCKER <dhc@dcrocker.net> Sat, 06 February 2010 02:14 UTC

Return-Path: <dhc@dcrocker.net>
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 41E853A686C for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 18:14:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.5
X-Spam-Level:
X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156]
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 AIRVXE5TDw1j for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 18:14:11 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by core3.amsl.com (Postfix) with ESMTP id 562E23A69B0 for <asrg@irtf.org>; Fri, 5 Feb 2010 18:14:11 -0800 (PST)
Received: from [192.168.1.43] (adsl-68-122-70-87.dsl.pltn13.pacbell.net [68.122.70.87]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id o162EwrO005235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Feb 2010 18:15:03 -0800
Message-ID: <4B6CD09B.8010304@dcrocker.net>
Date: Fri, 05 Feb 2010 18:14:51 -0800
From: Dave CROCKER <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <20100206001350.16263.qmail@simone.iecc.com> <4B6CC08C.3040200@dcrocker.net> <201002060147.UAA14079@Sparkle.Rodents-Montreal.ORG>
In-Reply-To: <201002060147.UAA14079@Sparkle.Rodents-Montreal.ORG>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.92/10361/Fri Feb 5 08:44:47 2010 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Fri, 05 Feb 2010 18:15:04 -0800 (PST)
Cc: der Mouse <mouse@Rodents-Montreal.ORG>
Subject: Re: [Asrg] Adding a spam button to MUAs
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net, 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: Sat, 06 Feb 2010 02:14:13 -0000

On 2/5/2010 5:36 PM, der Mouse wrote:
>> One of the benefits of the suggestion to use the regular posting
>> mechanism is that it means that the MUA already knows how to post a
>> message.  It does not need the IP Address of a server to post two.
>
> However, it assumes that the path for outgoing mail is related to the
> path for incoming mail.

Well, before I sent my first post on this, I considered that question, and I 
could argue it either way.  If the requirement is a trusted channel from MUA to 
the reporting mailbox, then yeah, an asymmetry is a problem.  Otherwise, it's ok.


> If the two paths are not related, then sending something to the
> outgoing mail path won't have any effect on incoming mail handling.

Not quite.  The outgoing mail path is a posting agent, not a delivery agent. 
The /address/ specifies the delivery agent.  That's why this is an issue of 
trust, not routing.  Since the domain name or possibly full email address of the 
reporting destination is taken from the pickup host, there's no question that it 
points to the right place.  Hence, any valid posting server ought to be able to 
get the report there.  The problem is whether the reporting server /believes/ 
that the report is valid.

If there is a configuration asymmetry, then the report will come from outside 
the trust boundary.


> Also, everyone's talking about POP and IMAP as if they were all there
> is.  What about cases where the user's mailbox is accessed other ways?

I think the latest round of discussion has eliminated any interest in the 
message retrieval mechanism.

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net