Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)
Claudio Telmon <claudio@telmon.org> Sat, 27 June 2009 15:21 UTC
Return-Path: <claudio@telmon.org>
X-Original-To: asrg@core3.amsl.com
Delivered-To: asrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EA2F28C186 for <asrg@core3.amsl.com>; Sat, 27 Jun 2009 08:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.302
X-Spam-Level:
X-Spam-Status: No, score=0.302 tagged_above=-999 required=5 tests=[AWL=-0.861, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, SARE_SUB_RAND_LETTRS4=0.799, URIBL_RHS_DOB=1.083]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EifkQyDZGwd for <asrg@core3.amsl.com>; Sat, 27 Jun 2009 08:21:15 -0700 (PDT)
Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id 0DCEC3A6A3E for <asrg@irtf.org>; Sat, 27 Jun 2009 08:21:14 -0700 (PDT)
Received: from 88-149-251-208.dynamic.ngi.it ([::ffff:88.149.251.208]) by slim-4c.inet.it via I-SMTP-5.6.0-560 id ::ffff:88.149.251.208+XYOAt9RWdu; Sat, 27 Jun 2009 17:21:32 +0200
Message-ID: <4A4638FB.4010207@telmon.org>
Date: Sat, 27 Jun 2009 17:21:31 +0200
From: Claudio Telmon <claudio@telmon.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090318 Lightning/0.8 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666
MIME-Version: 1.0
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
References: <4A43B696.2000106@cybernothing.org> <4A449A7C.6070106@tana.it> <20090626100736.GA29159@gsp.org> <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk>
In-Reply-To: <9088C3969464C4F82C833994@lewes.staff.uscs.susx.ac.uk>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] draft-irtf-asrg-criteria (was Re: request for review for a non FUSSP proposal)
X-BeenThere: asrg@irtf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Sat, 27 Jun 2009 15:21:17 -0000
First, let me say, from the point of view of one that just submitted a proposal, that I've been looking for such a document for days before submitting my proposal to the list, and (once finished) this document should definitely be cited in the faq. I don't think that spam should be redefined in this kind of document, since it wouldn't be of much help to prospective proposers. I don't think that having a proposer think at whether a specific class of messages is spam or not would help in getting better proposals, especially since even this knowledgeable group can't agree on the term. Said that, I don't think that the definition in the document is appropriate, since a lot of messages, including harassment messages and messages from some co-workers or bosses :) are messages one wouldn't definitely like to be presented, but unfortunately they can hardly be classified as spam :) Some additional information in the document could help in preparing a better proposal, e.g. a list of "cases" and "issues" to be considered: I spent a lot of time trying to "imagine" some, but still missed e.g. the shared address issue. Some could be: - multiple recipients in messages; - webmail vs. personal MUA vs. both; - message forwarding - mailing lists - incoming MTA different from outgoing MTA - legacy protocol versions - ... This would avoid proposals that miss some key situations where they will break. While it is reasonable to expect that proposers are willing to understand the difficulties and internals of email before proposing anything, I think it's not reasonable to expect them to have a good understanding from the beginning: it often happen that truly innovative proposals come from people who look at a system "from the outside". Maybe also a reference to a description of current techniques, both implemented and failed. Many of you pointed me to e.g. different address tagging services/proposals. While I had already seen most, I spent a lot of time in this search too (not that this has been wasted time). But, while I've seen that the ASRG moved to non-consent research, I didn't find anywhere why, so I was left guessing why it happened. Also, the critical requirement that it should reduce the effort of managing spam for the recipient is not very clear. Many solutions may reduce the burden for some, and increase it for others. Also, for many it will reduce the bured of some tasks but will add some other tasks. My discussion with Rich about MUAs, address books etc. is a clear example. So, I suggest that being able to classify users with respect to increase/decrease of burden, and to clearly state what additional tasks are required, would be more useful. Also, just stating that it would decrease the burden for the majority of users is not enough, or else anything that works for Outlook and a couple of ESP would suffice. Another point is the "voluntary participation", which may also be unclear. As an example, one can "voluntarily" enable the consent framework, but without some care this would force its correspondent to deal with the framework too. This may seem a violation of the rule, but many protocols have the same requirement. As an example, if I protect my http service with TSL, users willing to access it will need to implement TSL, and I won't usually offer the same service, and this is common to most security protocols (e.g. VPNs). One could argue that with email, one could not know that the security/antispam protocol until a message is rejected. As Alessandro suggested, I'm interested especially in this final issue. -- Claudio Telmon claudio@telmon.org http://www.telmon.org
- [Asrg] draft-irtf-asrg-criteria (was Re: request … J.D. Falk
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Douglas Otis
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Alessandro Vesely
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Rich Kulawiec
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Ian Eiloart
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Ian Eiloart
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Alessandro Vesely
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Ian Eiloart
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Seth
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Seth
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Ian Eiloart
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Seth
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… der Mouse
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… der Mouse
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Ian Eiloart
- Re: [Asrg] draft-irtf-asrg-criteria is missing Ou… Ian Eiloart
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Seth
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Alessandro Vesely
- Re: [Asrg] draft-irtf-asrg-criteria is missing Ou… Douglas Otis
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… J.D. Falk
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Douglas Otis
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Alessandro Vesely
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Claudio Telmon
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Dave CROCKER
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Claudio Telmon
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Michael Thomas
- Re: [Asrg] No, we're not going to define spam John Levine
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Ian Eiloart
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Ian Eiloart
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Alessandro Vesely
- Re: [Asrg] No, we're not going to define spam Alessandro Vesely
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Claudio Telmon
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Rich Kulawiec
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Alessandro Vesely
- Re: [Asrg] draft-irtf-asrg-criteria is missing Ou… Douglas Otis
- Re: [Asrg] really, we're not going to define spam… John Levine
- Re: [Asrg] draft-irtf-asrg-criteria is missing Ou… Danny Angus
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Danny Angus
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Steve Atkins
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Seth
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Claudio Telmon
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Alessandro Vesely
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Claudio Telmon
- Re: [Asrg] draft-irtf-asrg-criteria is missing Ou… Douglas Otis
- Re: [Asrg] draft-irtf-asrg-criteria (was Re: requ… Danny Angus
- Re: [Asrg] draft-irtf-asrg-criteria is missing Ou… Danny Angus