Re: [Asrg] Adding a spam button to MUAs

"BOBOTEK, ALEX (ATTCINW)" <AB3778@att.com> Wed, 09 December 2009 07:30 UTC

Return-Path: <AB3778@att.com>
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 C38373A6ADE for <asrg@core3.amsl.com>; Tue, 8 Dec 2009 23:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.445
X-Spam-Level:
X-Spam-Status: No, score=-106.445 tagged_above=-999 required=5 tests=[AWL=-0.002, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100]
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 m3k2s9Za++Mf for <asrg@core3.amsl.com>; Tue, 8 Dec 2009 23:30:40 -0800 (PST)
Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id DA6933A69DB for <asrg@irtf.org>; Tue, 8 Dec 2009 23:30:39 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: AB3778@att.com
X-Msg-Ref: server-15.tower-129.messagelabs.com!1260343828!19742384!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [144.160.112.25]
Received: (qmail 18722 invoked from network); 9 Dec 2009 07:30:29 -0000
Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-15.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Dec 2009 07:30:29 -0000
Received: from enaf.dadc.sbc.com (localhost.localdomain [127.0.0.1]) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id nB97USPp024306 for <asrg@irtf.org>; Wed, 9 Dec 2009 01:30:28 -0600
Received: from td03xsmtp005.US.Cingular.Net (td03xspare20-new.us.cingular.net [135.179.64.44] (may be forged)) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id nB97UMfM024235 for <asrg@irtf.org>; Wed, 9 Dec 2009 01:30:22 -0600
Received: from BD01XSMTP003.US.Cingular.Net ([135.163.18.44]) by td03xsmtp005.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 01:30:22 -0600
Received: from BD01MSXMB015.US.Cingular.Net ([135.214.26.11]) by BD01XSMTP003.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Dec 2009 23:30:21 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 8 Dec 2009 23:32:19 -0800
Message-ID: <BF533A28DBE487489EAB3411C5412CBE0F421DF9@BD01MSXMB015.US.Cingular.Net>
In-Reply-To: <AD273AC6AF921143B646204CB8157C3409AF782EDD@BD01MSXMB015.US.Cingular.Net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: RE:[Asrg] Adding a spam button to MUAs
Thread-Index: Acp4nnlOdecDym0rRc2EwB5KYAJnPwAAyAew
References: <AD273AC6AF921143B646204CB8157C3409AF782EDD@BD01MSXMB015.US.Cingular.Net>
From: "BOBOTEK, ALEX (ATTCINW)" <AB3778@att.com>
To: <asrg@irtf.org>
X-OriginalArrivalTime: 09 Dec 2009 07:30:21.0381 (UTC) FILETIME=[76ED4750:01CA78A1]
Subject: Re: [Asrg] Adding a spam button to MUAs
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: Wed, 09 Dec 2009 07:30:41 -0000

One approach to identifying a destination for spam reports is to inspect
the RECEIVED headers of the suspect message and fire the report back to
the last MTA (or perhaps a DNS txt 'spamReport' record assigned to that
MTA).  This assumes that it knows what to do with it, possibly leading
to a cascading effect.  IMHO, this is a good way of getting the info
back to systems/parties that we expect to block it.  

One potential hazard is the reports being cascaded back to the spammer,
or otherwise exposing the reporters to the extent that list washing
would be possible.  Another conceivable undesired effect is a single
spam message generating a large  number of abuse reports (if an MTA fans
out reports to multiple destinations) causing capacity issues.
DOS-by-spam-report isn't what we're after.

Not sure how practical this would be.  It would be a challenge to get a
critical mass to adopt.

Thoughts?

Regards,

Alex



Alex Bobotek
Principal Architect, Messaging and Messaging Abuse
AT&T Labs
alex.bobotek@att.com
425 580-6279
 
------------------------------------------------------------------------
-----------
 
This email and any files transmitted with it are AT&T property, are
confidential, and are intended solely for the use of the individual or
entity to whom this email is addressed.  If you are not one of the named
recipient(s) or otherwise have reason to believe that you have received
this message in error, please notify the sender and delete this message
immediately from your computer.  Any other use, retention,
dissemination, forwarding, printing, or copying of this email is
strictly prohibited.