Re: [Asrg] An "ideal" false positive (TMGRS take 2)

Ian Eiloart <iane@sussex.ac.uk> Mon, 15 February 2010 10:17 UTC

Return-Path: <iane@sussex.ac.uk>
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 644BC3A7AF7 for <asrg@core3.amsl.com>; Mon, 15 Feb 2010 02:17:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.591
X-Spam-Level:
X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599]
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 ZU0GJ4YAZIHM for <asrg@core3.amsl.com>; Mon, 15 Feb 2010 02:16:58 -0800 (PST)
Received: from chip.uscs.susx.ac.uk (chip.uscs.susx.ac.uk [139.184.14.86]) by core3.amsl.com (Postfix) with ESMTP id 31E183A73A8 for <asrg@irtf.org>; Mon, 15 Feb 2010 02:16:55 -0800 (PST)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.135.133]:64604) by chip.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KXVOOL-000BXJ-9T for asrg@irtf.org; Mon, 15 Feb 2010 10:19:33 +0000
Date: Mon, 15 Feb 2010 10:18:12 +0000
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <69337EC16D97A928D8EC3442@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <20100214235728.GA19491@gsp.org>
References: <4B61D1BA.6060807@tana.it> <20100129135607.GB27203@gsp.org> <FBFC96085D5112AA96E23D0F@lewes.staff.uscs.susx.ac.uk> <20100214224735.GB11546@gsp.org> <60F30C47-57A0-4D27-ACAD-3501666F8229@blighty.com> <20100214235728.GA19491@gsp.org>
Originator-Info: login-token=Mulberry:01wBlkdCl60tkBhrjWLD8zjtfnJpGFziM/NYQ=; token_authority=support@its.sussex.ac.uk
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] An "ideal" false positive (TMGRS take 2)
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: Mon, 15 Feb 2010 10:17:00 -0000

--On 14 February 2010 18:57:28 -0500 Rich Kulawiec <rsk@gsp.org> wrote:

> On Sun, Feb 14, 2010 at 03:04:51PM -0800, Steve Atkins wrote:
>> You sent the email I'm replying to from an end user system, so there's
>> an innate paradox in that statement.
>
> Actually, no.  My email message is NOT an input to a security
> policy mechanism.
>
> ---Rsk

ASRG doesn't influence security policies?

Actually, all emails that are scanned by security mechanisms, are inputs to 
that mechanism. That's especially true if the mechanism is a learning 
mechanism, like a bayesian filter with auto-learning.

So, of course, are all emails to abuse@ or postmaster@. I get surprisingly 
few of each.

You're correct, of course, to caution that automatic reporting mechanisms 
will be subject to automated poisoning. We should, of course build 
mechanisms to defend against such attacks. I'd suggest the following:

1. Reports should be submitted over an authenticated channel. If the 
mechanism is SMTP, then it needs to be ESMTPSA, or via a verified feedback 
loop supported by DKIM signatures or SPF.

These measures don't make us immune to attack, but they do raise the bar.

2. Reports should be ignored if the subject of the report can't be 
verified. That is, if an email isn't on the system AS DELIVERED, you should 
not accept a report against that email.

3. An heirarchy of possible actions should be available in response to a 
set of reports, for example (a) unsubscribing the reporter from a mailing 
list; (b) blocking delivery to the reporter's mailbox; (c) blocking 
delivery to an entire mailstore; (d) reporting up the channel; (e) 
involving official regulators; (f) calling the police.

4. The action selected should be proportionate to the confidence that one 
has in the report. Confidence might be built by aggregating reports, by out 
of channel confirmation, or by admin eyeballing the offending message. 
Client machines that we administer (on campus) might be given more 
weighting than others.

NB: Some actions - (a) and (b) - are already available to black-hats, so 
automatic reporting mechanisms are not introducing a new risk. The 
mechanism, if well implemented, will make it easier for end users to block 
senders. Of course, the mechanism might be easier for black-hats to achieve 
those particular ends, but the system could guard against by using 
out-of-channel confirmations.

Other actions, (c), (d) and (f) would require different levels of 
investigation, but if I can make it easier for end users to report spam, 
then I can focus my investigations on incidents that affect more people 
rather than incidents that affect the loudest shouters or the people 
closest to me in the organisation.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/