From brendan@swiftspirit.co.za Sun Jun 10 09:26:23 2012 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 ; 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 ; 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 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 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 List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From sm@resistor.net Sun Jun 10 12:41:57 2012 Return-Path: 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 2FD5621F8525 for ; Sun, 10 Jun 2012 12:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.11 X-Spam-Level: X-Spam-Status: No, score=-101.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, USER_IN_WHITELIST=-100] 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 f7UuDX0qc4OG for ; Sun, 10 Jun 2012 12:41:55 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2EE21F850B for ; Sun, 10 Jun 2012 12:41:54 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5AJfnc4007529 for ; Sun, 10 Jun 2012 12:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339357313; i=@resistor.net; bh=/sLzsAdDOidojZeoy0ct/dy8vzsnI/GqNOGSs/WFYxc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=lo1r7w3dTjyXhiGdi6ySZdDuQkHd8zHfFRQZ5LTP30pCfvX+GeV8Gl/iLj40Rpr7j aGVGRp59ZYnrSxVxlZtN1DZVoElM9vxKdn+8AOWY3bbNXsnHY0TdjwoQIDJchtkyUV jP6LmHvowUYYKr3TLEbw5dTqmqCPUg0mBSinnel8= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1339357313; i=@resistor.net; bh=/sLzsAdDOidojZeoy0ct/dy8vzsnI/GqNOGSs/WFYxc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=yY+KLR7WyIfZBJAAnxx1Pbg+uyp0NqDllY/2sWJ8wpgCcFYqtlBJsjLwkBgqu18S+ DJJXFeCaSRcS7SsF8SkMcXA67bSpECN9AmP9L2DJQJgTG/MZuaB3djuSdh79FtkCRG fNKM5N/F4JbfuQ+Ohhi7FGVpOwMEJ9x8T6hhHIfc= Message-Id: <6.2.5.6.2.20120610123350.0939fc28@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 10 Jun 2012 12:41:23 -0700 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <4FD4CAA4.5050006@swiftspirit.co.za> References: <4FD4CAA4.5050006@swiftspirit.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2012 19:41:57 -0000 Hi Brendan, At 09:26 10-06-2012, Brendan Hide wrote: >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. [snip] >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. Have you considered using ARF (RFC 5965)? Please also see some of the work from the IETF MARF working group. Regards, -sm From brendan@swiftspirit.co.za Sun Jun 10 20:37:12 2012 Return-Path: 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 ; 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 ; 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 ; 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 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 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 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 List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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/ From sm@resistor.net Mon Jun 11 02:11:02 2012 Return-Path: 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 3C8E621F8535 for ; Mon, 11 Jun 2012 02:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 XsEFNX4PjNNG for ; Mon, 11 Jun 2012 02:10:56 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1676E21F855B for ; Mon, 11 Jun 2012 02:10:56 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q5B9AoXj002771 for ; Mon, 11 Jun 2012 02:10:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1339405854; i=@resistor.net; bh=hITztCYN5hgO9m2ZktTqttZp0xoo6AWVvCpJE4yJoQ4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=pSv6CBjsxM3JBgP5Cz53I6twuPzZ33z7JIPY67WCylYJGIeK38Xx2WV8EM0h51fdg xLDGeR8S5xWhmhLyzatHuTqfb1Ce6umX+f+fsRaEHg1bLEzvhYGAIRMw0dWSll/vnk w0mj/d1fek6tWL2wbZFR+BttZBPd7V1GhrEgvPMA= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1339405854; i=@resistor.net; bh=hITztCYN5hgO9m2ZktTqttZp0xoo6AWVvCpJE4yJoQ4=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=UTZWhQvougReYslAJbp+UcHO08yW9w8fM0pwnazeHQMdWs3MG51ZY3yWJdsN3Qtvo OFlysyl7I9+leEDW3pTu83lJpo88NXrbb6oGM2NVRXAiM8xQF9waz5nBDQD/wJc2r0 X0DEaeFWdCVCRxemHmvyeqFtRpjJ8bhNOFXTrRYU= Message-Id: <6.2.5.6.2.20120611012901.09858498@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 11 Jun 2012 02:05:48 -0700 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: <4FD567DB.2080407@swiftspirit.co.za> References: <4FD4CAA4.5050006@swiftspirit.co.za> <6.2.5.6.2.20120610123350.0939fc28@resistor.net> <4FD567DB.2080407@swiftspirit.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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 List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 09:11:02 -0000 Hi Brendan, At 20:36 10-06-2012, Brendan Hide wrote: > 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 [snip] >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? There are systems which add a reporting URL for users to provide feedback. That can be used for point (a). A server-side header can be added in less than an hour if you already have the backend in place to process the report. The corresponding support in MUAs would take years. The likelihood of that happening is very small due to legacy. Picking points from your previous message: >Drawbacks: >Broken Header/Header Abuse? - My guess is that we will probably end >up with RBLs targeting servers that relay with invalid headers There will be abuse. >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. It's possible to track even on a large system. >Advantages: >Better First Response against compromised accounts That only works if both sides are proactive. That's rare in practice as abuse handling is an expense people would prefer not to have. >Standardisation of as-of-yet incompatible/incongruent features That can take a year or more. Some could write a draft as a starting point for the discussion. Regards, -sm From vesely@tana.it Mon Jun 11 07:27:35 2012 Return-Path: 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 B4EC121F850C for ; Mon, 11 Jun 2012 07:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4] 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 b0R6yx1w5u0R for ; Mon, 11 Jun 2012 07:27:35 -0700 (PDT) Received: from wmail.tana.it (mail.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id B9B8821F84EC for ; Mon, 11 Jun 2012 07:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1339424852; bh=N6pOBo5LPT22ZpfLCTJpiu4LHPukvqm8RDZfi7A5ocY=; l=2575; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=DDDN+4pZ8iKcMpuIJ65b+rfkFZ2TqTVXI/G7sN8ilhuVserDDEHGCdO39h7WSrhE1 BvzJswOL/bRE2LHVmbfIx/7vIXLQCbNbhlwdLyr4jgvMtmD8znak14xHsTMxOpw7bj 2qXuhXp6nYI1J4qFOPK4eyJBYfCVhYJR9BsPUTqU= Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Mon, 11 Jun 2012 16:27:32 +0200 id 00000000005DC033.000000004FD60054.00007C42 Message-ID: <4FD60054.9060706@tana.it> Date: Mon, 11 Jun 2012 16:27:32 +0200 From: Alessandro Vesely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: asrg@irtf.org References: <4FD4CAA4.5050006@swiftspirit.co.za> <6.2.5.6.2.20120610123350.0939fc28@resistor.net> <4FD567DB.2080407@swiftspirit.co.za> In-Reply-To: <4FD567DB.2080407@swiftspirit.co.za> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 14:27:35 -0000 On Mon 11/Jun/2012 05:36:59 +0200 Brendan Hide wrote: > > 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. Having such links is required by law in some countries. However, some of them just don't work. Some of them seem to work and tell recipients they're unsubscribed from stream "xyz", but then they get spam with /unsubscribe?id=xyzbis, /unsubscribe?id=xyzter, and so forth. In addition, spammers can add such kind of links pretending to be a reputable originator, in the same way that they fake "From:" and "Return-Path:" header fields. Thus, getting at least a part of the header and body of reported messages would seem to be appropriate in order to reliably determine the originator's identity. > 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? A disadvantage of reporting spam directly, from final recipients to senders, is that each end user would have to keep track of the complaints she sent. The reporting entity needs to assess the trustworthiness of each sender, at least to the extent of learning whether abuse reporting has any effect. For example, in some cases it may be better to send reports to the sender's network provider. Thus, it may be convenient to delegate abuse reporting to a trusted central service, such as the recipient's mailbox provider. In the latter scenario, MUA support can be limited to flagging messages to be reported as spam. It would work much like "spam" buttons on webmail sites. That strategy requires less updates to MUA functionality, as it is sufficient to upgrade server software on both sides. However, server software itself is not updated as often as needed, since there are still MXex that understand HELO but not EHLO. From johnl@iecc.com Mon Jun 11 08:00:29 2012 Return-Path: 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 2C2C321F864B for ; Mon, 11 Jun 2012 08:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.785 X-Spam-Level: X-Spam-Status: No, score=-108.785 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] 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 hSG1fZm8+lgI for ; Mon, 11 Jun 2012 08:00:28 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id DCEA821F864E for ; Mon, 11 Jun 2012 08:00:27 -0700 (PDT) Received: (qmail 73154 invoked from network); 11 Jun 2012 15:00:26 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 11 Jun 2012 15:00:26 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fd6080a.xn--btvx9d.k1206; i=johnl@user.iecc.com; bh=ek1/omTERjasJUZlDJQ3m5RS7zxX+tEMF3x9tbpm7oU=; b=sIj4uQ1zsa4s8CKcKoNvLv3uhJfV5+Atw8EaxCKMZXvgi5FEMpWR0iPekzVPuaoVuJpuPfdrZcSqkKiOUYn4GtYEtFUkAFEiBSjtDUyyywoSggzTsBLxm7LC/HCE8e/dkw9n8lPMkcCdc5aC7YScUw4S76OFCxaStTU+vE8UbhE= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=4fd6080a.xn--btvx9d.k1206; olt=johnl@user.iecc.com; bh=ek1/omTERjasJUZlDJQ3m5RS7zxX+tEMF3x9tbpm7oU=; b=zFKnb0qS0xUfUXkglpBIivJmtQ/PlOf1ZgyFVNwr9HlszHt22z38gI4FoM72CB+za7gFcUFA28IHiDNylY7sRpL9F58yI9GCkl6+d1GfulnLBWzanQiUiosC1UpjzR+x6AOH49li76Q0+h4wnw45X6t7dGxGYYMzALu8quY+fBA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 11 Jun 2012 15:00:04 -0000 Message-ID: <20120611150004.97523.qmail@joyce.lan> From: "John Levine" To: asrg@irtf.org In-Reply-To: <4FD4CAA4.5050006@swiftspirit.co.za> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit 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 List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 15:00:29 -0000 >Has a spam reporting header been considered, similar to the >List-Unsubscribe header in RFC2369? Yes, but I doubt it would be very useful. The problem is that bad guys can add the same headers as good guys, so it would likely be mostly used as a way to deflect complaints away from the ISP to the spammer. There are web control panels that add X-Anti-Abuse headers that I find mostly useful as a high scoring indicator in Spamassassin. You could envision some way to check and see if a reporting header was valid, but if you do that, whatever authority you contacted to check for validity could as easily provide the reporting address directly. The vast majority of ARF reports are sent as part of privately arranged feedback loops, where a sender tells a recipient what its outgoing IPs or DKIM signatures are, and the recipient sends a report when a user marks a message as spam. I also use ARF for unsolicited reports, finding the contact address through a combination of abuse.net and a modest (3000 entry) private list of IP ranges. That works reasonably well, but I'm not sure how well it scales. The question of how to figure out where to send abuse reports has come up many times in the past. You might want to look through the archives and the wiki. R's, John From brendan@swiftspirit.co.za Mon Jun 11 11:52:26 2012 Return-Path: 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 79E5621F845F for ; Mon, 11 Jun 2012 11:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 IlzQv6EvQBaz for ; Mon, 11 Jun 2012 11:52:24 -0700 (PDT) Received: from fw10a.glodns.net (fw10a.glodns.net [196.220.48.58]) by ietfa.amsl.com (Postfix) with ESMTP id E007021F8617 for ; Mon, 11 Jun 2012 11:52:23 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by fw10a.glodns.net (Postfix) with ESMTP id 78DFF250044 for ; Mon, 11 Jun 2012 18:52:22 +0000 (UTC) X-Virus-Scanned: amavisd-new at fw10a.glodns.net Received: from fw10a.glodns.net ([196.220.48.58]) by localhost (fw10a.glodns.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id aiSF+I5U20AS for ; Mon, 11 Jun 2012 20:52:07 +0200 (SAST) Received: from control.glodns.net (smtp1w.glodns.net [75.126.138.3]) by fw10a.glodns.net (Postfix) with ESMTP id 94B71250261 for ; Mon, 11 Jun 2012 20:52:07 +0200 (SAST) Received: (qmail 12515 invoked from network); 11 Jun 2012 20:52:06 +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; 11 Jun 2012 20:52:03 +0200 Message-ID: <4FD63E4F.3020006@swiftspirit.co.za> Date: Mon, 11 Jun 2012 20:51:59 +0200 From: Brendan Hide User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4FD4CAA4.5050006@swiftspirit.co.za> <6.2.5.6.2.20120610123350.0939fc28@resistor.net> <4FD567DB.2080407@swiftspirit.co.za> <6.2.5.6.2.20120611012901.09858498@resistor.net> In-Reply-To: <6.2.5.6.2.20120611012901.09858498@resistor.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SM 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 List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 18:52:26 -0000 Hi, SM You've made some good points I'll be considering. Thank you for your comments thus far. :) On 06/11/12 11:05, SM wrote: >> Better First Response against compromised accounts > Advantages: > That only works if both sides are proactive. That's rare in practice > as abuse handling is an expense people would prefer not to have. In my case we're proactive and the current process is expensive on man hours. Automation would be more cost-effective. -- __________ Brendan Hide Web Africa - Internet Business Solutions http://www.webafrica.co.za/?AFF1E97 From brendan@swiftspirit.co.za Mon Jun 11 11:53:08 2012 Return-Path: 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 CEA7721F861B for ; Mon, 11 Jun 2012 11:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, 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 TZNTKtY5Dk2l for ; Mon, 11 Jun 2012 11:53:07 -0700 (PDT) Received: from fw9a.glodns.net (fw9a.glodns.net [196.220.48.59]) by ietfa.amsl.com (Postfix) with ESMTP id D6DB321F8497 for ; Mon, 11 Jun 2012 11:53:07 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by fw9a.glodns.net (Postfix) with ESMTP id 433C526111 for ; Mon, 11 Jun 2012 18:53:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at fw9a.glodns.net Received: from fw9a.glodns.net ([196.220.48.59]) by localhost (fw9a.glodns.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 03t1iyeKLOOC for ; Mon, 11 Jun 2012 20:53:01 +0200 (SAST) Received: from control.glodns.net (smtp1w.glodns.net [75.126.138.3]) by fw9a.glodns.net (Postfix) with ESMTP id B13DD260DF for ; Mon, 11 Jun 2012 20:53:01 +0200 (SAST) Received: (qmail 12986 invoked from network); 11 Jun 2012 20:53:01 +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; 11 Jun 2012 20:53:01 +0200 Message-ID: <4FD63E8A.3030904@swiftspirit.co.za> Date: Mon, 11 Jun 2012 20:52:58 +0200 From: Brendan Hide User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <4FD4CAA4.5050006@swiftspirit.co.za> <6.2.5.6.2.20120610123350.0939fc28@resistor.net> <4FD567DB.2080407@swiftspirit.co.za> <4FD60054.9060706@tana.it> In-Reply-To: <4FD60054.9060706@tana.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 18:53:09 -0000 Hi Allesandro On 06/11/12 16:27, Alessandro Vesely wrote: > On Mon 11/Jun/2012 05:36:59 +0200 Brendan Hide wrote: >> Legitimate bulk mail services are already successfully using simple >> headers and unique IDs. > Having such links is required by law in some countries. However, some > of them just don't work. Some of them seem to work and tell > recipients they're unsubscribed from stream "xyz", but then they get > spam with /unsubscribe?id=xyzbis, /unsubscribe?id=xyzter, and so > forth. I hadn't thought about the links being required by law. Re the differing IDs, it *has to* be unique for every mail sent, not just per recipient. This aids in tracking down a specific offence. > In addition, spammers can add such kind of links pretending to > be a reputable originator, in the same way that they fake "From:" and > "Return-Path:" header fields. Thus, getting at least a part of the > header and body of reported messages would seem to be appropriate in > order to reliably determine the originator's identity. I don't see this part being an issue at all. If my report-handling server responds saying the report is invalid then the relaying IP address will very quickly find its way onto an RBL. On the other hand: > A disadvantage of reporting spam directly, from final recipients to > senders, is that each end user would have to keep track of the > complaints she sent. The reporting entity needs to assess the > trustworthiness of each sender. This IS a very good point (even if it is made indirectly). If reports are sent directly to the spammer, the spammer is not going to do anything about it while the end-recipient believes he has properly reported the issue. This would not be such an issue if the ISP is pro-active and aware of the Report-as-Spam header (the ISP might insert their own header above the spammer's). Additionally, if the spammer has a dedicated server (ie the ISP does not intercept/relay the mail directly) then, again, the ISP won't be able to insert its own header. Ultimately, there's no way for the end-user to place any trust in the header's origin. DNS is probably the only saving grace but, regardless, its back to the drawing board. Thank you, Allesandro. :) -- __________ Brendan Hide Web Africa - Internet Business Solutions http://www.webafrica.co.za/?AFF1E97 From brendan@swiftspirit.co.za Mon Jun 11 11:57:16 2012 Return-Path: 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 D997B21F8471 for ; Mon, 11 Jun 2012 11:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, 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 W271jAxhIpXc for ; Mon, 11 Jun 2012 11:57:16 -0700 (PDT) Received: from fw2a.glodns.net (fw2a.glodns.net [196.220.48.60]) by ietfa.amsl.com (Postfix) with ESMTP id 4958221F846E for ; Mon, 11 Jun 2012 11:57:16 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by fw2a.glodns.net (Postfix) with ESMTP id BA5CE28C2C3 for ; Mon, 11 Jun 2012 18:57:15 +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 gjM7eyGGwuN1 for ; Mon, 11 Jun 2012 20:57:10 +0200 (SAST) Received: from control.glodns.net (smtp1w.glodns.net [75.126.138.3]) by fw2a.glodns.net (Postfix) with ESMTP id 2886B28C153 for ; Mon, 11 Jun 2012 20:57:10 +0200 (SAST) Received: (qmail 14560 invoked from network); 11 Jun 2012 20:57:10 +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; 11 Jun 2012 20:57:09 +0200 Message-ID: <4FD63F83.5060503@swiftspirit.co.za> Date: Mon, 11 Jun 2012 20:57:07 +0200 From: Brendan Hide User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20120611150004.97523.qmail@joyce.lan> In-Reply-To: <20120611150004.97523.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John Levine 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 List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 18:57:17 -0000 On 06/11/12 17:00, John Levine wrote: > The problem is that bad guys can add the same headers as good guys, so > it would likely be mostly used as a way to deflect complaints away > from the ISP to the spammer. You've hit the nail on the head. I suspect a reverse DNS scheme *could* be the key here - but, per my other mail, its back to square one. Thank you for your input. -- __________ Brendan Hide Web Africa - Internet Business Solutions http://www.webafrica.co.za/?AFF1E97