Re: [Asrg] Adding a spam button to MUAs

Daniel Feenberg <> Fri, 05 February 2010 18:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 03E563A6C14 for <>; Fri, 5 Feb 2010 10:00:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.442
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b3wv8UWQsDeL for <>; Fri, 5 Feb 2010 10:00:14 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E4A933A6B28 for <>; Fri, 5 Feb 2010 10:00:13 -0800 (PST)
Received: from ( []) by (8.14.3/8.13.8) with ESMTP id o15I11lL097642 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 5 Feb 2010 13:01:02 -0500 (EST) (envelope-from
Received: from (localhost []) by (8.13.8+Sun/8.12.10) with ESMTP id o15Hxk7L021498; Fri, 5 Feb 2010 12:59:46 -0500 (EST)
Received: from localhost (Unknown UID 1079@localhost) by (8.13.8+Sun/8.13.8/Submit) with ESMTP id o15Hxjvx021495; Fri, 5 Feb 2010 12:59:46 -0500 (EST)
X-Authentication-Warning: Unknown UID 1079 owned process doing -bs
Date: Fri, 5 Feb 2010 12:59:44 -0500 (EST)
From: Daniel Feenberg <>
To: Anti-Spam Research Group - IRTF <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <>
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-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Anti-Spam Research Group - IRTF <>
List-Id: Anti-Spam Research Group - IRTF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 05 Feb 2010 18:00:15 -0000

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 It effectively "preconfigures" the MUA since "arf" is standard and "" 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 may go to the host named, or it may 
go to a host of any other name given in the MX statement for 
There is no requirement that host an MTA at all. Am I 
missing something or are you teasing me?

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 must have an MTA somewhere that can accept mail for 
arf@[pop|imap} 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 

The desire to eliminate all naming conventions strikes me as pointless - 
they are widespread and quite helpful in my experience. From localhost to, 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
> _______________________________________________
> Asrg mailing list