Re: [Asrg] request for review for a non FUSSP proposal
Claudio Telmon <claudio@telmon.org> Wed, 24 June 2009 07:36 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 372783A6F52 for <asrg@core3.amsl.com>; Wed, 24 Jun 2009 00:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.623
X-Spam-Level:
X-Spam-Status: No, score=-0.623 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245]
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 zKnTw1G4lybC for <asrg@core3.amsl.com>; Wed, 24 Jun 2009 00:36:46 -0700 (PDT)
Received: from slim-4c.inet.it (slim-4c.inet.it [213.92.5.127]) by core3.amsl.com (Postfix) with ESMTP id 9A24B3A68DF for <asrg@irtf.org>; Wed, 24 Jun 2009 00:36:43 -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+j2df9xGEJI; Wed, 24 Jun 2009 09:36:15 +0200
Message-ID: <4A41D76E.3040404@telmon.org>
Date: Wed, 24 Jun 2009 09:36:14 +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: <4A3DFC91.2090506@telmon.org> <4A3F9B2B.8020603@tana.it> <4A3FF3AF.9030401@telmon.org> <4A3FF7F1.1060705@nd.edu> <4A3FFB64.6030409@telmon.org> <20090622215251.GA2137@gsp.org> <4A400246.9060103@telmon.org> <20090623100542.GA9628@gsp.org> <4A40B2C0.8090604@telmon.org> <20090623203753.GA14617@gsp.org>
In-Reply-To: <20090623203753.GA14617@gsp.org>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [Asrg] 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: Wed, 24 Jun 2009 07:36:48 -0000
Rich Kulawiec wrote: > Maybe I'm not saying this very well. Let me try examples: Fred > doesn't know Barney, but gets a request for consent: it looks plausible, > so he grants it. But the request *wasn't* from Barney, it was from > the malware on Barney's laptop, and now Fred not only has to deal with > the spam, he's got to revoke the consent. This is a very good example, and I'm really happy to read it, since this is exactly the kind of problems that lets me put "non FUSSP" in the subject. In order to answer to your example, I must take advantage of existing antispam techniques. A consent request is a message with some syntax limits, but it's not just that: it is... well, a request for consent. If it looks like spam, current antispam tools could deal with it at least as good as they do with other messages (including DKIM, blacklist, check on the envelope, etc., but on a simpler and smaller message). If it doesn't look like spam, then Fred reads it: it is not spam, but now it must also be a convincing request specifically for Fred, so that he may be willing to believe it. Now, let's get to Fred: he receives a convincing request for a contact, whatever "convincing" means to him. Should he take the risk of granting a token? Answers: 1. No. It then just doesn't accept consent requests: whoever wants to contact him must manage to obtain a token through some other channel, e.g. a common friend. Somebody won't be able to contact him: Fred's choice. 2. Yes. Well, if a software on Barney's laptop manages to pass all the other antispam protections, and also passes the "Turing test" of mimicing Barney so good to be able to provide a request that is convincing for Fred, what can we do about it? The fact is, it shouldn't be that easy to get to this point, but we can't put limits on spammer talents :). 3. Yes, but with a trick. I wrote the trick in the "Additional fields in the MTA database" section. I don't like it, since it requires the MTA to be able to write in the database, which increases implementation complexity, but anyway: Barney is provided a token with a counter. When a message is received with that token, the MTA decreases the counter. When the counter is zero, the token is invalidated. Should Barney (or his personal zombie) abuse of the token, he could do so for a very limited number of messages. Should Barney actually be Fred's good fiend, he would be provided a new token. All this can be automatically managed, Fred would be asked by the MUA to choose if to set a counter when answering to the consent request, and could then answer "Yes" when, while reading Barney's messages, the MUA proposes to grant an unlimited token. This is at least how I conceived to deal with the problem. > I don't think so: there is no "local". Take for example, the members > of this mailing list: presuming that all of us use a mail client which > maintains an "address book" (and I don't) I'm certain that every one > of us has at least one entry in it that nobody else on this list has. > Most of us probably have *many* entries that nobody else on this list has. > And some of those entries are mailing lists which forward to many people. > Consider the extent of the damage that could be done if one of our > systems started spewing -- and how many spam recipients would have to > individually act in order to fully mitigate it. (Because A and B > revoking their consent to mail from Z does not help C, D, E...) > I don't think that much action would be needed. If my system is compromised, the tokens I have were compromised. My friends would complain (the "local" blame that works), and the spammer would have a token for the mailing list, the one I use, so it would be able to send spam to the list. While this wouldn't avoid spam to the list and its recipients, it wouldn't increase the risk/damage with respect to the current situation. The list (not me) owns tokens for its subscribers, and would forward the spam to these users with these tokens. These tokens wouldn't be compromised, since me and my personal zombie cannot access them. You would complain with the list owner: not with me, you don't have a token for it and in any case I wouldn't care (the "non local" blame). The list owner invalidates the token me and my personal zombie use in order to send messages to the list. End of the game. In the meantime, since my friends threaten me not to grant me tokens any more, I will probably clean up my system. If I don't, they will either stop communicating with me, or accept my little problem, the same way it usually goes with personal relationships. The mailing list will not. > (Which raises another scalability question: how would those of us who > have hundreds or thousands of correspondents find the time to manage > all this? And any of us participating in any mailing list have many more > potential correspondents: anyone on any of those lists might write to us > off-list. Same for anyone with a web site or blog or running any other > resource. A quick check of my personally-addressed and valid inbound mail > -- that is, not including mailing lists, not including spam or phishes -- > suggests that I've had over 11,500 correspondents in the past few years. > That's a lot of tokens to keep track of. And that's just *me*.) > Dealing with the framework without an address book would be actually impossible. With respect to numbers, I cannot answer. People and software explicitly dealing with large lists of addresses/subscribers would usually need to deal with an equal (well, double) number of tokens. People like you, dealing, if I understand correctly, with a large number of occasional correspondents, would need to do the same. Note however that probably in these cases, most of the token exchanges would be automated (you receive a token through a consent request, put a token in piggyback in your first answer) and handled by the MUA, you wouldn't even see these tokens. You would however need to collect some through other means. I cannot make any guess on numbers, nor would I take me or people I know as a reference on how many correspondents people has (did anybody ever publish any statistics on this?), but it would all turn down on how strict you are when accepting consent requests, and how strict your correspondents are. At one end, you answer to every contact request: this would end up with no consent protection, no limits to communications with you, and in some cases to useless messages (note that a consent request wouldn't be usually a useless message, it just must be short and text). You could then disable the consent protection on your address. At the other end, you do not accept consent requests, and end up with a private network. The same for your correspondents. Between these extremes, you select your correspondents, and the same do they, and still enjoy the protection of antispam tools, especially on consent requests. > Moreover, "informing the owners" has already proven to be a badly-losing > strategy. *If* the owners actually receive such communication > (telling them their system is probably compromised), they tend to > either disbelieve it, ignore it, classify it as a phish--often correct, > deny it, or act ineffectively to remedy the situation. Do you feel that the same would be true if the communication were not an automated communication but a communication from correspondents, not by email, and maybe implying the (temporary) inability to communicate with some of them? This would actually severely limit the usability of the scheme. > No anti-spam > scheme which requires effective, clueful participation by end-users has > any chance of working: if they existed (in very large numbers) then we > wouldn't have such a large spam problem because (a) their systems would > be compromised in huge numbers and (b) they would have learned by > now to never respond to any spam. I don't know. Me, as probably each of us, I'm often asked by friends to "reinstall" their systems because they are full of garbage. My email address probably got collected also through their systems, but I never considered blaming them, as I couldn't show any evidence of the fact. Should I receive spam using their token, I could be much more aggressive than I've been until now, and maybe others would do the same. This kind of blame usually works with other communication channels (again, people disseminating phone numbers), why shouldn't it work with email? People usually don't care of ineffective blame, but don't like to be considered stupid by their friends. -- Claudio Telmon claudio@telmon.org http://www.telmon.org
- [Asrg] request for review for a non FUSSP proposal Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Alessandro Vesely
- Re: [Asrg] request for review for a non FUSSP pro… Jose-Marcio Martins da Cruz
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Paul Russell
- Re: [Asrg] request for review for a non FUSSP pro… Steve Atkins
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Rich Kulawiec
- Re: [Asrg] request for review for a non FUSSP pro… Rich Kulawiec
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Lyndon Nerenberg
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Douglas Otis
- Re: [Asrg] request for review for a non FUSSP pro… Alessandro Vesely
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Rich Kulawiec
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Ian Eiloart
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Seth
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Ian Eiloart
- Re: [Asrg] request for review for a non FUSSP pro… Douglas Otis
- Re: [Asrg] request for review for a non FUSSP pro… Rich Kulawiec
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… John Levine
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Ian Eiloart
- Re: [Asrg] request for review for a non FUSSP pro… Jose-Marcio Martins da Cruz
- Re: [Asrg] request for review for a non FUSSP pro… Ian Eiloart
- Re: [Asrg] request for review for a non FUSSP pro… Seth
- Re: [Asrg] request for review for a non FUSSP pro… Jose-Marcio Martins da Cruz
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Rich Kulawiec
- [Asrg] VPNs (was: request for review for a non FU… Alessandro Vesely
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] VPNs (was: request for review for a no… Claudio Telmon
- Re: [Asrg] VPNs vs consent Claudio Telmon
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] request for review for a non FUSSP pro… Seth
- Re: [Asrg] request for review for a non FUSSP pro… Danny Angus
- Re: [Asrg] request for review for a non FUSSP pro… Ian Eiloart
- Re: [Asrg] request for review for a non FUSSP pro… Ian Eiloart
- Re: [Asrg] request for review for a non FUSSP pro… Alessandro Vesely
- Re: [Asrg] request for review for a non FUSSP pro… Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Rich Kulawiec
- Re: [Asrg] VPNs vs consent Rich Kulawiec
- Re: [Asrg] VPNs (was: request for review for a no… Rich Kulawiec
- Re: [Asrg] VPNs vs consent Claudio Telmon
- Re: [Asrg] request for review for a non FUSSP pro… Alessandro Vesely
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] VPNs vs consent Claudio Telmon
- Re: [Asrg] VPNs vs consent Rich Kulawiec
- Re: [Asrg] VPNs Alessandro Vesely
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] VPNs vs consent Claudio Telmon
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] VPNs vs consent Claudio Telmon
- Re: [Asrg] VPNs vs consent Claudio Telmon
- Re: [Asrg] VPNs vs consent Jose-Marcio Martins da Cruz
- Re: [Asrg] VPNs vs consent Claudio Telmon
- [Asrg] Shared addresses (was: Re: VPNs vs consent) Claudio Telmon
- Re: [Asrg] VPNs Bill Cole
- Re: [Asrg] VPNs Bill Cole
- Re: [Asrg] VPNs Bill Cole
- Re: [Asrg] VPNs Alessandro Vesely
- Re: [Asrg] VPNs Bill Cole
- Re: [Asrg] VPNs der Mouse
- [Asrg] A Vouch By Feedback proposal (was: VPNs) Alessandro Vesely
- Re: [Asrg] VPNs Daniel Feenberg
- [Asrg] gmail as source of spam (was VPN) David Wilson
- Re: [Asrg] A Vouch By Feedback proposal J.D. Falk
- Re: [Asrg] A Vouch By Feedback proposal Alessandro Vesely
- Re: [Asrg] A Vouch By Feedback proposal Claudio Telmon
- Re: [Asrg] A Vouch By Feedback proposal der Mouse
- Re: [Asrg] VPNs Rich Kulawiec
- Re: [Asrg] VPNs Bill Cole
- [Asrg] Too Big to Block? John Leslie
- Re: [Asrg] Too Big to Block? Chris Lewis
- Re: [Asrg] Too Big to Block? Dotzero
- Re: [Asrg] Too Big to Block? Chris Lewis
- Re: [Asrg] A Vouch By Feedback proposal Ian Eiloart
- Re: [Asrg] Too Big to Block? Ian Eiloart
- Re: [Asrg] A Vouch By Feedback proposal Rich Kulawiec
- Re: [Asrg] Too Big to Block? Rich Kulawiec
- Re: [Asrg] A Vouch By Feedback proposal Ian Eiloart
- Re: [Asrg] Too Big to Block? John Leslie
- Re: [Asrg] Too Big to Block? Alessandro Vesely
- Re: [Asrg] Too Big to Block? der Mouse
- Re: [Asrg] Too Big to Block? John Leslie
- Re: [Asrg] Too Big to Block? der Mouse
- Re: [Asrg] Too Big to Block? John Leslie
- Re: [Asrg] EPOSTAGE Too Big to Block? John Levine
- Re: [Asrg] EPOSTAGE Too Big to Block? John Leslie
- [Asrg] archives Tom Petch
- Re: [Asrg] archives Bill Cole
- Re: [Asrg] archives Claudio Telmon
- Re: [Asrg] archives Tom Petch