Re: [Asrg] Adding a spam button to MUAs

Douglas Otis <dotis@mail-abuse.org> Fri, 05 February 2010 19:57 UTC

Return-Path: <dotis@mail-abuse.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 75BB428C1DC for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 11:57:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.3
X-Spam-Level:
X-Spam-Status: No, score=-6.3 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 RQfOiMqYTFEC for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 11:57:34 -0800 (PST)
Received: from harry.mail-abuse.org (harry.mail-abuse.org [168.61.5.27]) by core3.amsl.com (Postfix) with ESMTP id 97DDD28C142 for <asrg@irtf.org>; Fri, 5 Feb 2010 11:57:34 -0800 (PST)
Received: from sjc-office-nat-223.mail-abuse.org (gateway1.sjc.mail-abuse.org [168.61.5.81]) by harry.mail-abuse.org (Postfix) with ESMTP id DA87DA9444E for <asrg@irtf.org>; Fri, 5 Feb 2010 19:58:23 +0000 (UTC)
Message-ID: <4B6C785F.2080801@mail-abuse.org>
Date: Fri, 05 Feb 2010 11:58:23 -0800
From: Douglas Otis <dotis@mail-abuse.org>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: asrg@irtf.org
References: <20100205151049.85259.qmail@simone.iecc.com> <Pine.GSO.4.64.1002051011310.28969@nber6.nber.org> <4B6C653C.7060807@nortel.com> <F20D7208-2839-4B53-ADC9-471D11880F70@blighty.com> <4B6C6E56.5010802@nortel.com>
In-Reply-To: <4B6C6E56.5010802@nortel.com>
Content-Type: multipart/alternative; boundary="------------090601020703050903000809"
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 19:57:35 -0000

On 2/5/10 11:15 AM, Chris Lewis wrote:
> Steve Atkins wrote:
>
> Okay, but "arf" is so short ;-) And we have to get everybody else to 
> use it.
>
> "feedback" works too.
>
>> The only setting that the MUA is likely to have access to is the name 
>> of the IMAP or POP3 server. As IMAP and POP3 are not name-based, the 
>> entry there could easily be domain.com, mail.domain.com, 
>> imap.domain.com or pop.domain.com or smtp.domain.com or even 
>> www.domain.com.
>
> It has the default name used in inbound email, as well as (usually) an 
> email address used as a userid.  Per delivery server.  It may even be 
> able to see the rcpt to (or the MTA could "help".  Oh, never mind).
>
>> One option is to have the MUA "use some heuristic to find the 
>> 'domain' associated with that hostname", but past experience with SSP 
>> suggests that it makes people point and laugh at you and start 
>> mentioning things like imap.aardvark.us.com.
>>
>> Another would be to prepend "feedback." to the imap server name - so 
>> do an MX lookup for "feedback.imap.domain.com" to discover whether 
>> it's to enable the TiS button. That'll either need a DNS record added 
>> for every possible name for the IMAP server, or accept that it won't 
>> autoconfigure unless the recipient uses the name for the IMAP server 
>> you're expecting, either of which seems reasonable.
>>
>> (That doing MX lookups is not something that MUAs typically need code 
>> for, and that isn't supported by base API, is a minor issue but worth 
>> mentioning).
>
> Agreed.  I suspect many MUAs are completely incapable of doing direct 
> to MX, and don't do MX lookups.  See other suggestion, where I say 
> "Use normal submit mechanism".
It seems doubtful that any MUA will be able to properly determine 
origination's of a message without greater insight into their receiving 
administrative domain's architecture. Nor will Authentication-Results be 
bound to specific accounts once placed into a recipient's mailbox.  Any 
meaningful feedback, especially those related to source IP addresses, 
can only be emitted by the receiving administrative domain.  In 
addition, without some type of secured mechanism,  MUAs can not safely 
submit any end user feedback beyond their receiving administrative domain.

-Doug