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/
- [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