Re: [Asrg] Report-as-Spam header

Brendan Hide <brendan@swiftspirit.co.za> Mon, 11 June 2012 03:37 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 CDCF621F84DD for <asrg@ietfa.amsl.com>; Sun, 10 Jun 2012 20:37:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 0iAxDkQ010Q6 for <asrg@ietfa.amsl.com>; Sun, 10 Jun 2012 20:37:12 -0700 (PDT)
Received: from wnls-smtp2.wa.co.za (wnls-smtp2.wa.co.za [41.185.62.207]) by ietfa.amsl.com (Postfix) with ESMTP id B969E21F84D8 for <asrg@irtf.org>; Sun, 10 Jun 2012 20:37:11 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by wnls-smtp2.wa.co.za (Postfix) with ESMTP id 38CED4E41BF; Mon, 11 Jun 2012 03:36:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at wnls-smtp2.wa.co.za
Received: from wnls-smtp2.wa.co.za ([127.0.0.1]) by localhost (wnls-smtp2.wa.co.za [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Icw+6OwzJDzG; Mon, 11 Jun 2012 05:36:09 +0200 (SAST)
Received: from [192.168.1.129] (dsl-61-97-90.dynamic.wa.co.za [41.61.97.90]) by wnls-smtp2.wa.co.za (Postfix) with ESMTP id CEE9A4E41A5; Mon, 11 Jun 2012 05:36:09 +0200 (SAST)
Message-ID: <4FD567DB.2080407@swiftspirit.co.za>
Date: Mon, 11 Jun 2012 05:36:59 +0200
From: Brendan Hide <brendan@swiftspirit.co.za>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <4FD4CAA4.5050006@swiftspirit.co.za> <6.2.5.6.2.20120610123350.0939fc28@resistor.net>
In-Reply-To: <6.2.5.6.2.20120610123350.0939fc28@resistor.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: SM <sm@resistor.net>
Subject: Re: [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: Mon, 11 Jun 2012 03:37:12 -0000

On 2012/06/10 09:41 PM, SM wrote:
[snip]
> Have you considered using ARF (RFC 5965)?  Please also see some of the 
> work from the IETF MARF working group.
I hadn't considered utilising ARF here. While incoming complaints do 
typically contain the whole mail or at least all headers, an automated 
system would not require so much data. In my case relayed mails are kept 
in a retrievable format for at least a few days. In theory, I only need 
very few of the headers of a mail in order to find the full content, 
perhaps even only one header. A full report in ARF format is far too 
much information when all I really want is enough information to 
know/determine:
a) A recipient reckons the mail was spam
b) The account responsible for having sent the mail

Having gone through all of the IETF MARF working group's draft 
documents, ARF is a MIME format for reports and does not define how the 
reports are to be sent. I like the concept however, per above, it seems 
inappropriate, perhaps even superfluous. The working group is looking 
towards utilising DNS in order to determine reporting mechanisms and 
protocols. Again, this appears far too complicated for reporting spam.

Legitimate bulk mail services are already successfully using simple 
headers and unique IDs. Typically their "unsubscribe" and 
"report-as-spam" links embedded in the headers and in the mail itself 
all use the same ID with only the URL being slightly different, for 
example /unsubscribe?id=xyz and /report?id=xyz. This has required 
minimal investment and research for the providers to implement yet, in 
theory, it already achieves a reporting mechanism that can be automated. 
The only hindrance with this type of reporting is critical mass and 
standardisation. I'm not aware of any two bulk mail services that use 
the same format or header.

A concern I'm looking at is development time and achievable results. How 
many days and lines of code will it take to implement a server-side 
report-as-spam header (and corresponding support in MUAs) vs 
implementing the reporting mechanisms the IETF MARF Working Group are 
working on?

-- 
Brendan Hide

http://swiftspirit.co.za/