Re: [Asrg] Adding a spam button to MUAs

"BOBOTEK, ALEX (ATTCINW)" <AB3778@att.com> Wed, 09 December 2009 07:07 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 B9E8F3A69D9 for <asrg@core3.amsl.com>; Tue, 8 Dec 2009 23:07:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.443
X-Spam-Level:
X-Spam-Status: No, score=-106.443 tagged_above=-999 required=5 tests=[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 6ZI6MORA5AaG for <asrg@core3.amsl.com>; Tue, 8 Dec 2009 23:07:20 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id C4E313A691F for <asrg@irtf.org>; Tue, 8 Dec 2009 23:07:20 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: AB3778@att.com
X-Msg-Ref: server-12.tower-120.messagelabs.com!1260342428!50291559!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [144.160.112.25]
Received: (qmail 11622 invoked from network); 9 Dec 2009 07:07:08 -0000
Received: from sbcsmtp3.sbc.com (HELO tlph064.enaf.dadc.sbc.com) (144.160.112.25) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 9 Dec 2009 07:07:08 -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 nB97777N023126 for <asrg@irtf.org>; Wed, 9 Dec 2009 01:07:08 -0600
Received: from td03xsmtp006.US.Cingular.Net (td03xspare19-new.us.cingular.net [135.179.64.43] (may be forged)) by tlph064.enaf.dadc.sbc.com (8.14.3/8.14.3) with ESMTP id nB9774Ei022614 for <asrg@irtf.org>; Wed, 9 Dec 2009 01:07:04 -0600
Received: from BD01XSMTP003.US.Cingular.Net ([135.163.18.44]) by td03xsmtp006.US.Cingular.Net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Dec 2009 01:07:04 -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:07:03 -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:08:56 -0800
Message-ID: <BF533A28DBE487489EAB3411C5412CBE0F421DF5@BD01MSXMB015.US.Cingular.Net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: RE:[Asrg] Adding a spam button to MUAs
Thread-Index: Acp4nnlOdecDym0rRc2EwB5KYAJnPw==
From: "BOBOTEK, ALEX (ATTCINW)" <AB3778@att.com>
To: <asrg@irtf.org>
X-OriginalArrivalTime: 09 Dec 2009 07:07:03.0604 (UTC) FILETIME=[35C96F40:01CA789E]
X-Mailman-Approved-At: Wed, 09 Dec 2009 11:36:16 -0800
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:08:33 -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.