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

"Andrew Richards" <> Mon, 08 February 2010 20:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11DE73A7283 for <>; Mon, 8 Feb 2010 12:55:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.508
X-Spam-Status: No, score=-0.508 tagged_above=-999 required=5 tests=[AWL=0.031, 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 j-dxNsRngirO for <>; Mon, 8 Feb 2010 12:55:22 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id B75EA3A7255 for <>; Mon, 8 Feb 2010 12:55:21 -0800 (PST)
Received: (qmail 16834 invoked by uid 0); 8 Feb 2010 20:56:21 -0000
Received: (ofmipd; 8 Feb 2010 20:55:59 -0000
Date: 8 Feb 2010 20:56:23 +0000
Message-Id: <>
From: "Andrew Richards" <>
To: "Dave CROCKER" <>, "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] 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: Mon, 08 Feb 2010 20:55:23 -0000

On Monday 08 February 2010 19:18:30 Dave CROCKER wrote:
> On 2/8/2010 11:11 AM, Andrew Richards wrote:
> >> 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.
> >
> > I wish to imply that it would become a requirement for the server to
> > hold a copy if it wishes to implement this functionality
> That creates a massive barrier to adoption.  Huge implementation
>  overhead.

However TiS is implemented will require implementation work on the server-
side, so I'm not sure that [2] is so different from [1] in this respect.

> >> The challenge is the "few days".  It means that the mechanism fails
> >>   after a few days.  Is that acceptable?  Why?
> >
> > Reports of spam are most useful the fresher they are
> while no doubt true, it is not a clear to me that it's appropriate to
>  make it impossible to submit older reports.

MTA admins may choose how long to retain copies of messages, perhaps 
subject to a suggested minimum. So yes it would be impossible in some 
cases, but is that a problem if 95% of spam can be successfully reported 
(95% of reports being fresh enough for the message still to be held by the 
MTA)? Losing 5% of reports is perhaps worthwhile if this approach has other 
advantages, I would suggest a greater elegance (no squandered bandwidth, 
see separate post) and a safer security model re. information leakage. I am 
of course pulling my 95%/5% figures out of thin air. The MTA admin has an 
incentive to retain copies for a reasonably long time to maximise his/her 
anti-spam capabilities.

Alternatively to address that 5%, and perhaps relevant to other TiS 
approaches, if MTAs had the option of retaining messages for TiS purposes, 
if the report-submission was interactive (such as Steve Atkins option [3] 
'for completeness' posted on 6th Feb which I've pasted below) the MUA could 
query whether the upstream system already has a copy of the message. For 
example I would note that IMAP servers have a good chance of having the 
message. The MUA can then report TiS messages where a copy has been kept 
without inadvertent information leakage, and might have a user setting 
whether to send a full report where no copy has been kept.


Steve's option [3]:

 [3] Is the same for every mechanism for retrieving the message,
      but not based on submitting email.

... for example, reporting via an HTTP post, or an SMTP extension,
or XMPP, or telepathy, regardless of whether the original message
was read via POP, IMAP, spool access, SMTP ETRN, SMS or an
XML-RPC call.