[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
- [Asrg] Report-as-Spam header Brendan Hide
- Re: [Asrg] Report-as-Spam header SM
- Re: [Asrg] Report-as-Spam header Brendan Hide
- Re: [Asrg] Report-as-Spam header SM
- Re: [Asrg] Report-as-Spam header Alessandro Vesely
- Re: [Asrg] Report-as-Spam header John Levine
- Re: [Asrg] Report-as-Spam header Brendan Hide
- Re: [Asrg] Report-as-Spam header Brendan Hide
- Re: [Asrg] Report-as-Spam header Brendan Hide