Re: [Asrg] Consensus Call - submission via posting (was Re: Iteration #3)

"Andrew Richards" <> Mon, 08 February 2010 17:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BB343A724D for <>; Mon, 8 Feb 2010 09:34:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.461
X-Spam-Status: No, score=-0.461 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FmU4DNrSUio7 for <>; Mon, 8 Feb 2010 09:34:40 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id E0F3A3A690D for <>; Mon, 8 Feb 2010 09:34:39 -0800 (PST)
Received: (qmail 8833 invoked by uid 0); 8 Feb 2010 17:35:38 -0000
Received: (ofmipd; 8 Feb 2010 17:35:16 -0000
Date: 8 Feb 2010 17:35:39 +0000
Message-Id: <>
From: "Andrew Richards" <>
To:, "Anti-Spam Research Group - IRTF" <>
User-Agent: KMail/1.12.2 (Linux/2.6.31-19-generic-pae; KDE/4.3.2; i686; ; )
References: <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] Consensus Call - submission via posting (was Re: Iteration #3)
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: Mon, 08 Feb 2010 17:34:41 -0000

On Saturday 06 February 2010 18:37:05 Dave CROCKER wrote:
> ...
>       Reports should be submitted using a mechanisms that:
>       [1]  Is the same as for submitting regular new mail, that is,
>  normal posting.  (Determination of the address to send to is a separate
>  issue.)
>       [2]  Is specific to the mechanism for retrieving the message for
>  which a report is being submitted.  (The details of such mechanisms is
>  a separate issue.)

I prefer [2].

What bugs me about [1] is that the whole message is being re-sent, but we 
seem to have established that the only thing a spam button will be saying 
is "This is spam/unwanted", so sending a report including the original 
email for basically a single bit of information seems excessive.

If the originating MTA(s) can be persuaded to hold onto [a copy of] the 
original message for at least a few days the reporting MUA merely needs to 
tell its upstream MTA which message(s) are spam/unwanted by referring to 
their UIDLs or Message-IDs. In addition there seems to be a greater chance 
of inadvertent disclosure of information with [1] whereas with [2] we know 
the MTA has already seen the message.

I don't see POP3 as a problem with [2] as suggested elsewhere: It could be 
extended to include reporting a UIDL (or Message-ID) as spam/unwanted; 
unaltered implementations would simply answer 'unimplemented', which I 
don't see as a problem: If people like having a spam button they can 
persuade their POP3 provider to implement the server-side part of it or 
vote with their feet.