From asrg-bounces@ietf.org Wed Apr 25 13:02:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgksm-0001XT-GF; Wed, 25 Apr 2007 13:02:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgksl-0001XO-4d for asrg@ietf.org; Wed, 25 Apr 2007 13:02:19 -0400 Received: from mx.freeshell.org ([192.94.73.18] helo=sdf.lonestar.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgksj-0000Bm-I8 for asrg@ietf.org; Wed, 25 Apr 2007 13:02:19 -0400 Received: from sdf.lonestar.org (IDENT:samble@vinland.freeshell.org [192.94.73.6]) by sdf.lonestar.org (8.13.5.20060308/8.13.8) with ESMTP id l3PH29JW003919 for ; Wed, 25 Apr 2007 17:02:09 GMT Received: (from samble@localhost) by sdf.lonestar.org (8.13.8/8.12.8/Submit) id l3PH297G022619; Wed, 25 Apr 2007 12:02:09 -0500 (CDT) Date: Wed, 25 Apr 2007 12:02:09 -0500 (CDT) From: sam bledsoe X-X-Sender: samble@vinland.freeshell.org To: asrg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Asrg] Spam profitability analysis and countermeasures X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: asrg-bounces@ietf.org Hello brave digital warriors, I submit for discussion an idea about combating spam. It is not wholly novel based on my findings, and I may fall in to the following 'You might be an anti-spam kook'[1] categories: spam-fighter-2 spammers-are-stupid-3 dont-get-no-respect-7 My work consists of a paper[2], the abstract of which is below, and a a collection of Python scripts[3]. There is also a C# implementation[4]. I realize this is a technical list, but it still seems an appropriate forum for this post. Happy flaming, Sam 1. ABSTRACT Almost all Internet and email users have experienced problems relating to spam. There is no doubt that it is a scourge, and many attempts have been made to fight the difficulties it imposes. Legislators have passed laws banning the practice, and measures such as greylisting and adaptive filtering have been effective at limiting its detrimental effects -- but decreasingly so. However this research takes a different view on the issue than the ones mentioned. The legislative approach seems incomplete because preservation of rights is not the central issue, although theft of service concerns are legal in nature. The technical approach is closer but misses a key point. Many of the problems that are a result of spam are technical in nature, but its cause is economic[4] (section 1, paragraph 1). A clear understanding of the spam phenomenon is crucial to fighting it. This research investigates the causes for spam and the factors that influence its continuing viability, as well as provides an implementation of a suitable countermeasure. The motivating reason for sending spam seems clear: monetary profit. Businesses are willing to pay marketers and look the other way, and mass email marketers are seeking only profit. The combination of conditions that are involved in profiting from abusing email systems in this way are less clear, but include very low cost to send, sender anonymity, large target market, and low user response rate. Note that technical considerations will not be ignored, but rather they provide the backdrop for dealing with this instance of crass profiteering. [1] http://www.rhyolite.com/anti-spam/you-might-be.html [2] http://mrmoe.net/~samble/spamthing/spam_profitability.txt - plaintext, not wrapped http://mrmoe.net/~samble/spamthing/spam_profitability-fmt.txt - plaintext, wrapped http://mrmoe.net/~samble/spamthing/spam_profitability.odt - OpenDocument Text [3] http://mrmoe.net/~samble/spamthing/src/ http://mrmoe.net/~samble/spamthing/ [4] http://randonom.com/~wladek/projects/spamthing.net/ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Apr 25 13:38:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HglRk-00068m-CB; Wed, 25 Apr 2007 13:38:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HglRj-00068Z-5n for asrg@ietf.org; Wed, 25 Apr 2007 13:38:27 -0400 Received: from trillian.net.astrum.ch ([213.144.132.251] helo=mail.leisi.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HglRh-0001AN-Ld for asrg@ietf.org; Wed, 25 Apr 2007 13:38:27 -0400 X-Spam-ASN: AS13030 213.144.128.0/19 X-Spam-Checker-Version: SpamAssassin 3.2.0-pre2-r512851 (2007-02-28) on trillian.net.astrum.ch X-Spam-Hammy: 0.000-+--sha1, 0.000-+--SHA1, 0.000-+--SIGNATURE, 0.000-+--HX-Enigmail-Version:0.94.2.0, 0.000-+--H*u:Mnenhy X-Spam-Status: No, hits=-88.0 required=4.5 test=AWL=14.582,BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-100, SPF_PASS=-0.001 autolearn=ham AWL=14.6 DNSWL=YES X-Spam-Spammy: 1.000-9--noticeable, 0.998-1--magnitude, 0.997-1--fraudulent, 0.997-1--operators, 0.993-1--innocent X-Spam-Level: X-Spam-DNSWL: YES RCVD_IN_DNSWL_HI X-Spam-Report: * -100 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high * trust * [213.144.132.250 listed in list.dnswl.org] * -0.0 SPF_PASS SPF: sender matches SPF record * -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] * 15 AWL AWL: From: address is in the auto white-list Received: from [192.168.1.21] (marvin.net.astrum.ch [213.144.132.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.leisi.net (Postfix) with ESMTP id 324513CAF0 for ; Wed, 25 Apr 2007 19:38:20 +0200 (CEST) Message-ID: <462F920B.1010105@leisi.net> Date: Wed, 25 Apr 2007 19:38:19 +0200 From: Matthias Leisi User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.10) Gecko/20060911 SUSE/1.5.0.10-1.1 Thunderbird/1.5.0.10 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] Spam profitability analysis and countermeasures References: In-Reply-To: X-Enigmail-Version: 0.94.2.0 OpenPGP: id=7CA2FE89 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: asrg-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 sam bledsoe wrote: > [Quoting from] > http://mrmoe.net/~samble/spamthing/spam_profitability.odt | One click per spam [per spam recipient] could destabilize spammers' | business models, upsetting their clients' cash flow, and leading to an | end to the economic viability of the practice. You assume that spammers use their own bandwidth for web hosting, which is rare -- quite (most?) often, they use someone else's infrastructure: * Hosting on a botnet, so all that would be achieved is saturating an (not-so) innocent bystander (zombie owner and it's ISP), but not causing direct economic disincentive to the spammer. * Hosting on an abused website. Again, this will negatively affect the rightful owner and it's ISP. * Hosting on a server rented by the spammer - often with fake credit card data or other fraudulent tactics. This will at best impact the ISP, but not cause cost for the spammer. Any kind of (d)DoS attack on a spamvertized host may decrease that particular hosts' lifespan, because it is detected and cleaned sooner than it would be without DoS. This may drive up a spammer's cost slightly because he has to rotate the landing hosts faster, but given the wide availability of such spam-hosting resources, I would not expect a noticeable effect. Further, given that botnets can be in the tens of thousands of members, it's easy for the botnet operator to initiate counter-attacks if the number, "click-rate" and aggregated bandwidth of spam-recipients does not outnumber the botnet operator's resources by an order of a magnitude. - -- Matthias -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGL5ILxbHw2nyi/okRAh96AJ4iW8tsQtCe5QBckLJjo6PNBzIyqACfeerq MMcBcGYUuUMB4d7Fqty4054= =9R0P -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Apr 25 13:55:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgli2-00011y-Qc; Wed, 25 Apr 2007 13:55:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgli1-00011t-RW for asrg@ietf.org; Wed, 25 Apr 2007 13:55:17 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgli0-00065H-IJ for asrg@ietf.org; Wed, 25 Apr 2007 13:55:17 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l3PHtEJ11857 for ; Wed, 25 Apr 2007 17:55:14 GMT Received: from [47.129.150.3] ([47.129.150.3] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Apr 2007 13:55:08 -0400 Message-ID: <462F95F9.5050702@nortel.com> Date: Wed, 25 Apr 2007 13:55:05 -0400 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] Spam profitability analysis and countermeasures References: <462F920B.1010105@leisi.net> In-Reply-To: <462F920B.1010105@leisi.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Apr 2007 17:55:08.0874 (UTC) FILETIME=[DD1082A0:01C78762] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: asrg-bounces@ietf.org Matthias Leisi wrote: > Further, given that botnets can be in the tens of thousands of members, > it's easy for the botnet operator to initiate counter-attacks if the > number, "click-rate" and aggregated bandwidth of spam-recipients does > not outnumber the botnet operator's resources by an order of a magnitude. We must _not_ forget the Blue Frog lesson: http://en.wikipedia.org/wiki/Blue_Frog _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Apr 25 15:24:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgn6g-0008Lq-4N; Wed, 25 Apr 2007 15:24:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgn6e-0008Lk-9R for asrg@ietf.org; Wed, 25 Apr 2007 15:24:48 -0400 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgn6c-0006RE-UG for asrg@ietf.org; Wed, 25 Apr 2007 15:24:48 -0400 Received: from [168.61.10.150] (SJC-Office-DHCP-150.Mail-Abuse.ORG [168.61.10.150]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l3PJOjm9010057 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 25 Apr 2007 12:24:46 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <462F95F9.5050702@nortel.com> References: <462F920B.1010105@leisi.net> <462F95F9.5050702@nortel.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5B3A3797-20FE-4582-8F82-528B3EB11C9B@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Spam profitability analysis and countermeasures Date: Wed, 25 Apr 2007 12:24:52 -0700 To: Anti-Spam Research Group - IRTF X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: asrg-bounces@ietf.org On Apr 25, 2007, at 10:55 AM, Chris Lewis wrote: > Matthias Leisi wrote: > >> Further, given that botnets can be in the tens of thousands of >> members, it's easy for the botnet operator to initiate counter- >> attacks if the number, "click-rate" and aggregated bandwidth of >> spam-recipients does not outnumber the botnet operator's resources >> by an order of a magnitude. > > We must _not_ forget the Blue Frog lesson: > > http://en.wikipedia.org/wiki/Blue_Frog Latency in any counter-measure makes reacting to individual events futile. As such, counter-measures must be broad and lasting. A fly's perceptions and reactions are much faster, making them difficult to swat. With their low persistence, by the time a swatter can even be raised, they have already taken light. Warnings only work accompanied with negative ramifications. A "No Solicitation" announcement can be made with rfc3865. IP addresses might be exploited, so a safe identity for which to apply long lasting ramifications would be the ASN at the very moment of the offense. This indicates which ASNs monitor their outbound traffic, checks SMTP error rates generated by outbound clients, disables port 25 for residential access points, and responds to complaints of abuse. Alas, industry attempts to punish or restrict individual users, where various providers continue to profit from revenues generated by abuse and abuse counter measures. Holding the ASN accountable is the _only_ practical means to affect the profit motive driving abuse. Many of the schemes that attempt to identity individuals actually enables devastating DDoS exploits. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Apr 25 15:49:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgnUH-0004eK-Ae; Wed, 25 Apr 2007 15:49:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgnUF-0004dp-7y for asrg@ietf.org; Wed, 25 Apr 2007 15:49:12 -0400 Received: from mx.freeshell.org ([192.94.73.18] helo=sdf.lonestar.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgnUD-0001YV-Di for asrg@ietf.org; Wed, 25 Apr 2007 15:49:11 -0400 Received: from sdf.lonestar.org (IDENT:samble@vinland.freeshell.org [192.94.73.6]) by sdf.lonestar.org (8.13.5.20060308/8.13.8) with ESMTP id l3PJn01P017589 for ; Wed, 25 Apr 2007 19:49:00 GMT Received: (from samble@localhost) by sdf.lonestar.org (8.13.8/8.12.8/Submit) id l3PJn0YL029650; Wed, 25 Apr 2007 14:49:00 -0500 (CDT) Date: Wed, 25 Apr 2007 14:49:00 -0500 (CDT) From: sam bledsoe X-X-Sender: samble@vinland.freeshell.org To: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] Spam profitability analysis and countermeasures In-Reply-To: <5B3A3797-20FE-4582-8F82-528B3EB11C9B@mail-abuse.org> Message-ID: References: <462F920B.1010105@leisi.net> <462F95F9.5050702@nortel.com> <5B3A3797-20FE-4582-8F82-528B3EB11C9B@mail-abuse.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: asrg-bounces@ietf.org On Wed, 25 Apr 2007, Douglas Otis wrote: > Date: Wed, 25 Apr 2007 12:24:52 -0700 > From: Douglas Otis > Reply-To: Anti-Spam Research Group - IRTF > To: Anti-Spam Research Group - IRTF > Subject: Re: [Asrg] Spam profitability analysis and countermeasures > > > On Apr 25, 2007, at 10:55 AM, Chris Lewis wrote: > >> Matthias Leisi wrote: >> >>> Further, given that botnets can be in the tens of thousands of members, >>> it's easy for the botnet operator to initiate counter-attacks if the >>> number, "click-rate" and aggregated bandwidth of spam-recipients does not >>> outnumber the botnet operator's resources by an order of a magnitude. >> >> We must _not_ forget the Blue Frog lesson: >> >> http://en.wikipedia.org/wiki/Blue_Frog Hi Matthias and others. Part of the concept is that spammers aren't neccessarily the root of the problem. I see it as analogous to the illegal immigrant worker problem - the immigrants are just trying to make a buck, and there are very many of them operating outside the bounds of the law, which makes enforcing laws over them extremely difficult. They immigrate because companies will pay them. Crack down on the guys writing the paychecks, and people won't show up trying to get paid. This is by no means an indisputable or even well established principle, but it makes sense to me. Based on that idea though, the "legitimate" companies who employ spammers should be brought in to check. I have not forgotten about Blue Frog, either. I don't want to manage a database of users, or contact ISPs to tell on people, or any of that. With users themselves running the countermeasure software, there is no centralized point of retaliation. > > Latency in any counter-measure makes reacting to individual events futile. > As such, counter-measures must be broad and lasting. A fly's perceptions and > reactions are much faster, making them difficult to swat. With their low > persistence, by the time a swatter can even be raised, they have already > taken light. Warnings only work accompanied with negative ramifications. A > "No Solicitation" announcement can be made with rfc3865. IP addresses might > be exploited, so a safe identity for which to apply long lasting > ramifications would be the ASN at the very moment of the offense. > > This indicates which ASNs monitor their outbound traffic, checks SMTP error > rates generated by outbound clients, disables port 25 for residential access > points, and responds to complaints of abuse. Alas, industry attempts to > punish or restrict individual users, where various providers continue to > profit from revenues generated by abuse and abuse counter measures. Holding > the ASN accountable is the _only_ practical means to affect the profit motive > driving abuse. Many of the schemes that attempt to identity individuals > actually enables devastating DDoS exploits. > > -Doug Sorry Doug, while I can parse what you say I cannot understand your point. > > > _______________________________________________ > Asrg mailing list > Asrg@ietf.org > https://www1.ietf.org/mailman/listinfo/asrg > samble@sdf.lonestar.org SDF Public Access UNIX System - http://sdf.lonestar.org _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Apr 25 17:06:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgogc-0006gG-Oh; Wed, 25 Apr 2007 17:06:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgogb-0006g8-Fz for asrg@ietf.org; Wed, 25 Apr 2007 17:06:01 -0400 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgoga-0006Z0-4h for asrg@ietf.org; Wed, 25 Apr 2007 17:06:01 -0400 Received: from [168.61.10.150] (SJC-Office-DHCP-150.Mail-Abuse.ORG [168.61.10.150]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l3PL5xuF030184 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 25 Apr 2007 14:05:59 -0700 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <462F920B.1010105@leisi.net> <462F95F9.5050702@nortel.com> <5B3A3797-20FE-4582-8F82-528B3EB11C9B@mail-abuse.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <84C9F25E-C324-4167-B1F0-3473061B3046@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Spam profitability analysis and countermeasures Date: Wed, 25 Apr 2007 14:06:06 -0700 To: Anti-Spam Research Group - IRTF X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: asrg-bounces@ietf.org On Apr 25, 2007, at 12:49 PM, sam bledsoe wrote: > On Wed, 25 Apr 2007, Douglas Otis wrote: >> Latency in any counter-measure makes reacting to individual events >> futile. As such, counter-measures must be broad and lasting. A >> fly's perceptions and reactions are much faster, making them >> difficult to swat. With their low persistence, by the time a >> swatter can even be raised, they have already taken light. >> Warnings only work accompanied with negative ramifications. A "No >> Solicitation" announcement can be made with rfc3865. IP addresses >> might be exploited, so a safe identity for which to apply long >> lasting ramifications would be the ASN at the very moment of the >> offense. >> >> This indicates which ASNs monitor their outbound traffic, checks >> SMTP error rates generated by outbound clients, disables port 25 >> for residential access points, and responds to complaints of >> abuse. Alas, industry attempts to punish or restrict individual >> users, where various providers continue to profit from revenues >> generated by abuse and abuse counter measures. Holding the ASN >> accountable is the _only_ practical means to affect the profit >> motive driving abuse. Many of the schemes that attempt to >> identity individuals actually enables devastating DDoS exploits. > > Sorry Doug, while I can parse what you say I cannot understand your > point. For example, don't expect a peer-to-peer version of the blue-frog approach to be either effective or safe. 1) The modus operandi is changing in response to ongoing "take downs". 2) Anyone can be a member of a peer-to-peer network. So disabuse any expectation of a) confidentiality, b) information reliability as it may be corrupted, or c) effectiveness as information will be stale. These weaknesses means the scheme will be highly dangerous. Fines imposed upon ASN owners who permit abuse to continue would be more effective and safer. AUPs will become more restrictive, and a response to abuse more immediate, when ignoring abuse directly effects the bottom-line. Tossing out abusive high bandwidth customers or adding expensive router provisions become more easily justified. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Apr 29 21:50:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiL10-0004Cg-FH; Sun, 29 Apr 2007 21:49:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiL0x-00048w-Sa for asrg@ietf.org; Sun, 29 Apr 2007 21:49:19 -0400 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiL0j-0008A4-Nd for asrg@ietf.org; Sun, 29 Apr 2007 21:49:11 -0400 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HiL0c-00033L-Vx for asrg@ietf.org; Mon, 30 Apr 2007 03:48:59 +0200 Received: from du-001-227.access.de.clara.net ([212.82.227.227]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Apr 2007 03:48:58 +0200 Received: from nobody by du-001-227.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 30 Apr 2007 03:48:58 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Mon, 30 Apr 2007 03:31:17 +0200 Organization: Lines: 47 Message-ID: <463546E5.2049.1of4@xyzzy.claranet.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: du-001-227.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 2.4 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Asrg] FYI: 2821bis and 2822upd X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: asrg-bounces@ietf.org Hi, there's a fresh attempt in the IETF to promote RFC 2821 (SMTP) and 2822 (mail) to "draft standards", the second step in the IETF standards process. Full standard (STD) is the third step, at the moment RFC 821 belongs to STD 10, and RFC 822 is STD 11. The actual drafts 2821bis-03 and 2822upd-01 are available at and The drafts are discussed on the traditional ietf-smtp and ietf-822 lists shown on : and The lists are also available on GMaNe, see If you for some reason or another feel that something with mail is not as it should be, and if you're willing to review these drafts, then now would be a good time to chime in. Example for folks interested in Sender-ID, the 2822upd draft still says that Resent-* header fields MUST NOT be used in "other such automatic actions on messages". Example for folks interested in misdirected bounces, the 2821bis draft still favours accept instead of reject, and mandates to send non-delivery reports to the originator as indicated in the reverse path. Example for folks interested in NetNews, the 2822upd draft still allows control characters (NO-WS-CTL) and unnecessary "quoted- pairs" (backslash escapes) in Message-IDs. Example for folks interested in SPF, the 2821bis draft still does not clearly admit that the RFC 821 alias-forwarding to 3rd parties was designed for an SMTP with "return routes", and whatever that was, it was killed by RFC 1123 together with the "source routes". So there are some "minor" points in these drafts which should be relevant for some readers of this list. Please help to get it right this time. Don't let them get away with "it's as it is, and we can't change it because a promotion to 'draft standard' doesn't allow serious fixes." RFC 3986 and RFC 3629 are examples where serious fixes worked, and if all else fails a fixed new "proposed standard" is better than any broken by design "draft standard". Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg