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

Ian Eiloart <> Tue, 09 February 2010 12:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D70373A71AE for <>; Tue, 9 Feb 2010 04:54:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kZ9eG3VtXw6k for <>; Tue, 9 Feb 2010 04:54:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7A0FD3A7386 for <>; Tue, 9 Feb 2010 04:54:29 -0800 (PST)
Received: from ([]:53317) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <>) id KXKRX7-000IGA-48; Tue, 09 Feb 2010 12:55:55 +0000
Date: Tue, 09 Feb 2010 12:55:19 +0000
From: Ian Eiloart <>
To: Anti-Spam Research Group - IRTF <>, Andrew Richards <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <>
Originator-Info: login-token=Mulberry:013TMFDkaUc3MeoFlwSVlQqHiBQ6smaEBZUp4=;
X-Mailer: Mulberry/4.0.8 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Sussex: true
X-Sussex-transport: remote_smtp
Subject: Re: [Asrg] who has the message (was Re: 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: Tue, 09 Feb 2010 12:54:30 -0000

--On 8 February 2010 09:39:27 -0800 Dave CROCKER <> wrote:

> On 2/8/2010 9:35 AM, Andrew Richards wrote:
>> 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.
> The alternative requires that a copy of the message still be at the
> server. That works in only some MUA-based models.  Often/typically, the
> entire message is downloaded to the MUA's site and the server no longer
> has a copy.  Hence, it's too late to enjoy merely passing a citation back
> to the server.

Both IMAP and POP are capable of operating in a suitable manner. If the 
message isn't on the mailstore, then the operator has no way to check that 
the report really is about a message that they delivered.

>> 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
> The challenge is the "few days".  It means that the mechanism fails after
> a few days.  Is that acceptable?  Why?

Actually, that's completely implementation dependant. When a server gets a 
message "x is junk", it can either act immediately or it can queue an 

For IMAP, it should make a safe working copy, then apply a flag or 
annotation acknowledging the report. At this point, the user/client knows 
its safe to delete the message, though they may prefer to keep it for later 
reference. Alternatively, the flag could be used to change the behaviour of 
the DELETE or EXPUNGE commands. For example, there's a patch for Cyrus IMAP 
which implements delayed expunge - messages are removed from the mailbox 
index, but aren't deleted from the file system until they've had a chance 
to be backed up (eg, after 24 hours). It's not hard to imagine a similar 
mechanism that handles messages with junk flags.

For POP, you'd probably make a safe copy then delete the original message. 
If the user wants a copy, they can download it before making the report.

In neither case is there a requirement for the message to continue to be 
visible to the recipient, or use any of their quota.

> d/

Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see