Re: [Asrg] Adding a spam button to MUAs

Steve Atkins <steve@blighty.com> Fri, 05 February 2010 18:38 UTC

Return-Path: <steve@blighty.com>
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 DE0923A6DBE for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 10:38:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.443
X-Spam-Level:
X-Spam-Status: No, score=-6.443 tagged_above=-999 required=5 tests=[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 4P5pmLm7COXf for <asrg@core3.amsl.com>; Fri, 5 Feb 2010 10:38:02 -0800 (PST)
Received: from m.wordtothewise.com (fruitbat.wordtothewise.com [208.187.80.135]) by core3.amsl.com (Postfix) with ESMTP id 0C4ED28C15E for <asrg@irtf.org>; Fri, 5 Feb 2010 10:38:02 -0800 (PST)
Received: from platterhard.wordtothewise.com (184.wordtothewise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 5253F4F8209 for <asrg@irtf.org>; Fri, 5 Feb 2010 10:38:53 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1077)
From: Steve Atkins <steve@blighty.com>
In-Reply-To: <Pine.GSO.4.64.1002051247261.16421@nber6.nber.org>
Date: Fri, 05 Feb 2010 10:38:52 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <36CBE9CB-5B4E-4389-B7E6-B0D565D956BB@blighty.com>
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>
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
X-Mailer: Apple Mail (2.1077)
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:38:03 -0000

On Feb 5, 2010, at 9:59 AM, Daniel Feenberg wrote:

> 
> 
> On Fri, 5 Feb 2010, Steve Atkins wrote:
> 
>> 
>> On Feb 5, 2010, at 4:09 AM, Daniel Feenberg wrote:
>>> 
>>> 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 to a host of any other name given in the MX statement for example.com. There is no requirement that pop.example.com host an MTA at all. Am I missing something or are you teasing me?

I was asking for clarification - if you read the next sentence, you'll see me doing that, even mentioning MX records - as you suggested that the role account be on the designated POP or IMAP server.

> 
> Furthermore, there can be no expectation that all email domains will support this protocol - so my expectation is that all email domains that wish to support this protocol for users receiving mail from pop or imap@example.com must have an MTA somewhere that can accept mail for arf@[pop|imap}.example.com. If there is a domain somewhere that wishes to support the protocol, but does not wish to use the naming convention, then they would be left out in the cold. I don't see that as a very big concern.

What if they wish to use the naming convention, but do not wish to use the protocol?

A not unheard of setup for a vanity domain is for all traffic to be served at "example.com" - web, email, everything.

So there's a DNS record "example.com MX 10 example.com", and a POP3 or IMAP server listening on example.com[1].

If the MUA uses the existence of an MX record for the hostname of the POP or IMAP server to decide whether to enable the "TiS" button (an obvious thing to do) then in that case it will be enabled.

If the user hits the "TiS" button, then it'll either cause a rejection, a deferred bounce or (if it's a catch-all domain) deliver the report back to the users inbox.

This violates the UI principle of least surprise, and is part of what I was talking about when I said "namespace pollution".

[1] It may also be listening on imap.example.com, mail.example.com, pop3.example.com and www.example.com, all at the same IP address. As IMAP and POP3 are not name-based protocols, all of these will work. So the end user could put any of these in to their MUA as their IMAP server, and mail will work just fine. Automatic discovery may find one of these and not another, depending on probe order. So if you're relying on the MUAs IMAP server setting as a key, it's not that simple.

> 
> The desire to eliminate all naming conventions strikes me as pointless - they are widespread and quite helpful in my experience. From localhost to 127.0.0.1, to postmaster and abuse what is the downside? Someone may wish to use "localhost" as a hostname? Did they miss the IETF meeting? Then they are out of luck. In any case, at somepoint there has to be a convention, all the protocol can do is add levels of indirection.
> 
> Daniel Feenberg
> 
>> 
>> Or are you suggesting something MXish or SRVish (which isn't implausible, though it's got the usual namespace pollution problems to dodge)?
>> 

Cheers,
  Steve