Re: [Asrg] A Vouch By Feedback proposal

Ian Eiloart <iane@sussex.ac.uk> Thu, 09 July 2009 14:36 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 DBB373A6C41 for <asrg@core3.amsl.com>; Thu, 9 Jul 2009 07:36:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.454
X-Spam-Level:
X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 hFWd5ZovuoPG for <asrg@core3.amsl.com>; Thu, 9 Jul 2009 07:36:56 -0700 (PDT)
Received: from sivits.uscs.susx.ac.uk (sivits.uscs.susx.ac.uk [139.184.14.88]) by core3.amsl.com (Postfix) with ESMTP id 93C3D3A683A for <asrg@irtf.org>; Thu, 9 Jul 2009 07:36:55 -0700 (PDT)
Received: from lewes.staff.uscs.susx.ac.uk ([139.184.134.43]:49896) by sivits.uscs.susx.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.64) (envelope-from <iane@sussex.ac.uk>) id KMIRAB-000CHN-QG for asrg@irtf.org; Thu, 09 Jul 2009 15:37:24 +0100
Date: Thu, 09 Jul 2009 15:37:12 +0100
From: Ian Eiloart <iane@sussex.ac.uk>
Sender: iane@sussex.ac.uk
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Message-ID: <36B0EA72B852DDA692165C9D@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <20090709114851.GB26436@gsp.org>
References: <4A43618A.6000205@tana.it> <4A4F7DD0.4040404@billmail.scconsult.com> <4A51D35E.70306@tana.it> <4A52C36D.6040207@billmail.scconsult.com> <4A532344.5010509@tana.it> <4A53AC55.8030801@cybernothing.org> <4A5450B9.1050306@tana.it> <4A545D29.2010908@telmon.org> <200907081423.KAA06850@Sparkle.Rodents-Montreal.ORG> <DF5D26EA213E71501516EAB4@lewes.staff.uscs.susx.ac.uk> <20090709114851.GB26436@gsp.org>
Originator-Info: login-token=Mulberry:01nJi7kQX5KfbdBQ/zCL4PDS4EAhDc6/++EQM=; 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] A Vouch By Feedback proposal
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: Thu, 09 Jul 2009 14:36:57 -0000

--On 9 July 2009 07:48:51 -0400 Rich Kulawiec <rsk@gsp.org> wrote:

> On Thu, Jul 09, 2009 at 10:08:35AM +0100, Ian Eiloart wrote:
>> Knowing the real email address responsible lets us:
>>
>> 1. Contact the owner of a compromised account, and advise them to take
>> action.

Granted, all the following may be true, but we're still better off than the 
current situation where we have no clue who has sent most emails.

> If the account's compromised, then the new owner may not permit
> the former owner to see those communications.

Well, that's a sure way of getting the attention of the account owner.

> Or
>
> The former owner is unlikely to believe such reports or take any
> meaningful action.  For example, they may just abandon the compromised
> account, and open a new one...which will shortly be compromised in
> the same way.

Well, if people don't value their accounts, that may be true. In that 
event, you have to do something else.

> Or
>
> The former owner will classify these reports as spam/phishes.

So, blacklist them, or contact their provider.

> Relying on the same end-users who have created the problem to solve
> it is a 100% pre-failed strategy.

Who said we're relying on that. If I'd given you a list of ONE item, then 
you could level that accusation.

>> 2. Contact the account service provider.
>
> If you can manage to jump through the hoops they've put in place, sure.
> But automated reporting will misfire, manual reporting doesn't scale,
> and many account service providers simply don't care.  They don't
> have to: there are few, if any, meaningful consequences to apathy,
> and as long as they're profitable, few of them care about their
> responsibilities to the 'net.
>
>> 3. Blacklist the address.
>
> (I'm presuming you mean email address, not IP address.)
>
> Yes, but given that there is an inexhaustible supply of those, this will
> block the spam that's not coming any more from yesterday's compromised
> account and do nothing to block the spam that's coming tomorrow from
> the next compromised account.  This is also a 100% pre-failed strategy.

No, it's not. It makes life harder for the spammer. With reputation 
services, you can limit the amount of inbound email from addresses that 
haven't yet acquired good reputation.

> (Now, if you're talking about IP address, sure: we have very effective
> blacklist mechanisms for doing that.)

No, we don't. Witness the fact that 90% of email is still spam.

>> 4. Bounce unwanted email back to the sender.
>
> Unwanted mail should always be rejected, never bounced. Doing the
> latter not only generates useless traffic but is pretty likely
> to generate outscatter/backscatter, which is spam.  And even if
> it's correctly delivered, it will do absolutely no good -- see above.

Bounces only cause backscatter when you can't rely on the sender address 
being accurate. When the address is accurate - a compromised account, for 
example, there are no good arguments left against it. In fact, it'll 
encourage security of the account.


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