[Asrg] Report-as-Spam header

Brendan Hide <brendan@swiftspirit.co.za> Sun, 10 June 2012 16:26 UTC

Return-Path: <brendan@swiftspirit.co.za>
X-Original-To: asrg@ietfa.amsl.com
Delivered-To: asrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA0121F860F for <asrg@ietfa.amsl.com>; Sun, 10 Jun 2012 09:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.002
X-Spam-Level:
X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HS_INDEX_PARAM=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJWmxREVsBdH for <asrg@ietfa.amsl.com>; Sun, 10 Jun 2012 09:26:22 -0700 (PDT)
Received: from fw2a.glodns.net (fw2a.glodns.net [196.220.48.60]) by ietfa.amsl.com (Postfix) with ESMTP id F22AB21F85FB for <asrg@irtf.org>; Sun, 10 Jun 2012 09:26:21 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by fw2a.glodns.net (Postfix) with ESMTP id A384D28C07E for <asrg@irtf.org>; Sun, 10 Jun 2012 16:26:20 +0000 (UTC)
X-Virus-Scanned: amavisd-new at fw2a.glodns.net
Received: from fw2a.glodns.net ([196.220.48.60]) by localhost (fw2a.glodns.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2x8FvfHlGO3z for <asrg@irtf.org>; Sun, 10 Jun 2012 18:26:14 +0200 (SAST)
Received: from control.glodns.net (smtp1w.glodns.net [75.126.138.3]) by fw2a.glodns.net (Postfix) with ESMTP id DB78128C074 for <asrg@irtf.org>; Sun, 10 Jun 2012 18:26:14 +0200 (SAST)
Received: (qmail 23067 invoked from network); 10 Jun 2012 18:26:14 +0200
Received: from blvd-cr1-nat1.wa.co.za (HELO watricky.invalid.co.za) (196.220.32.228) by smtp1b.plesk.glodns.net with SMTP; 10 Jun 2012 18:26:14 +0200
Message-ID: <4FD4CAA4.5050006@swiftspirit.co.za>
Date: Sun, 10 Jun 2012 18:26:12 +0200
From: Brendan Hide <brendan@swiftspirit.co.za>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Asrg] Report-as-Spam header
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.12
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/options/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: Sun, 10 Jun 2012 16:26:23 -0000

Hi all

Has a spam reporting header been considered, similar to the 
List-Unsubscribe header in RFC2369? Already many Bulk Mail service 
providers provide readable headers directing recipients where to send 
spam complaints. I don't think this is standardised in any way however.

One of my specialities is handling abuse complaints and monitoring 
outbound spam blocking systems. The performance of my team and I have a 
direct correlation to network reputation and RBL listings as a result of 
compromised end-user accounts. Automated (or even semi-automated) 
suspension of compromised accounts would aid in this field and would 
probably outperform any army of abuse-complaint "specialists".

The notion of being able to report back to the responsible ISP/mail 
server directly without going through a long process is attractive. In 
some environments a relay cluster with outbound anti-spam scanning could 
even report high-spam-scoring mails with little to no human intervention.

Differences between List-Unsubscribe and "Report-as-Spam":
List-Unsubscribe is added by List Maintainers or Mailing-List 
Distribution servers. Report-as-Spam could be added by the mail or relay 
server independently of the sender's MUA when the server receives the 
mail. The implication is that every "MAIL FROM" could result in a unique 
Report-as-Spam ID, similar to where Message-Id would be generated. If a 
relay server implicitly trusts a mail server that already adds a 
Report-as-Spam header then the relay server would not bother to add 
another header.

Drawbacks:
Broken Header/Header Abuse? - My guess is that we will probably end up 
with RBLs targeting servers that relay with invalid headers
Performance - Mail servers implementing an automated suspension system 
would need to maintain a database (or would need to be able to trawl its 
own logs) for the account responsible for the abuse. This does not 
necessarily have to be a large database, however it is conceivable that 
some mail systems will want to trim this database to only include recent 
outgoing mail.

Advantages:
Better First Response against compromised accounts
Standardisation of as-of-yet incompatible/incongruent features

Any comments, positive or negative, would be appreciated, unless its 
simply a link to those lists of "why your idea won't stop spam". This 
isn't supposed to stop spam, its supposed to make fighting spam more 
effective for responsible ISPs.

-- 
__________
Brendan Hide
http://swiftspirit.co.za/
Web Africa - Internet Business Solutions
http://www.webafrica.co.za/?AFF1E97