From asrg-bounces@ietf.org Thu Feb 01 02:16:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCW7A-0003fx-GJ; Thu, 01 Feb 2007 02:12:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCW78-0003eJ-Sj for asrg@ietf.org; Thu, 01 Feb 2007 02:12:10 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCW5e-00036K-DH for asrg@ietf.org; Thu, 01 Feb 2007 02:10:39 -0500 Received: from [192.168.2.40] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l117Abxx032281 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 31 Jan 2007 23:10:37 -0800 Subject: Re: [Asrg] How about we do something about spam? From: Douglas Otis To: Barry Shein In-Reply-To: <17857.22096.267216.638009@world.std.com> References: <17856.62286.468183.171586@world.std.com> <20070131215235.9381.qmail@simone.iecc.com> <17857.9992.58654.806936@world.std.com> <3B6ADE70-B1CF-459F-AFA5-49B3B2A60F50@mail-abuse.org> <17857.22096.267216.638009@world.std.com> Content-Type: text/plain Date: Wed, 31 Jan 2007 23:10:37 -0800 Message-Id: <1170313837.3123.186.camel@dcore.sonic.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, 2007-01-31 at 21:54 -0500, Barry Shein wrote: > You seem to prefer a technological solution, possibly with some new > legislation making "spam" illegal. I have no particular problem with > that, in spirit. DKIM, together with autonomous associations, can be used to prevent spoofing and allow opportunistic security in a fashion similar to SSH. The recipients should first confirm sources using an out-of-band technique, such as a picture or pass-phrase included within an introduction. DKIM can identify the entity transmitting the messages when used properly. Unfortunately, providers do not want to identify themselves. Prompt relief from abuse requires that transmitters identify themselves, and NOT their customers. Their customers can offer domain associations as authorization when needed. > But I do believe that a more immediate goal of urging law enforcement > (et al) to better enforce existing laws (&c) regarding the creation > and operation of, e.g., zombie botnets is valuable without in any way > detracting from other efforts stated. Why focus on Bot-Nets? Microsoft's PNRP protocol coupled with Teredo (RFC4380) named after teredo navalis, Latin name of a common species of shipworm, provides a loosely coupled matrix of computers exchanging complex addresses designed to penetrate compatible firewalls and NATs. Every game manufacturer will have kids playing interactively within structures closely resembling malware created Bot-Nets now sans reference to DNS. There will not be much luck trying to police this type of traffic. > Put another way, we don't board up all our windows and let burglars > run free. We try to make burglary dangerous for burglars. There are many gated communities that control access, where individuals are not free to test every door or window without being noticed. The CAN-SPAM law prevents a practical means to limit access, or to call authorities when such control is challenged. There is no sure means to know when a message is safe, but limiting the number of attempts offers significant protection in itself. The best strategy is to limit the spread of infection. This means people MUST NOT be allowed to bulk send unsolicited messages. The CAN-SPAM act allows spammers a simple strategy of switching to a different product line after 10 days, once someone has requested them to stop. You can't even expect spammers to offer their physical address when most messages from Fortune 1000 or even Senators ignore this requirement. They expect you to follow a link. Even attempting to OPT-OUT often attracts additional traffic. Providers must control access, block abusers, and be held accountable when they fail to do so. When someone spams, they must be blocked. Sending volumes of unsolicited messages is rather easy to detect, where miscreants can be blocked quickly. When this traffic is from customers using compromised systems, then each problematic customer's outbound messages must be blocked. Of course, the next concern might be malware placed in websites, even things like Wikipedia might contain malware. There must be efforts made to ensure blogs are properly defanged as well. There are laws against spyware, but knowing when information has been compromised is extremely difficult. Establish an agency that handles SSNs changed into something that looks like a credit card number. Allow each company to ask for a stable reference of the individual that is unique to the requestor. Allow a citizen to report that they suspect their information may have been compromised, and have it changed at no charge. Any requestor asking for a stable reference of a invalidated number should attract attention. The agency would need to provide services that allow companies to exchange their stable references, but never the original numbers. Sharing original numbers are too likely to be detected as having been invalidated and leading to an investigation. There might even be significant fines related to requests with invalidated numbers. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 01 02:19:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCWE0-0006Nm-ID; Thu, 01 Feb 2007 02:19:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCWDz-0006Nc-00 for asrg@ietf.org; Thu, 01 Feb 2007 02:19:15 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCWDw-0005z4-LV for asrg@ietf.org; Thu, 01 Feb 2007 02:19:14 -0500 Received: from [192.168.2.40] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l117JARJ017515 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 31 Jan 2007 23:19:10 -0800 Subject: Re: [Asrg] How about we do something about spam? From: Douglas Otis To: gep2@terabites.com In-Reply-To: References: <20070131160521.GG21178@mail> <1170264881.3123.89.camel@dcore.sonic.net> Content-Type: text/plain Date: Wed, 31 Jan 2007 23:19:10 -0800 Message-Id: <1170314350.3123.195.camel@dcore.sonic.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: asrg@ietf.org, bzs@world.std.com, David Maxwell X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, 2007-01-31 at 11:54 -0600, gep2@terabites.com wrote: > > I certainly agree that a major part of the solution is to > not process dangerous E-mail arriving from > unfamiliar/untrusted senders. > > That said, we need to provide a default rule which allows > receiving "safe" mail from new, first-time senders > (long-lost friends, Customer Service requests from > customers, etc), subject to SpamAssassin-like > determination that it doesn't "look like" spam. Make spam illegal and hold providers accountable instead. > As for DKIM, I don't have strong opinions one way or the > other at this point, but continue to remind folks that > sometimes people send legitimate E-mail messages from > inhabitual locations. This could be a cruise ship > Internet cafe, an Internet E-mail sending room in a post > office in Beijing, or a "business center" in a hotel. I > think it's far more important WHAT IS IN the E-mail than > where it "came" from. For new or introductory messages, there must be some out-of-band confirmation obtained before the source of the message is trusted. DKIM coupled with an association scheme can offer enough flexibility where most won't find this difficult. This can be used in a fashion similar to SSH. The current DKIM base draft unfortunately does not permit this mode of use. I think this was done to extort keys from customers. : ( -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 01 11:22:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCeeJ-00083L-OC; Thu, 01 Feb 2007 11:18:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCeeI-00083G-Dj for asrg@ietf.org; Thu, 01 Feb 2007 11:18:58 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCeeC-0000lT-PZ for asrg@ietf.org; Thu, 01 Feb 2007 11:18:58 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HCee3-0006sG-Pd for asrg@ietf.org; Thu, 01 Feb 2007 17:18:43 +0100 Received: from d253196.dialin.hansenet.de ([80.171.253.196]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Feb 2007 17:18:43 +0100 Received: from nobody by d253196.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 01 Feb 2007 17:18:43 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Thu, 01 Feb 2007 17:08:36 +0100 Organization: Lines: 65 Message-ID: <45C21084.3CF2@xyzzy.claranet.de> References: <17856.62286.468183.171586@world.std.com> <20070131215235.9381.qmail@simone.iecc.com> <17857.9992.58654.806936@world.std.com> <3B6ADE70-B1CF-459F-AFA5-49B3B2A60F50@mail-abuse.org> 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: d253196.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Subject: [Asrg] Re: How about we do something about spam? X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org > This would place accountability onto the provider. The efforts > behind SPF and DKIM are aimed at passing blame to a hapless customer. Nonsense. SPF FAIL protects HELO identities and envelope-sender addresses, SPF PASS guarantees that bounces cannot hit innocent bystanders. And DKIM allows signers to take the responsibility for a mail transmission independent of SMTP. > Thousand of domains might share an SPF authorized server which > is likely to have only a few IP addresses. Therefore only a few IPs are permitted to use the domain as HELO or in an envelope-sender. Implementing RFC 4409 ("submit") and 2554bis ("auth") on that shared server is an obvious next step, SPF explicitly recommends this. FWIW, not much yet, publishers of sender policies can even state (= claim) that their server(s) don't allow "cross-user-forgery". Won't help them if they manage to become a part of a botnet, but as expected SPF and/or DKIM are no FUSSP. > The identity limitations with DKIM ensures providers will also > control their customer's private keys. Who sent and signed the > message is _designed_ to remain a mystery. [I-D.ietf-dkim-base-07 chapter 6.3] | If the message is signed on behalf of any address other than | that in the From: header field, the mail system SHOULD take | pains to ensure that the actual signing identity is clear to | the reader. > There should be laws against the use of highly danger > authorization schemes, such as SPF/Sender-ID. Omigod - how about a law against those dangerous MX records ? Without MX records the spammers won't know where to they could send their crap. Highly dangerous, this MX. Without it we'd have RFC 821 source routing again, SPF would be unnecessary. :-| > Enforcement must make any spam illegal AND hold providers > accountable. To ensure enforcement, allow anyone damaged to > seek legal relief. Great, Can-Spam, legal enforcement, and RFC 3865 to the rescue. Is that a new all-time low in the history of the IRTF-ASRG ? > The volume and lack of solicitation provides key differences. > The lack of solicitation allows for rather easy methods of > enforcement. RFC 3865 is already published, check it out. > OPT-OUT is a dangerous, impractical, and an immoral excuse. At least we agree on something. >> It takes a zombie botnet. > There are many other techniques. Open proxies and open relays. If that's all it's not "many". F _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 01 12:15:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCfWb-0002RZ-1h; Thu, 01 Feb 2007 12:15:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCfWZ-0002RM-L4 for asrg@ietf.org; Thu, 01 Feb 2007 12:15:03 -0500 Received: from mpls-qmqp-01.inet.qwest.net ([63.231.195.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCfWU-0007PT-Br for asrg@ietf.org; Thu, 01 Feb 2007 12:15:03 -0500 Received: from mpls-pop-01.inet.qwest.net (mpls-pop-01.inet.qwest.net [63.231.195.1]) by mpls-qmqp-01.inet.qwest.net (Postfix) with QMQP id ED4631A9C17 for ; Thu, 1 Feb 2007 17:14:54 +0000 (UTC) Received: from 71-33-174-211.hlrn.qwest.net (HELO ?192.168.0.3?) (71.33.174.211) by mpls-pop-01.inet.qwest.net with SMTP; 1 Feb 2007 17:14:54 -0000 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <17857.22096.267216.638009@world.std.com> References: <17856.62286.468183.171586@world.std.com> <20070131215235.9381.qmail@simone.iecc.com> <17857.9992.58654.806936@world.std.com> <3B6ADE70-B1CF-459F-AFA5-49B3B2A60F50@mail-abuse.org> <17857.22096.267216.638009@world.std.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5FE8F77A-7758-4562-9DEF-8BD8EE04EAA8@qwest.net> Content-Transfer-Encoding: 7bit From: Dan Oetting Subject: Re: [Asrg] How about we do something about spam? Date: Thu, 1 Feb 2007 10:14:52 -0700 To: Anti Spam Research Group 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 List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Jan 31, 2007, at 7:54 PM, Barry Shein wrote: > But I do believe that a more immediate goal of urging law enforcement > (et al) to better enforce existing laws (&c) regarding the creation > and operation of, e.g., zombie botnets is valuable without in any way > detracting from other efforts stated. Technical solutions can coexist with law enforcement options. I just stumbled on the site running Project Honeypot that is analyzing data from web scrapers and spambots to help put together the case evidence for spammers harvesting addresses from web pages which is also a violation of existing laws (according to the site). I was pushing for distributed collection of spamtrap data about 2.5 years ago. The primary goal was (is) to develop a fast blocklist to shutdown the spambots that were just emerging. I was told this idea was FUSSP directly by the inventor of the term and that it would never work. In my research last night I also found that in part is doing precisely what I was proposing. I've grown to mistrust anti-spam expert and tend to think their primary goal is to enhance their worth by insuring the fight against spam continues. After looking at some of my own posts from 2.5 years ago I could see how far we've progressed. Back then I was able to manually process all the spam that hit my inbox (with no pre-filtering by the ISP). Today I can barley scan the titles of the spam I get and I know there is lost legitimate mail due to the upstream filters. I'm still pushing my idea because I still believe it can help reverse the current trend of more and more spam every year. Even though there is apparently a commercial implementation, the goals of [2.3.5. Avoid central administration] and [2.3.6. Don't impose commercial administration] can be better realized in a public system. I'm also not one that blindly sticks to an idea. I am more of a scientist and would be just as interested in how the idea fails as in seeing it succeed. But I'll demand to see data before changing my mind. -- Dan Oetting _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 01 12:28:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCfhW-0007dT-5T; Thu, 01 Feb 2007 12:26:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCfhU-0007dN-QQ for asrg@ietf.org; Thu, 01 Feb 2007 12:26:20 -0500 Received: from adsl-216-102-208-14.dsl.snfc21.pacbell.net ([216.102.208.14] helo=mtcc14.mtcc.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCfhT-0002BM-32 for asrg@ietf.org; Thu, 01 Feb 2007 12:26:20 -0500 DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7593; t=1170350770; x=1171214770; c=relaxed/simple; s=alltheway.kirkwood; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Asrg]=20How=20about=20we=20do=20someth ing=20about=20spam? |Sender:=20 |To:=20Douglas=20Otis=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=X64FrLQWgd6JYPqpyCjiy9AF5Uoo30t4+lrqMGxI1iI=; b=ACdqXA6MsjhC/YyZXEkBP/G/53UhlFumLWDyblD9VOlE6ulbl9nPei79Sd 8SHDfKtxW0DCCM0ZQbQx5v+MPKw/gIw/xV4sXh5q337Cv44lj9usIxdjTMAY 7bCr5jPgRbkn21U+DWABnmYlcYifzFqLyT1z6sSIIPppttaxXV4DA=; Received: from [127.0.0.1] (mtcc14.mtcc.com [127.0.0.1]) (authenticated bits=0) by mtcc14.mtcc.com (8.13.8/8.13.8) with ESMTP id l11HQ961031716; Thu, 1 Feb 2007 09:26:10 -0800 Message-ID: <45C222B1.3070802@mtcc.com> Date: Thu, 01 Feb 2007 09:26:09 -0800 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.9) Gecko/20061219 Fedora/1.5.0.9-2.fc6 pango-text Thunderbird/1.5.0.9 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: Douglas Otis Subject: Re: [Asrg] How about we do something about spam? References: <17856.62286.468183.171586@world.std.com> <20070131215235.9381.qmail@simone.iecc.com> <17857.9992.58654.806936@world.std.com> <3B6ADE70-B1CF-459F-AFA5-49B3B2A60F50@mail-abuse.org> In-Reply-To: <3B6ADE70-B1CF-459F-AFA5-49B3B2A60F50@mail-abuse.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: mtcc14.mtcc.com; header.From=mike@mtcc.com; dkim=pass ( sig from mtcc.com/alltheway.kirkwood verified; ); X-Spam-Status: No, 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba Cc: asrg@ietf.org, Barry Shein X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org I don't even know where to start about the mischaracterization of dkim here, so I won't. Suffice it to say that Doug's take on dkim is nu^H^Hpretty idiosyncratic. Douglas Otis wrote: > > On Jan 31, 2007, at 3:32 PM, Barry Shein wrote: > >> >> On January 31, 2007 at 21:52 asrg@johnlevine.com (John Levine) wrote: >>>> Some confirmation from respected sources might help. >>> >>> Well, at this moment, I am sitting in a session at MAAWG where the >>> FTC's lead spam investigator is telling us about his investigation >>> process and he and ISP reps are going over issues like whether they >>> notify customers when they get a subpoena. Also present are the >>> Canadian competition bureau, analogous to the FTC, and I believe I >>> saw some guys from DOJ. >> >> Well that's of course great but some publicized thrust and focus from >> the IETF couldn't hurt the thinking of the policymakers who have to >> actually allocate budgets and other priorities. >> >> Is there any disagreement that if we could just snap our fingers and >> make the zombie botnets disappear (or 90% disappear) that "spam" (and >> related) wouldn't immediately have all the emotional punch of >> "off-topic posting", some odd msg you get and delete? >> >> Put another way, zombie botnets are the enabling technology of spam >> (phishing, etc.) > > Put another way, legalizing spam enables high infection rates needed > to support the existence of Bot-Nets. Malware content within an email > message and websites (required to OPT-OUT) provide bad actors ample > opportunity to leverage exploits that exist in email or website > browsers. The completely absurd stipulations of OPT-OUT is satisfied > by a link to a web site of all things. CAN-SPAM mandates victims > expose themselves to two very likely modes of infection. Browsers > continuously have new and complex features added, where many flaws > exist and can be exploited. Bulk messaging with embedded links > provides a highly dangerous infection vector. > >> Easier said than done I realize, but it's inherently illegal to >> create and operate zombie botnets, and I don't mean just in the US, >> most anywhere on the planet. > > By making spam illegal, the act of transmitting a high volume of > unsolicited messages would then clearly serve as evidence of crime. > This would place accountability onto the provider. The efforts behind > SPF and DKIM are aimed at passing blame to a hapless customer. > Thousand of domains might share an SPF authorized server which is > likely to have only a few IP addresses. The identity limitations with > DKIM ensures providers will also control their customer's private > keys. Who sent and signed the message is _designed_ to remain a > mystery. Some mode of accountability. > >> The law enforcement and regulatory agencies of the planet have a lot >> more resources they can muster than we ever could. > > Providers must acknowledge they are primarily responsible for much of > the mess that exists. Providers must be held accountable when any > high volume of unsolicited messaging emerges from their networks. > >> Even if we could come up with the FUSSP we'd still probably face >> enormous hurdles of deployment. > > The first step would be to make spam illegal. Illegal for individuals > to send, and for providers to ignore. After all, providers control > access. Allow those damaged to seek relief. Making spam illegal > would make networks many orders of magnitude safer. > >> Vigorous legal pursuit wouldn't preclude technical efforts in >> parallel unless of course spam just disappears as a result. > > Twice the technological effort is attempting to pass blame to some > likely hapless customer. Make a law that requires providers sign all > public messages with their own keys. There should even be laws that > prohibit signing with a customer's key. Customers can reference > specific keys used on their behalf instead. There should be laws > against the use of highly danger authorization schemes, such as > SPF/Sender-ID. Poisoning or destroying DNS is easily accomplish with > this loathsome technology. A technology also aimed at side stepping > accountability. > >> There is no other way we know of to send out on the order of one >> billion emails per day for a cost which even approaches the expected >> value of those messages and would so successfully evade already >> commonplace blocking and filtering methods. >> >> Does anyone disagree with that? > > Enforcement must make any spam illegal AND hold providers > accountable. To ensure enforcement, allow anyone damaged to seek > legal relief. > >> Can't we say that in some very public way? Does anyone doubt that's >> true? > > There are few providers that want to consider their accountability as > part of the cost of doing business. No one can afford to clean up the > mess being made. Just as was done to control the abuse of fax > machines, the same must be done with respect to email. At least with > a fax machine, programs were not in jeopardy, just resources. > >> Sometimes I think the problem otherwise insightful technical people >> have in thinking about spam is wrapping their heads around what it >> takes to send out O(billion) messages a day from a handful of base >> sources and we keep retreating to imagining spam as being much like >> sending this message other than the content and intent. >> >> It's not. > > Content or intent do not need to be considered. The volume and lack > of solicitation provides key differences. The lack of solicitation > allows for rather easy methods of enforcement. One grows weary > logging trespasses that can only be considered privately as bad. > Those making these private assessments remain exposed to civil > proceeding as a result. Spam must be illegal to stop it. There are > very few legitimate businesses using spam to promote their products, > and yet the US Congress has legalized spam. OPT-OUT is a dangerous, > impractical, and an immoral excuse. > >> It's as if I could make this message appear in 100 million mailboxes >> in the next few hours, despite many efforts to the contrary. > > The number of messages does not matter. The number of unsolicited > messages does. > >> I couldn't. You couldn't. > > Not true. There are some rather large mailing lists where such > volumes are possible. Lists enjoying a large number of subscribers > are also typically well managed. > >> It takes a zombie botnet. > > There are many other techniques. Malware provides many avenues to > exploit networks. Make spam illegal to slow the spread of malware. > >> There are other issues, but I'm focusing on this one as the most >> egregious and, I hope, easiest to agree on in terms of contribution >> to the problem and legal/moral unambiguity. > > You seem to have the cart before the horse. In addition to spam, > perhaps other rules could be considered regarding system scanning. > This again would require that providers take action to block access. > Vista comes equipped with what is likely an ideal command and control > system for controlling Bot armies. The system must protect from the > spread of infection. Prevention is worth a pound of cure. > > -Doug > > > > _______________________________________________ > Asrg mailing list > Asrg@ietf.org > https://www1.ietf.org/mailman/listinfo/asrg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 01 13:40:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgoC-0008Dl-Dl; Thu, 01 Feb 2007 13:37:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCgoB-0008B8-8q for asrg@ietf.org; Thu, 01 Feb 2007 13:37:19 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCgo7-0000Vl-Lc for asrg@ietf.org; Thu, 01 Feb 2007 13:37:19 -0500 Received: from [192.168.0.102] (kd-web.117.133.209.in-addr.arpa [209.133.117.100] (may be forged)) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l11IbCrt005159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Feb 2007 10:37:14 -0800 In-Reply-To: <45C21084.3CF2@xyzzy.claranet.de> References: <17856.62286.468183.171586@world.std.com> <20070131215235.9381.qmail@simone.iecc.com> <17857.9992.58654.806936@world.std.com> <3B6ADE70-B1CF-459F-AFA5-49B3B2A60F50@mail-abuse.org> <45C21084.3CF2@xyzzy.claranet.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: How about we do something about spam? Date: Thu, 1 Feb 2007 10:37:22 -0800 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 1, 2007, at 8:08 AM, Frank Ellermann wrote: >> This would place accountability onto the provider. The efforts >> behind SPF and DKIM are aimed at passing blame to a hapless customer. > > Nonsense. SPF FAIL protects HELO identities and envelope-sender > addresses, SPF PASS guarantees that bounces cannot hit innocent > bystanders. And DKIM allows signers to take the responsibility for > a mail transmission independent of SMTP. SPF does not protect the HELO as checking is optional and can be that of any domain, as compared to domains within the message. SPF does not prevent bounces sent to those that did not send the message without also reducing email's delivery integrity. Few SPF records have settings that operate in this mode as a result. DKIM is not about signer's taking responsibility in most cases. The DKIM signature can be replayed. Who signed and who replayed? Who is accountable for stopping abuse? >> Thousand of domains might share an SPF authorized server which is >> likely to have only a few IP addresses. > > Therefore only a few IPs are permitted to use the domain as HELO or > in an envelope-sender. Implementing RFC 4409 ("submit") and > 2554bis ("auth") on that shared server is an obvious next step, SPF > explicitly recommends this. FWIW, not much yet, publishers of > sender policies can even state (= claim) that their server(s) don't > allow "cross-user-forgery". An unlimited number of domains are allowed to use _any_ IP address to authorize their bounce address or any other originating domain within a message. > Won't help them if they manage to become a part of a botnet, but as > expected SPF and/or DKIM are no FUSSP. Expecting millions of recipients to pass the SMTP client IP address (perhaps as seen in the Received header), and various email domains to a script process that might then request hundreds of DNS transactions for each email-address being checked is a good way to poison DNS, cripple DNS, or take down any network. >> The identity limitations with DKIM ensures providers will also >> control their customer's private keys. Who sent and signed the >> message is _designed_ to remain a mystery. > > [I-D.ietf-dkim-base-07 chapter 6.3] > | If the message is signed on behalf of any address other than > | that in the From: header field, the mail system SHOULD take > | pains to ensure that the actual signing identity is clear to > | the reader. How can a reader be expected to recognize the From header field in the first place? This assumes there is method that allows a mailing system to take "pains" of ensuring what the reader can visually recognize something. Messages where the From/sign-domain do not match will be given a "special" folder? This restriction will eventually require email-address domain owners to supply providers with their private keys. In the end, look-alike and cousin domains will simply become more credible, and bad actors will have fun breaking into MTAs holding thousands of keys. >> There should be laws against the use of highly danger >> authorization schemes, such as SPF/Sender-ID. > > Omigod - how about a law against those dangerous MX records ? > Without MX records the spammers won't know where to they could send > their crap. Highly dangerous, this MX. Without it we'd have RFC > 821 source routing again, SPF would be unnecessary. :-| SPF expects recipients to not only check an MX record, but to resolve the addresses for each target within an MX record and to do this ten times over. Instead, verify the host of the SMTP client, and then check for domain associations using a single DNS transaction. This would be far safer in comparison. The difference is rather stark. The transmitting entity would be required to identify themselves first. If there is a problem, they might be asked to make it stop. >> Enforcement must make any spam illegal AND hold providers >> accountable. To ensure enforcement, allow anyone damaged to seek >> legal relief. > > Great, Can-Spam, legal enforcement, and RFC 3865 to the rescue. Is > that a new all-time low in the history of the IRTF-ASRG ? Spam must be made illegal. There should be no need for RFC3865, or for legal provisions that say it is okay to spam provided your message has a link that allows opting-out of this line of products. >> The volume and lack of solicitation provides key differences. The >> lack of solicitation allows for rather easy methods of enforcement. > > RFC 3865 is already published, check it out. And so? There should be an international agreement that bulk sending of unsolicited messages is illegal. Any network that permits this activity should be blocked. Spam would end very quickly, and infections rates would decline. This would required that providers and law makers take action however. RFCs should be aimed at identifying who is _transmitting_ the messages first. If a bank wants users to know which providers are sending their email, there can be a simple, small, and safe DNS transaction to indicate their authorization of the provider. Providers should be prevented from using the keys of their customers. The same strategy could be used based upon HELO verification as well, but of course, a signature would be much stronger. >> OPT-OUT is a dangerous, impractical, and an immoral excuse. > > At least we agree on something. > >>> It takes a zombie botnet. >> >> There are many other techniques. > > Open proxies and open relays. If that's all it's not "many". Unfortunately there are many more. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 01 17:56:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkoF-0006uU-6b; Thu, 01 Feb 2007 17:53:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCkoD-0006fl-KF for asrg@ietf.org; Thu, 01 Feb 2007 17:53:37 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCko9-0003iw-8y for asrg@ietf.org; Thu, 01 Feb 2007 17:53:37 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-218.Mail-Abuse.ORG [168.61.10.218]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l11MrWD3013581 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Feb 2007 14:53:32 -0800 In-Reply-To: <45C222B1.3070802@mtcc.com> References: <17856.62286.468183.171586@world.std.com> <20070131215235.9381.qmail@simone.iecc.com> <17857.9992.58654.806936@world.std.com> <3B6ADE70-B1CF-459F-AFA5-49B3B2A60F50@mail-abuse.org> <45C222B1.3070802@mtcc.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2D4A5CF9-5189-44E4-B23F-5C2BF25FC189@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] How about we do something about spam? Date: Thu, 1 Feb 2007 14:53:30 -0800 To: Michael Thomas X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 1, 2007, at 9:26 AM, Michael Thomas wrote: > I don't even know where to start about the mischaracterization of > dkim here, so I won't. Suffice it to say that Doug's take on dkim > is pretty idiosyncratic. When it comes to providers transmitting public messages and identifying themselves directly, this always seem to result in a different take. http://www.spartacus.schoolnet.co.uk/USAnast3.jpg Unless the entity transmitting the public message can be confirmed by the signature, it offers little value from the perspective of enforcement or of abating abuse. When there are many signatures added to a message, which signature is related to the entity transmitting the message, and how can that signature be located? Is it your view providers should obtain their customer's DKIM keys to sign on their behalf? Is it your view that the From email-address header matching with the signing domain is something safely communicated to the recipient? How does this deal with the common use of display names, look-alikes, or cousin domains? How will this deal with EAI and multiple addresses within the From header? False positive detection of phishing attempts can be prevented when the phished entity has authorized the signature. The basis of trust can be anything, where there is no need for the From domain to match the signing-domain. It is important for the signature to indicate on who's behalf it was added. DKIM lacks this essential feature however. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 08 16:27:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFGid-0000th-2O; Thu, 08 Feb 2007 16:22:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFGic-0000tY-21 for asrg@ietf.org; Thu, 08 Feb 2007 16:22:14 -0500 Received: from exchange.habeas.com ([64.78.21.106]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFGiX-00007b-Vg for asrg@ietf.org; Thu, 08 Feb 2007 16:22:14 -0500 Accreditor: Habeas X-Habeas-SWE-1: winter into spring X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-9: mark in spam to http://www.habeas.com/report/. X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2826 Importance: normal Priority: normal Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Feb 2007 13:22:01 -0800 Message-ID: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNSBL BCP v.2.0 Thread-Index: AcdLxywF4VlScakIRH6FHBjXV+q/vg== From: "Nick Nicholas" To: "Anti Spam Research Group" X-Spam-Score: 1.2 (+) X-Scan-Signature: 9361ae25efd9cff62e36f70ef966350e Subject: [Asrg] DNSBL BCP v.2.0 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Greetings: With much help from the authors as well as the ASRG chair and Dave Crocker, I have finally completed the revisions to the DNSBL BCP. A copy is beneath my .sig so that you may make your comments inline if desired. I tried to include as many comments as possible from the discussion of the previous draft, but the authors and the editor deemed it was necessary to decline to use some of the suggestions. Flame away! I'm wearing my Nomex suit. :-) Regards, Nick -- =20 Nick Nicholas Knowledge Engineer Habeas Inc. 650-694-3320 nick@habeas.com ------------------- Internet Draft Yakov Shafranovich (Editor) Expiration: August 2007 SolidMatrix Technologies Network Working Group Nick Nicholas (Editor) Habeas=20 Matt Sergeant MessageLabs Chris Lewis Nortel Networks February 2007 Guidelines for Management of DNS-Based Reputation Systems for Email draft-irtf-asrg-bcp-blacklists-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2007). All Rights Reserved. Abstract =20 The rise of spam and other anti-social behavior on the Internet has led to the creation of shared blacklists and whitelists of of IP addresses or domains. This memo discusses guidelines for management of public DNS blacklists. =20 The document will seek BCP status. Comments and discussion of this document should be addressed to the asrg@ietf.org mailing list. =20 =20 Table of Contents Abstract 1. Introduction 1.1 DNS-Based Reputation Systems 1.2 Guidance for DNSBL Users 1.3 Terminology 2. Background. 2.1. Transparency 2.1.2. Listing/Delisting Criteria SHOULD Be Easily Available. 2.1.3. An Audit Trail SHOULD Be Maintained. 2.2. Listings and Removals 2.2.1. Listings SHOULD Be Temporary. 2.2.2. A Direct Non-Public Way to Request Removal SHOULD Be Available. 2.2.3. Removals SHOULD Be Prompt. 2.2.4. Criteria for Listing and Delisting SHOULD Be Similar. 2.2.5. Removals SHOULD Be Possible in Absence of List Maintainer. 3. Operational Issues 3.1. Inactively Maintained Lists SHOULD Cease Operations. =20 3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion. 3.3. Content of DNSBL Zone File SHOULD Be Limited. 3.4. Special and Reserved IP Addresses MAY Be Used. 3.5. Use of Collateral Damage MUST Be Disclosed. 3.6. Special Considerations for Blacklists Listing Insecure Hosts. 3.6.1. MUST NOT Scan Without Provocation. 3.6.2. Re-scan Periods SHOULD Be Reasonable. 4. Security Considerations 5. Informative References 6. Author(s) Addresses. 7. Acknowledgements. 8. Full Copyright Statement. =20 1. Introduction. 1.1. DNS-Based Reputation Systems Due to the rising amount of spam and other forms of network abuse on the Internet, many community members and companies began to create and maintain DNS-based reputation systems ("DNSBL") of IP=20 addresses and domains identified as problem sources of email. These lists also have been known as blocklists and blacklists. These lists are used for filtering email. DNSBLs are either public or private. A public DNSBL makes its data available to any party seeking information from the list, but a private DNSBL is used=20 solely by an organization for its own use and the data is not made=20 available publicly. The first publicly available DNSBL using the Domain Name System (DNS) for distributing reputation data about email senders emerged in 1997, shortly after spam became a problem for network operators and email administrators. This pioneer DNSBL focused on identifying known=20 spam sources situated at static IP addresses. Due to the broad=20 adoption of this DNSBL, it had a devastating impact on static spam=20 sources. Consequently, abusers found other methods for distributing=20 their spam such as relaying messages through unsecured email servers=20 or flawed formmail scripts on web pages. Additional DNSBLs were=20 developed by others in order to address these changing tactics, and=20 today more than 700 DNSBLs are in operation. =20 Existing DNSBLs vary greatly in their policy, usage and and level=20 of maintenance. These guidelines try to lay out a set of best=20 practices for running a DNSBL in an open manner with the hope that=20 they will facilitate better management of DNSBLs, and provide better=20 information for prospective users in selecting which DNSBLs to use. These DNSBLs vary widely in integrity, strategy, methodology and=20 stability. While listing criteria can sometimes be quite=20 controversial, this document deliberately does not discuss the=20 rightness or wrongness of any criteria. We assert that DNSBL=20 operators are free to choose whatever listing criteria they wish,=20 as long as they are clear to their users what those criteria are. The DNSBL user has the responsibility to ensure that the listing=20 criteria and other aspects of a DNSBL meets its needs. This document is also intended to provide guidance to DNSBL administrators so that they may be able to identify what features users would be interested in seeing as part of a high-quality, well- managed DNSBL, e.g., a clear listing and delisting policy to which the DNSBL administrator adheres strictly. This document is intended=20 to be normative rather than prescriptive: it seeks to characterize=20 the features of a well-managed DNSBL rather than setting out rules=20 for how DNSBLs should be operated. 1.2. Guidance for DNSBL Users When choosing to adopt a DNSBL, an administrator should keep the following questions in mind: 1. What is the intended use of the list? 2. Does the list have a web site? 3. Are the list's policies stated on the web site? 4. Are the policies stated clearly and understandably? 5. Are web pages for removal requirements accessible and=20 functioning properly? 6. How long has the list been in operation? 7. What are the demographics and quantity of the list's user base? 8. Are comparative evaluations of the list available? 9. What do your peers or members of the Internet community say about the list. =20 It is the responsibility of the system administrators who adopt one=20 or more DNSBLs to evaluate, understand, and make a determination of which DNSBLs are appropriate for the sites they administer. If a system or network administrator allows a third party to make=20 blocking decisions for its network, then the administrator MUST=20 understand the policies and practices of those third parties=20 because responsibility for blocking decisions remain ultimately=20 with the administrator. A DNSBL does not prevent anyone from=20 receiving email or any other Internet service. A DNSBL *user*=20 prevents service delivery using the DNSBL as a tool for doing so. DNSBL administrators are merely expressing an opinion through the publication of a DNSBL, and it is their absolute right to do so free of legal encumbrance, and in violation of this BCP. However, it is through abiding by the guidelines set forth in this BCP that the administrators of a DNSBL may gain the trust of their users. These guidelines address public DNSBLs only and do not apply to privately operated DNSBLs. 1.3. Terminology. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. =20 2. Background. The Anti Spam Research Group (ASRG) was chartered to address the spam problem. The ASRG charter includes: "codification of best current practices in spam management" =20 This note falls within that category by listing guidelines for management of public DNSBLs. This document will seek BCP status. NOTE: This document is a product of the Anti-Spam Research Group (ASRG) of the IRTF. As per section 3 of [RFC 2014], IRTF groups do not require consensus to publish documents. Therefore readers should be aware that this document does not necessarily represent the consensus of the entire ASRG. =09 NOTE: This document is intended to evolve, based on comments from the Anti-Spam Research Group (ASRG) mailing list. It is certain that the current draft is incomplete and entirely possible that it is inaccurate. Hence, comments are eagerly sought, preferably in the form of suggested text changes, and preferably on the ASRG mailing list, at . 2.1. Transparency. A DNSBL SHOULD carefully describe the criteria which are the cause for adding, and the criteria for removing an IP address or domain=20 name on the list. Such listing and delisting criteria SHOULD be=20 presented in a clear and readable manner easily accessible to the=20 public through a mechanism such as the DNSBL's web site. A DNSBL=20 MUST abide by its stated listing and delisting criteria. Entries=20 that do not meet the published criteria MUST NOT be added to the DNSBL. =20 In other words, be direct and honest and clear about the listing=20 criteria, and make certain that only entries meeting the published criteria are added to the list. For example, some DNSBL operators have been known to include spite listings in the lists they administer. There is nothing inherently wrong with this practice so long as it is clearly disclosed. For example, a DNSBL described as listing open relays only MUST NOT include IP addresses for any other reason. This transparency principle does not require DNSBL administrators to disclose the precise algorithms and data involved in a listing. Availability of documentation concerning a DNSBL SHOULD NOT be dependent on the continued operation of DNS for the DNSBL zone file. In other words, if the DNSBL documentation is located at=20 http://example.com/dnsbl/, the documentation web site SHOULD remain available even if the DNSBL zone file is not available. See also=20 Section 3.2 2.1.2. Listing/Delisting Criteria SHOULD Be Easily Available. =20 Listing and delisting criteria for DNSBLs SHOULD be easily available and SHOULD be located in a place clearly marked in its own section of the web site affiliated with the DNSBL. =20 DNSBLs often publish their listing criteria along with additional technical information about using the blacklist. This=20 additional technical information can confuse end users, so a=20 separate page or section on its own SHOULD be dedicated to=20 detailing why a specific entry appears in the DNSBL. 2.1.3. An Audit Trail SHOULD Be Maintained. A DNSBL SHOULD maintain an audit trail for all listings and SHOULD make it publicly available in an easy to find location, preferably on the DNSBL's web site. Please note that making audit trail data public does not entail revealing all information in the DNSBL administrator's possession relating to the listing; e.g., a DNSBL administrator MAY make the audit trail data selectively accessible in such a way that spam trap addresses are not disclosed. 2.2 Listings and Removals 2.2.1. Listings SHOULD Be Temporary. With the exception of DNSBLs that that are based on data that does not change, such as those include the IP addresses associated with=20 a specific country or geographic region, all listings SHOULD be=20 temporary so that an entry will time out at some point in the=20 future. For more aggressive spammers (e.g., those operating their=20 own ISP) the temporary period MAY be as much as six (6) months. =20 However, longer periods SHOULD NOT be used since it is possible=20 that an IP address or domain can change hands, possibly being=20 allocated to a non-abusive user. =20 Note that all listings being temporary does not mean that some listings will not remain after the initial timeout period. If the=20 DNSBL administrator determines that the conditions for listing=20 still exists, then the timer for determining timeouts MAY be=20 renewed. 2.2.2. A Direct Non-Public Way to Request Removal SHOULD Be Available. Discussions about whether a DNSBL should remove an entry MAY=20 include activity in a public forum. Methods for processing=20 removal requests through private, direct exchanges, such as=20 person-to-person email or a combination of web page requests=20 and email responses, SHOULD be available. As a minimum, the=20 DNSBL SHOULD have a web page that has a removal request function=20 (separate from the page describing listing criteria as per=20 section 2.1.2). The DNSBL SHOULD also make available an email=20 address in order to handle issues other than blocking issues. =20 The DNSBL administrator MUST NOT use the list in question in such a way that removal requests would be blocked, and, moreover, SHOULD make unfiltered mailboxes available in order to allow=20 affected users to submit their requests. In some cases it is=20 impractical not to filter email to role accounts due to the amount=20 of spam those mailboxes receive. If filtering should be necessary in such circumstances, filtering methods with virtually non- existent false positive rates SHOULD be chosen. 2.2.3. Removals SHOULD Be Prompt. Requests for removal SHOULD be honored without question. Although this approach allows people to submit a request and have any listed IP address removed immediately, it does not prevent=20 the DNSBL administrator from re-listing the IP address at a=20 later time (for example: subject to seeing more spam, or=20 re-checking the IP address security). A re-listing MAY result in=20 a longer timeout until the listing expires before it is eligible=20 for removal. Bounded exponential backoff is a good choice for=20 listing timeout. Assuming the above is not possible and no listing reasons remain, removal at anyone's request SHOULD be prompt. Removal requests SHOULD be acted upon within a period of 24 hours, and SHOULD be handled within three (3) days. Most DNSBLs can effectively use a "no questions asked" removal=20 policy because by their very nature they will redetect or relist=20 problems almost immediately. They can mitigate more organized=20 attempts to "game" the system by elementary checking and rate- limiting procedures, increasing lockout periods, rescans etc. Furthermore, a few IP addresses more or less do not make a significant difference in the overall effectiveness of a DNSBL. Moreover, a "no questions asked" removal policy provides the=20 huge benefit of a swift reaction to incorrect listings. As an example, one popular DNSBL implementing a "no questions=20 asked" removal policy also performs rate-limiting and malicious=20 removal detection. Another important consideration supporting a "no questions asked" self-removal policy is that it forestalls conflicts between DNSBL administrators and organizations whose IP addresses have been listed. Such a policy also can be an effective deterrent to legal problems. 2.2.4 Criteria for Listing and Delisting SHOULD Be Similar The criteria for being removed from a DNSBL SHOULD bear a reasonable relationship to the factors which were the cause of the addition to the DNSBL. If a listed entity fulfills all published requirements for removal from a DNSBL, then the DNSBL administrator SHOULD NOT=20 impose any additional obstacles to remove a given entry from the DNSBL. There SHOULD NOT be any extra rules for de-listing other than the ones listed in the published listing criteria. =20 In addition, it is RECOMMENDED that all listings SHOULD be temporary=20 as described in section 2.2.1. For temporary listings, it is not=20 necessary to correct the causes of the listing in order to be removed from the DNSBL. 2.2.5. Removals SHOULD Be Possible in Absence of List Administrator. Removals SHOULD be possible in the absence of the list administrator. If removals cannot be automated (e.g., via robot re-testing) then the DNSBL SHOULD have multiple administrators so that a removal=20 request can be processed if the principal list administrator is=20 on vacation or otherwise unavailable. 3. Operational Issues. 3.1. Inactively Maintained Lists SHOULD Cease Operations If a DNSBL is no longer actively maintained, it SHOULD cease operations in accordance with the principles set forth in section 3.2. 3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion. When a DNSBL ceases operations and is taken out of circulation, it MUST do so in a graceful manner so that it does not create=20 excessive DNS queries or list the entire Internet. =20 The recommended approach is to put the DNSBL in its own second level domain, and then point the DNS NS records for that second=20 level domain to 127.255.255.255. The TTL for that record should be=20 set at the maximum allowed period of one week. 3.3. Content of DNSBL Zone File SHOULD Be Limited. The content of a DNSBL zone file SHOULD be limited to DNSBL entries and relevant control information such as the TTL for the entry,=20 explanatory TXT records, etc. By virtue of using domain names, a DNSBL is a hierarchy with a root anchored in the global Internet. The DNSBL "query root" SHOULD be below the registered domain, so=20 that the DNSBL information is not conflated with domain housekeeping=20 information (e.g., name server, MX or SPF records). By using this=20 approach, DNSBL queries would take the form of=20 ".dnsbl.example.com" rather than ".example.com". Further, this sub-tree should occupy its own zone. This approach=20 facilitates clear delineation of function as well as orderly DNSBL shutdown because the DNSBL nameserver records can be specified separately from the domain's principal nameservers. 3.4. Special and Reserved IP Addresses MAY Be Used. The DNSBL MAY list loopback, RFC 1918, LINK-LOCAL class D/E, and any other permanently reserved or special-use IP addresses. Such use MUST be disclosed in the documentation related to the DNSBL. Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8 to provide online indication of whether the DNSBL is operational. =20 In particular, most DNSBLs use a positive response for 127.0.0.2=20 for this. See reference [DNSBL-EMAIL] for additional information. 3.5. Use of Collateral Damage MUST Be Disclosed. Some DNSBLs have adopted a policy of using "collateral damage" as an intentional element of the list's operation. When collateral damage is applied, a DNSBL listing is expanded to include IP addresses under the control of a provider even though those IP addresses are not the source of abusive email. The theory is that customers=20 impacted by collateral damage will bring pressure upon the provider=20 to take action against the customer which is the cause of the original listing. Collateral damage as a DNSBL policy is highly controversial, and discussion of the appropriateness of this policy is beyond the scope of this document. However, if a DNSBL has policies and practices that include the imposition of collateral damage, such policies MUST be disclosed. 3.6. Considerations for DNSBLs Listing Insecure Hosts. Some DNSBLs list IP addresses of hosts that are insecure=20 in various ways (e.g. open relays, open proxies). The following recommendations for such DNSBLs may not be relevant to=20 regular DNSBLs. 3.6.1. MUST NOT scan without provocation. DNSBLs MUST NOT automatically probe for insecure systems without provocation. There is little agreement in the community as to whether or not such activity should be allowed, so this BCP adopts a more conservative policy. =20 Therefore, scanning MUST be be targeted, rather than broad-based,=20 with a given scan motivated by a specific reason to have concern about the IP address being scanned. Examples of such reasons=20 include delivery of a message to a spam trap address, receipt of=20 a user complaint, or periodic testing of an IP address that is=20 listed already. =20 3.6.2. Re-scan Periods SHOULD be Reasonable. If the DNSBL administrator re-scans a host in order to determine=20 whether the listing SHOULD timeout or not, the re-scan period=20 SHOULD be reasonable. Automated re-scans SHOULD NOT occur more often than once every 24 hours. 4. Security Considerations Like all DNS-based mechanisms, DNSBLs are subject to various=20 threats outlined in [RFC 3833]. =20 5. Informative References [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP9, RFC 2026, October 1996. [RFC 2014] Weintrib, A., Postel, J,; "IRTF Research Group Guidelines and Procedures", BCP 8, RFC 2014, October 1996 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 =20 [RFC 3833] Atkins, D. and Austein, R.; "Threat Analysis of the Domain Name System", RFC 3833, August 2004 [DNSBL-EMAIL] Levine, John; "DNS Based Blacklists and=20 Whitelists for E-Mail", draft-irtf-asrg-dnsbl-02, November 2005 6. Author(s) Addresses. Yakov Shafranovich (Editor) SolidMatrix Technologies, Inc. research@solidmatrix.com www.shaftek.org Nick Nicholas (Editor) Habeas, Inc. nick@habeas.com Chris Lewis Nortel Networks clewis@nortelnetworks.com Matt Sergeant MessageLabs, Inc. msergeant@messagelabs.com =20 =20 8. Acknowledgements. We would like to thank John R. Levine, Alan Murphy and Dave Crocker for their insightful comments.=20 Funding for the RFC Editor function is currently provided by the Internet Society. 9. Full Copyright Statement. Full Copyright Statement Copyright (C) The Internet Society (2007). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 08 19:34:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJgs-0007Bp-U7; Thu, 08 Feb 2007 19:32:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFJgs-0007Bi-D2 for asrg@ietf.org; Thu, 08 Feb 2007 19:32:38 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFJgn-0001Vt-Pu for asrg@ietf.org; Thu, 08 Feb 2007 19:32:38 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HFJgT-0002QP-1p for asrg@ietf.org; Fri, 09 Feb 2007 01:32:13 +0100 Received: from d255075.dialin.hansenet.de ([80.171.255.75]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Feb 2007 01:32:13 +0100 Received: from nobody by d255075.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Feb 2007 01:32:13 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Fri, 09 Feb 2007 01:27:15 +0100 Organization: Lines: 154 Message-ID: <45CBBFE3.E2@xyzzy.claranet.de> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> 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: d255075.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 03169bfe4792634a390035a01a6c6d2f Subject: [Asrg] Re: DNSBL BCP v.2.0 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Nick Nicholas wrote: > you may make your comments inline if desired Okay, you get it then in source order, from typo to whatever else I might see. > whitelists of of IP addresses or domains. This memo discusses s/of of/of/ > create and maintain DNS-based reputation systems ("DNSBL") of IP > addresses and domains identified as problem sources of email. These Some DNSBLs are in fact "DNS based lists" used for other purposes like Geo location. If you haven't done it later you could note that you're not talking about the general "DNSBL" concept. > These DNSBLs vary widely in integrity, strategy, methodology and s/These// They all vary widely. > 7. What are the demographics and quantity of the list's user base? How are admins supposed to evaluate this ? Sounds bogus for me. > 9. What do your peers or members of the Internet community say > about the list. They all say it's bad for various conflicting reasons, none of them related to any incident in the last five years. > If a system or network administrator allows a third party to make > blocking decisions for its network, then the administrator MUST > understand the policies and practices of those third parties > because responsibility for blocking decisions remain ultimately > with the administrator. Yes. And actually a list does NEVER make blocking decisions for a list user, because nobody is forced to use it. How about "uses the proposals of a third party to make blocking decisions". > These guidelines address public DNSBLs only and do not apply to > privately operated DNSBLs. s/do/may/ ? Some proposals should also make sense for private lists. > Therefore readers should be aware that this document > does not necessarily represent the consensus of the > entire ASRG. Is that necessary ? As a BCP it will have IETF consensus no matter what the ASRG situation might be. > public through a mechanism such as the DNSBL's web site. A DNSBL s/through a mechanism such as/on / No nonsense please, if it has no Web site it's anyway bogus. > Availability of documentation concerning a DNSBL SHOULD NOT be > dependent on the continued operation of DNS for the DNSBL zone file. > In other words, if the DNSBL documentation is located at > http://example.com/dnsbl/, the documentation web site SHOULD remain > available even if the DNSBL zone file is not available. I don't get this, if the list works like 2.0.0.127.example.net, then the accompanying Web site SHOULD be located at http://example.net Otherwise the list is bogus and SHOULD NOT be used. Of course it's fine if it has other URLs for its policy. > With the exception of DNSBLs that that are based on data that does > not change, such as those include the IP addresses associated with > a specific country or geographic region s/include/listing/ (?) > future. For more aggressive spammers (e.g., those operating their > own ISP) the temporary period MAY be as much as six (6) months. + own ISP) the temporary period could be considerably longer (e.g., + weeks) as stated in the listing policy. I don't get the idea of an arbitrary magic number "6 months". For a list with say bogon IPs it would be "as long as necessary", unlimited. You address this later, but IMO no fixed limit also here is clearer. > However, longer periods SHOULD NOT be used since it is possible > that an IP address or domain can change hands, possibly being > allocated to a non-abusive user. Add "unless it's the stated list policy to cause collateral damage for users getting their IPs from spam-supporting organizations." > re-checking the IP address security). A re-listing MAY result in > a longer timeout until the listing expires before it is eligible > for removal. Bounded exponential backoff is a good choice for > listing timeout. ACK, and that upper limit could be worse than six months. > 2.2.5. Removals SHOULD Be Possible in Absence of List Administrator. > Removals SHOULD be possible in the absence of the list administrator. Delete this line. > The recommended approach is to put the DNSBL in its own second > level domain, and then point the DNS NS records for that second > level domain to 127.255.255.255. The TTL for that record should be > set at the maximum allowed period of one week. Intersting, many DNS details are still a kind of mystery for me, users would then try to ask a name server at 127.255.255.255, and because that's a broadcast address on their own LAN they'd get an error, is that the idea ? Was that concept already tested anywhere ? > ".dnsbl.example.com" rather than ".example.com". That's what I meant above, http://dnsbl.example.com for the Web site, and other URLs for the case when the list is terminated. Ideally as redirection (moved permanently) to the more persistent URL. > The DNSBL MAY list loopback, RFC 1918, LINK-LOCAL class D/E, and > any other permanently reserved or special-use IP addresses. No, it MUST NOT abuse anything outside of 127.0.0.0/8, and it MUST NOT abuse 127.0.0.1 (using IPs to signal result codes is IMO abuse, please limit it as good as you can). > Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8 Indeed, and anything else is just wrong. > In particular, most DNSBLs use a positive response for 127.0.0.2 s/most/many/ and s/for/of/ You should also mention that lists SHOULD support 127.0.0.2 as "always listed" test entry, and 127.0.0.1 for the opposite (never listed), without ever returning 127.0.0.1 as a result. > for this. See reference [DNSBL-EMAIL] for additional information. Maybe that's not more needed if you explain the trivial concepts here. > [DNSBL-EMAIL] Levine, John; "DNS Based Blacklists and > Whitelists for E-Mail", draft-irtf-asrg-dnsbl-02, November 2005 If you keep RFC 1918 you've to list it as reference. RFC 2119 should be noted as normative - I think you've somehow lost the section with normative references. Nice draft, I like it, thanks, Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 08 21:22:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFLNw-0004Ef-7L; Thu, 08 Feb 2007 21:21:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFLNu-0004A0-Cy for asrg@ietf.org; Thu, 08 Feb 2007 21:21:10 -0500 Received: from chiark.greenend.org.uk ([193.201.200.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFLNp-0004vr-0H for asrg@ietf.org; Thu, 08 Feb 2007 21:21:10 -0500 Received: by chiark.greenend.org.uk (Debian Exim 3.36 #1) with local (return-path fanf@chiark.greenend.org.uk) id 1HFLNj-0003xF-00; Fri, 09 Feb 2007 02:20:59 +0000 To: Nick@habeas.com From: Tony Finch Subject: Re: [Asrg] DNSBL BCP v.2.0 In-Reply-To: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> Message-Id: Date: Fri, 09 Feb 2007 02:20:59 +0000 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org "Nick Nicholas" wrote: > The draft looks pretty sensible to me. >1.1. DNS-Based Reputation Systems > > DNSBLs are either public or > private. A public DNSBL makes its data available to any party > seeking information from the list, but a private DNSBL is used=20 > solely by an organization for its own use and the data is not made=20 > available publicly. There are also commercial DNSBLs which are public except that "any party" must be willing and able to pay. >2.2.1. Listings SHOULD Be Temporary. > > With the exception of DNSBLs that that are based on data that does > not change, such as those include the IP addresses associated with=20 > a specific country or geographic region, all listings SHOULD be=20 > temporary so that an entry will time out at some point in the=20 > future. IP addresses can move country or region - consider an international ISP. I don't think there are any certain unchanging attributes of IP addresses. >2.2.3. Removals SHOULD Be Prompt. > > Requests for removal SHOULD be honored without question. I think this requirement needs more hedging, since it depends on the DNSBL listing policy. For example, the requirement is not appropriate if the listing is based on who the address space has been allocated to, especially if the reason is that it has been allocated to criminals. In that case you expect to come into conflict with people who are listed. >3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion. > > When a DNSBL ceases operations and is taken out of circulation, > it MUST do so in a graceful manner so that it does not create=20 > excessive DNS queries or list the entire Internet. What do you mean by "excessive"? Is this a reference to insane DNS clients that generate more traffic when a DNS server goes away? >4. Security Considerations > > Like all DNS-based mechanisms, DNSBLs are subject to various=20 > threats outlined in [RFC 3833]. The recommendations for DNSBL users should be in this section. It's worth emphasizing that spam is a security problem and that DNSBLs are one of many ways to tackle it. DNSBLs usually relate to the SMTP client, which can have a limited relationship to the origin of the message if the client is relaying or forwarding. However RHSBLs exist as well, which have no guaranteed relationship to the client or the origin of the message, but can still be useful. Tony. -- f.a.n.finch http://dotat.at/ HUMBER: NORTHWESTERLY 5 OR 6. MODERATE OR ROUGH. WINTRY SHOWERS. GOOD. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 08 22:19:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFMGi-0006dO-RD; Thu, 08 Feb 2007 22:17:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFMGh-0006dH-Gt for asrg@ietf.org; Thu, 08 Feb 2007 22:17:47 -0500 Received: from mail48.messagelabs.com ([193.109.255.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HFMGf-00060p-TI for asrg@ietf.org; Thu, 08 Feb 2007 22:17:47 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-4.tower-48.messagelabs.com!1170991063!11031293!1 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 15505 invoked from network); 9 Feb 2007 03:17:43 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-4.tower-48.messagelabs.com with SMTP; 9 Feb 2007 03:17:43 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 03:17:43 +0000 Received: (qmail 4671 invoked from network); 9 Feb 2007 03:17:42 -0000 Received: from unknown (HELO ?10.100.0.124?) (10.100.0.124) by matt?dev.int.star.co.uk with SMTP; 9 Feb 2007 03:17:42 -0000 In-Reply-To: <45CBBFE3.E2@xyzzy.claranet.de> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8A308376-E1F0-4089-86C1-1FF200D1A548@messagelabs.com> Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Thu, 8 Feb 2007 22:17:28 -0500 To: Frank Ellermann X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Feb 2007 03:17:43.0609 (UTC) FILETIME=[DD0F5290:01C74BF8] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 8-Feb-07, at 7:27 PM, Frank Ellermann wrote: >> create and maintain DNS-based reputation systems ("DNSBL") of IP >> addresses and domains identified as problem sources of email. >> These > > Some DNSBLs are in fact "DNS based lists" used for other purposes > like Geo location. If you haven't done it later you could note > that you're not talking about the general "DNSBL" concept. I think we entirely cover that under 2.2.1. Please let us know if you think we don't. >> 7. What are the demographics and quantity of the list's user >> base? > > How are admins supposed to evaluate this ? Sounds bogus for me. Certainly easy to lie about, but a BCP doesn't cover lying. It could certainly be stated on the DNSBL's web page, or could be stated on a separate page on whichdnsbl.com (yes, I made that up, though it is available!). >> 9. What do your peers or members of the Internet community say >> about the list. > > They all say it's bad for various conflicting reasons, none of them > related to any incident in the last five years. :-) Not sure how we could encode that in a BCP. >> If a system or network administrator allows a third party to make >> blocking decisions for its network, then the administrator MUST >> understand the policies and practices of those third parties >> because responsibility for blocking decisions remain ultimately >> with the administrator. > > Yes. And actually a list does NEVER make blocking decisions for a > list user, because nobody is forced to use it. How about "uses the > proposals of a third party to make blocking decisions". Not sure which part you think is badly worded here. Please elaborate. >> These guidelines address public DNSBLs only and do not apply to >> privately operated DNSBLs. > > s/do/may/ ? Some proposals should also make sense for private lists. Possibly, but that is not the intention, and is not something we could BCP about IMHO. If a private entity wishes to follow these ideas then that's fantastic, but not what this BCP is about. >> Therefore readers should be aware that this document >> does not necessarily represent the consensus of the >> entire ASRG. > > Is that necessary ? As a BCP it will have IETF consensus no matter > what the ASRG situation might be. I think this is just draft preamble, required for discussion here. >> public through a mechanism such as the DNSBL's web site. A DNSBL > > s/through a mechanism such as/on / No nonsense please, if it has no > Web site it's anyway bogus. It's entirely conceivable that a DNSBL's public presence might be purely a yahoo-groups mailing list, or NANABL, or some-such. With FAQs and listing criteria regularly published to such locations. >> Availability of documentation concerning a DNSBL SHOULD NOT be >> dependent on the continued operation of DNS for the DNSBL zone >> file. >> In other words, if the DNSBL documentation is located at >> http://example.com/dnsbl/, the documentation web site SHOULD >> remain >> available even if the DNSBL zone file is not available. > > I don't get this, if the list works like 2.0.0.127.example.net, > then the > accompanying Web site SHOULD be located at http://example.net > Otherwise > the list is bogus and SHOULD NOT be used. Of course it's fine if > it has > other URLs for its policy. There are major problems with this. What if you decide to stop running the DNSBL? See section 3.2. I see no reason to remove this section. >> With the exception of DNSBLs that that are based on data that does >> not change, such as those include the IP addresses associated with >> a specific country or geographic region > > s/include/listing/ (?) Good catch. Thank you. >> future. For more aggressive spammers (e.g., those operating their >> own ISP) the temporary period MAY be as much as six (6) months. > > + own ISP) the temporary period could be considerably longer (e.g., > + weeks) as stated in the listing policy. > > I don't get the idea of an arbitrary magic number "6 months". For a > list with say bogon IPs it would be "as long as necessary", unlimited. > You address this later, but IMO no fixed limit also here is clearer. We've mulled over this a lot. Gone back and forth. In the end we said 6 months because if we put no limit on then it's no help - a DNSBL could just set the limit at 30 years. 6 months is reasonable for a long listing, and this is very well covered by the last point in this section - that a temporary listing can easily be extended by (for example) receiving more spam from this IP/range. >> However, longer periods SHOULD NOT be used since it is possible >> that an IP address or domain can change hands, possibly being >> allocated to a non-abusive user. > > Add "unless it's the stated list policy to cause collateral damage > for users getting their IPs from spam-supporting organizations." Even the organisation can change hands. See above. >> 2.2.5. Removals SHOULD Be Possible in Absence of List Administrator. > >> Removals SHOULD be possible in the absence of the list >> administrator. > > Delete this line. Yup. >> The recommended approach is to put the DNSBL in its own second >> level domain, and then point the DNS NS records for that second >> level domain to 127.255.255.255. The TTL for that record >> should be >> set at the maximum allowed period of one week. > > Intersting, many DNS details are still a kind of mystery for me, users > would then try to ask a name server at 127.255.255.255, and because > that's a broadcast address on their own LAN they'd get an error, is > that the idea ? Was that concept already tested anywhere ? It has been discussed both here and in many other places. >> ".dnsbl.example.com" rather than ".example.com". > > That's what I meant above, http://dnsbl.example.com for the Web site, > and other URLs for the case when the list is terminated. Ideally as > redirection (moved permanently) to the more persistent URL. Not sure what you mean here. Hopefully you're agreeing with what I said above. >> The DNSBL MAY list loopback, RFC 1918, LINK-LOCAL class D/E, and >> any other permanently reserved or special-use IP addresses. > > No, it MUST NOT abuse anything outside of 127.0.0.0/8, and it MUST NOT > abuse 127.0.0.1 (using IPs to signal result codes is IMO abuse, please > limit it as good as you can). list != result. We're not talking about the result IP here. Just what can be present in the DNSBL. >> Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8 > > Indeed, and anything else is just wrong. Possibly/probably yeah. But this BCP doesn't cover that. >> In particular, most DNSBLs use a positive response for 127.0.0.2 > > s/most/many/ and s/for/of/ I think "most" is fine. The second change is correct. > You should also mention that lists SHOULD > support 127.0.0.2 as "always listed" test entry, and 127.0.0.1 for the > opposite (never listed), without ever returning 127.0.0.1 as a result. Good point. We'll consider adding that. It's a good test for DNSBL validity. >> for this. See reference [DNSBL-EMAIL] for additional information. > > Maybe that's not more needed if you explain the trivial concepts here. > >> [DNSBL-EMAIL] Levine, John; "DNS Based Blacklists and >> Whitelists for E-Mail", draft-irtf-asrg-dnsbl-02, November 2005 > > If you keep RFC 1918 you've to list it as reference. RFC 2119 should > be noted as normative - I think you've somehow lost the section with > normative references. > > Nice draft, I like it, thanks, Thanks for your comments. Very useful. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 08 22:33:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFMUH-0006OZ-1M; Thu, 08 Feb 2007 22:31:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFMUF-0006OT-Sc for asrg@ietf.org; Thu, 08 Feb 2007 22:31:47 -0500 Received: from mail48.messagelabs.com ([193.109.255.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HFMUD-0002sb-Q8 for asrg@ietf.org; Thu, 08 Feb 2007 22:31:47 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-16.tower-48.messagelabs.com!1170991902!1754918!1 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 12976 invoked from network); 9 Feb 2007 03:31:42 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-16.tower-48.messagelabs.com with SMTP; 9 Feb 2007 03:31:42 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 03:31:42 +0000 Received: (qmail 4682 invoked from network); 9 Feb 2007 03:31:41 -0000 Received: from unknown (HELO ?10.100.0.124?) (10.100.0.124) by matt?dev.int.star.co.uk with SMTP; 9 Feb 2007 03:31:41 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] DNSBL BCP v.2.0 Date: Thu, 8 Feb 2007 22:31:27 -0500 To: Tony Finch X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Feb 2007 03:31:42.0213 (UTC) FILETIME=[D0E82350:01C74BFA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: asrg@ietf.org, Nick@habeas.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 8-Feb-07, at 9:20 PM, Tony Finch wrote: >> 1.1. DNS-Based Reputation Systems >> >> DNSBLs are either public or >> private. A public DNSBL makes its data available to any party >> seeking information from the list, but a private DNSBL is used=20 >> solely by an organization for its own use and the data is not >> made=20 >> available publicly. > > There are also commercial DNSBLs which are public except that "any > party" > must be willing and able to pay. I guess better wording might be: "but a private DNSBL restricts who has access to querying the list." >> 2.2.1. Listings SHOULD Be Temporary. >> >> With the exception of DNSBLs that that are based on data that does >> not change, such as those include the IP addresses associated >> with=20 >> a specific country or geographic region, all listings SHOULD be=20 >> temporary so that an entry will time out at some point in the=20 >> future. > > IP addresses can move country or region - consider an international > ISP. > I don't think there are any certain unchanging attributes of IP > addresses. I'd like to get more comment on that. Even international ISPs assign IP ranges within their country boundaries. >> 2.2.3. Removals SHOULD Be Prompt. >> >> Requests for removal SHOULD be honored without question. > > I think this requirement needs more hedging, since it depends on the > DNSBL listing policy. For example, the requirement is not appropriate > if the listing is based on who the address space has been allocated > to, > especially if the reason is that it has been allocated to criminals. > In that case you expect to come into conflict with people who are > listed. I strongly believe this is covered by the verbiage in this section. Should a criminal spammer find himself listed in the SBL (for example), he should be allowed to immediately request removal, and be granted that. As soon as he spams, he should be immediately relisted. And the limits on removals be made harder for him/her - see the second to last sentence in that first paragraph. The intention is to make innocent listings easy to remove, and criminal listings harder to remove. >> 3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion. >> >> When a DNSBL ceases operations and is taken out of circulation, >> it MUST do so in a graceful manner so that it does not create=20 >> excessive DNS queries or list the entire Internet. > > What do you mean by "excessive"? Is this a reference to insane DNS > clients that generate more traffic when a DNS server goes away? A typical example of shutting down a DNSBL would involve setting the TTL to a very high value, to limit the number of queries that result. >> 4. Security Considerations >> >> Like all DNS-based mechanisms, DNSBLs are subject to various=20 >> threats outlined in [RFC 3833]. > > The recommendations for DNSBL users should be in this section. > It's worth > emphasizing that spam is a security problem and that DNSBLs are one > of many ways to tackle it. DNSBLs usually relate to the SMTP client, > which can have a limited relationship to the origin of the message if > the client is relaying or forwarding. However RHSBLs exist as well, > which have no guaranteed relationship to the client or the origin of > the message, but can still be useful. I'm not sure we want to venture into that cesspool :-) But I'm willing to be persuaded otherwise. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 08 23:22:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFNFz-0003ok-Ab; Thu, 08 Feb 2007 23:21:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFNFx-0003oK-Uc for asrg@ietf.org; Thu, 08 Feb 2007 23:21:05 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFNFw-00006S-BD for asrg@ietf.org; Thu, 08 Feb 2007 23:21:05 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l194L0w7001230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 8 Feb 2007 20:21:01 -0800 In-Reply-To: <45CBBFE3.E2@xyzzy.claranet.de> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Thu, 8 Feb 2007 20:21:07 -0800 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 8, 2007, at 4:27 PM, Frank Ellermann wrote: > Nick Nicholas wrote: > >> 7. What are the demographics and quantity of the list's user >> base? > > How are admins supposed to evaluate this ? Sounds bogus for me. Perhaps whether a particular geographic area or type of enterprise is being served? >> 9. What do your peers or members of the Internet community say >> about the list. > > They all say it's bad for various conflicting reasons, none of them > related to any incident in the last five years. This is not something one should believe from the DNSRBL operator, so why make this a requirement? >> If a system or network administrator allows a third party to make >> blocking decisions for its network, then the administrator MUST >> understand the policies and practices of those third parties >> because responsibility for blocking decisions remain ultimately >> with the administrator. > > Yes. And actually a list does NEVER make blocking decisions for a > list user, because nobody is forced to use it. How about "uses the > proposals of a third party to make blocking decisions". It might even be better to only call this a blocklist or black-hole list, rather than a blacklist. These two areas provide grounds for meaningless legal tussles designed to waste money. Who is blocking is an important concept to clarify, as well that a block-list is not "blacklisting" as often defined in the law. >> These guidelines address public DNSBLs only and do not apply to >> privately operated DNSBLs. > > s/do/may/ ? Some proposals should also make sense for private lists. > >> public through a mechanism such as the DNSBL's web site. A DNSBL > > s/through a mechanism such as/on / No nonsense please, if it has no > Web site it's anyway bogus. It might become a required strategy to not rely upon web sites when they become DDoS targets. It seems contacts should be generalized to allow greater flexibility. >> Availability of documentation concerning a DNSBL SHOULD NOT be >> dependent on the continued operation of DNS for the DNSBL zone >> file. >> In other words, if the DNSBL documentation is located at >> http://example.com/dnsbl/, the documentation web site SHOULD >> remain >> available even if the DNSBL zone file is not available. > > I don't get this, if the list works like 2.0.0.127.example.net, > then the > accompanying Web site SHOULD be located at http://example.net > Otherwise > the list is bogus and SHOULD NOT be used. Of course it's fine if > it has > other URLs for its policy. There are TXT records that might accompany the IP address information that can provide contact information. Of course it would be rather painful should the contact information be an 800 phone number. >> future. For more aggressive spammers (e.g., those operating their >> own ISP) the temporary period MAY be as much as six (6) months. > > + own ISP) the temporary period could be considerably longer (e.g., > + weeks) as stated in the listing policy. > > I don't get the idea of an arbitrary magic number "6 months". For a > list with say bogon IPs it would be "as long as necessary", unlimited. > You address this later, but IMO no fixed limit also here is clearer. Frank is right. 6 months does not make much sense. Such a set interval can be rather easily gamed. A good operation will apply different criteria for various networks regarding such intervals as well as requests for delisting. The level of cooperation varies widely and this too affects these parameters. >> However, longer periods SHOULD NOT be used since it is possible >> that an IP address or domain can change hands, possibly being >> allocated to a non-abusive user. > > Add "unless it's the stated list policy to cause collateral damage > for users getting their IPs from spam-supporting organizations." How about: A listing should not extend beyond what the operator has determined to be beyond that offering a reasonable expectation that the address is likely to be under different administration. The operator may make exceptions based upon various factors, such as the past behavior of the network's management across the related addresses. >> re-checking the IP address security). A re-listing MAY result in >> a longer timeout until the listing expires before it is eligible >> for removal. Bounded exponential backoff is a good choice for >> listing timeout. > > ACK, and that upper limit could be worse than six months. > s/exponential backoff/exponentially extended periods/ >> 2.2.5. Removals SHOULD Be Possible in Absence of List Administrator. > >> Removals SHOULD be possible in the absence of the list >> administrator. > > Delete this line. Agreed. --- 3.3. Content of DNSBL Zone File SHOULD Be Limited. The DNSBL "query root" SHOULD be below the registered domain, so that the DNSBL information is not conflated with domain housekeeping information (e.g., name server, MX or SPF records). By using this approach, DNSBL queries would take the form of ".dnsbl.example.com" rather than ".example.com". --- This would be a problem only when zone transfers are used to distribute data. > That's what I meant above, http://dnsbl.example.com for the Web site, > and other URLs for the case when the list is terminated. Ideally as > redirection (moved permanently) to the more persistent URL. > >> The DNSBL MAY list loopback, RFC 1918, LINK-LOCAL class D/E, and >> any other permanently reserved or special-use IP addresses. > > No, it MUST NOT abuse anything outside of 127.0.0.0/8, and it MUST NOT > abuse 127.0.0.1 (using IPs to signal result codes is IMO abuse, please > limit it as good as you can). > >> Most DNSBLs follow a convention of entries for IPs in 127.0.0.0/8 > > Indeed, and anything else is just wrong. > >> In particular, most DNSBLs use a positive response for 127.0.0.2 > > s/most/many/ and s/for/of/ You should also mention that lists SHOULD > support 127.0.0.2 as "always listed" test entry, and 127.0.0.1 for the > opposite (never listed), without ever returning 127.0.0.1 as a result. Just exclude 127.0.0.1 to prevent exploits that might rely upon an unexpected self references from an otherwise trusted domain. --- There is nothing inherently wrong with this practice so long as it is clearly disclosed. For example, a DNSBL described as listing open relays only MUST NOT include IP addresses for any other reason. This transparency principle does not require DNSBL administrators to disclose the precise algorithms and data involved in a listing. --- s/as listing open relays/as only listing open relays/ --- 2.1.3. An Audit Trail SHOULD Be Maintained. A DNSBL SHOULD maintain an audit trail for all listings and SHOULD make it publicly available in an easy to find location, preferably on the DNSBL's web site. Please note that making audit trail data public does not entail revealing all information in the DNSBL administrator's possession relating to the listing; e.g., a DNSBL administrator MAY make the audit trail data selectively accessible in such a way that spam trap addresses are not disclosed. --- It is not possible to disclose _any_ email information without also disclosing where the message was obtained. It is simply impossible to fully redact a message to provide such an assurance of non-disclosure. How about: An operator should maintain an audit trail for their own private use. This information should _not_ be made public unless the entity making the request is considered trustworthy. In response to Tony: A list closed to only those that enter into a contract is not a "public" DNSRBL. A contract supersedes casual expectations expressed in this document. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 08 23:25:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFNKV-0006J1-7o; Thu, 08 Feb 2007 23:25:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFNKU-0006Iv-Ll for asrg@ietf.org; Thu, 08 Feb 2007 23:25:46 -0500 Received: from bigsky.scconsult.com ([66.73.230.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFNKR-00013n-QH for asrg@ietf.org; Thu, 08 Feb 2007 23:25:46 -0500 Received: from bigsky.scconsult.com (localhost [127.0.0.1]) by bigsky.scconsult.com (Postfix) with ESMTP id E9C5041258E for ; Thu, 8 Feb 2007 23:25:42 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> X-Message-Flag: Use of Microsoft mail clients is the primary cause of cracked systems. Please switch! Date: Thu, 8 Feb 2007 23:25:41 -0500 To: From: Bill Cole Subject: Re: [Asrg] DNSBL BCP v.2.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org At 1:22 PM -0800 2/8/07, Nick Nicholas wrote: >Greetings: > >With much help from the authors as well as the ASRG chair and Dave >Crocker, I have finally completed the revisions to the DNSBL BCP. A >copy is beneath my .sig so that you may make your comments inline if >desired. I tried to include as many comments as possible from the >discussion of the previous draft, but the authors and the editor deemed >it was necessary to decline to use some of the suggestions. > >Flame away! I'm wearing my Nomex suit. :-) Just a couple of minor quibbles: >3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion. > > When a DNSBL ceases operations and is taken out of circulation, > it MUST do so in a graceful manner so that it does not create > excessive DNS queries or list the entire Internet. > > The recommended approach is to put the DNSBL in its own second > level domain, and then point the DNS NS records for that second > level domain to 127.255.255.255. s/to/to a hostname that resolves to/ It's amazing how many people think that's it's OK to point an NS record at an IP address... > The TTL for that record should be > set at the maximum allowed period of one week. One week is NOT the maximum value for a TTL. One week is the top value that BIND will honor. TTL's can in theory be about 68 years (2147483647.) Alternate wording: The TTL field for the NS record and the A record it points to should be set to 604800 (one week) because larger values are not universally honored. -- Bill Cole bill@scconsult.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 08 23:46:30 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFNd2-0007yk-La; Thu, 08 Feb 2007 23:44:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFNd1-0007tS-A9 for asrg@ietf.org; Thu, 08 Feb 2007 23:44:55 -0500 Received: from mail50.messagelabs.com ([195.245.230.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HFNcz-00064C-SM for asrg@ietf.org; Thu, 08 Feb 2007 23:44:55 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-13.tower-50.messagelabs.com!1170996291!5284867!1 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 14207 invoked from network); 9 Feb 2007 04:44:51 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-13.tower-50.messagelabs.com with SMTP; 9 Feb 2007 04:44:51 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 04:44:51 +0000 Received: (qmail 5027 invoked from network); 9 Feb 2007 04:44:51 -0000 Received: from unknown (HELO ?10.100.0.124?) (10.100.0.124) by matt?dev.int.star.co.uk with SMTP; 9 Feb 2007 04:44:51 -0000 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Thu, 8 Feb 2007 23:44:36 -0500 To: Douglas Otis X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Feb 2007 04:44:51.0498 (UTC) FILETIME=[091FE0A0:01C74C05] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Frank Ellermann , asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 8-Feb-07, at 11:21 PM, Douglas Otis wrote: >> I don't get the idea of an arbitrary magic number "6 months". For a >> list with say bogon IPs it would be "as long as necessary", >> unlimited. >> You address this later, but IMO no fixed limit also here is clearer. > > Frank is right. 6 months does not make much sense. Please re-respond in light of my response to Frank here. > --- > 3.3. Content of DNSBL Zone File SHOULD Be Limited. > > The DNSBL "query root" SHOULD be below the registered domain, so > that the DNSBL information is not conflated with domain housekeeping > information (e.g., name server, MX or SPF records). By using this > approach, DNSBL queries would take the form of > ".dnsbl.example.com" rather than ".example.com". > --- > > This would be a problem only when zone transfers are used to > distribute > data. ... which covers all public DNSBLs, surely? Or at least those that have any hope of becoming popular (i.e. those that follow best practices). I don't see any reason you'd want to remove this section. > --- > There is nothing inherently wrong with this practice so long as it > is clearly disclosed. For example, a DNSBL described as listing open > relays only MUST NOT include IP addresses for any other reason. This > transparency principle does not require DNSBL administrators to > disclose the precise algorithms and data involved in a listing. > --- > > s/as listing open relays/as only listing open relays/ Good. > --- > 2.1.3. An Audit Trail SHOULD Be Maintained. > > A DNSBL SHOULD maintain an audit trail for all listings and SHOULD > make it publicly available in an easy to find location, preferably > on the DNSBL's web site. Please note that making audit trail data > public does not entail revealing all information in the DNSBL > administrator's possession relating to the listing; e.g., a DNSBL > administrator MAY make the audit trail data selectively accessible > in such a way that spam trap addresses are not disclosed. > --- > > It is not possible to disclose _any_ email information without also > disclosing where the message was obtained. It is simply impossible > to fully redact a message to provide such an assurance of > non-disclosure. Hence why this is a SHOULD not a MUST. It's a tricky line - compare for example the disclosure given by PSBL (almost full spamtrap hit contents) vs SBL. Both presumably maintain an internal audit trail, but one is public and one is private, but both are reasonably well run DNSBLs. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 07:51:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFV9h-0003L5-Mn; Fri, 09 Feb 2007 07:47:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFV9g-0003Kr-84 for asrg@ietf.org; Fri, 09 Feb 2007 07:47:08 -0500 Received: from mail1.nber.org ([66.251.72.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HFV9d-0002uf-Nq for asrg@ietf.org; Fri, 09 Feb 2007 07:47:08 -0500 Received: from mail1 (root@localhost) by mail1.nber.org (8.12.11.20060308/8.12.11) with SMTP id l19Ckt0E006745 for ; Fri, 9 Feb 2007 07:46:57 -0500 Received: from nber1.nber.org (nber1.nber.org [66.251.72.71]) by mail1.nber.org (8.12.11.20060308/8.12.11) with ESMTP id l19Cksch006716; Fri, 9 Feb 2007 07:46:54 -0500 Received: from nber1.nber.org (localhost [127.0.0.1]) by nber1.nber.org (8.12.10+Sun/8.12.10) with ESMTP id l19CkpnE025733; Fri, 9 Feb 2007 07:46:51 -0500 (EST) Received: from localhost (feenberg@localhost) by nber1.nber.org (8.12.10+Sun/8.12.9/Submit) with ESMTP id l19CkecH025730; Fri, 9 Feb 2007 07:46:40 -0500 (EST) X-Authentication-Warning: nber1.nber.org: feenberg owned process doing -bs Date: Fri, 9 Feb 2007 07:46:40 -0500 (EST) From: Daniel Feenberg To: Matt Sergeant Subject: Re: [Asrg] DNSBL BCP v.2.0 In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Tony Finch , asrg@ietf.org, Nick@habeas.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Thu, 8 Feb 2007, Matt Sergeant wrote: >>> >>> Requests for removal SHOULD be honored without question. >> >> I think this requirement needs more hedging, since it depends on the >> DNSBL listing policy. For example, the requirement is not appropriate >> if the listing is based on who the address space has been allocated to, >> especially if the reason is that it has been allocated to criminals. >> In that case you expect to come into conflict with people who are listed. > > I strongly believe this is covered by the verbiage in this section. Should a > criminal spammer find himself listed in the SBL (for example), he should be > allowed to immediately request removal, and be granted that. As soon as he > spams, he should be immediately relisted. And the limits on removals be made > harder for him/her - see the second to last sentence in that first paragraph. > The intention is to make innocent listings easy to remove, and criminal > listings harder to remove. > Is this always desirable? Does anyone here have any statistics about how long a spammer can spam on average before being picked up by DNSBLs? My impression from our use of Spamhaus is that detection is slow. On our system with about a 1,000 active mail accounts only about 1% of spam source IP addresses were seen more than once in the test week, suggesting to me that it would be difficult to tell if spamming had ceased in less than several months unless one had a very large set of spam traps. If removal must be automatic, doesn't that unnecesarily give the spammer twice as long on the IP address? It seems like that would double the amount of uncaught spam. I would have thought that confirming a delisting with the ASN abuse contact or providing reverse name look to a non-generic host name would be reasonable precaustions a DNSBL might wish to impose before delisting an address, and that in any case it should be up to list policy. There is a principle of statistics that if your detector sees only a small fraction of events, then variation in the rate is mostly random, and not evidence of variation in the underlying process. Daniel Feenberg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 09:02:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFWJ4-00019S-DS; Fri, 09 Feb 2007 09:00:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFWJ1-00011d-CL for asrg@ietf.org; Fri, 09 Feb 2007 09:00:51 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFWIw-000690-68 for asrg@ietf.org; Fri, 09 Feb 2007 09:00:51 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HFWFo-00023U-Nx for asrg@ietf.org; Fri, 09 Feb 2007 14:57:34 +0100 Received: from d254119.dialin.hansenet.de ([80.171.254.119]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Feb 2007 14:57:32 +0100 Received: from nobody by d254119.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Feb 2007 14:57:32 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Fri, 09 Feb 2007 14:47:13 +0100 Organization: Lines: 160 Message-ID: <45CC7B61.323C@xyzzy.claranet.de> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <8A308376-E1F0-4089-86C1-1FF200D1A548@messagelabs.com> 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: d254119.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Subject: [Asrg] Re: DNSBL BCP v.2.0 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Matt Sergeant wrote: >> Some DNSBLs are in fact "DNS based lists" used for other purposes >> like Geo location. If you haven't done it later you could note >> that you're not talking about the general "DNSBL" concept. > I think we entirely cover that under 2.2.1. Please let us know if > you think we don't. Yes, I read it top down, and the first definition sounded like "it's only about 'B' as in 'bl[ao]ck'". Later you have "or anything" with a 'B' as in 'based'. IP-based geo-location - as far as you believe in it - can be completely unrelated to 'bl[oa]ck'. If you want to cover the latter maybe state it earlier, before 2.2.1. It's certainly a nice example why decisions to block "countries" by IP could indicate a dangerous degree of ignorance on the side of the list user. The location could be wrong, it could change any time, and if users block complete countries they MUST NOT send any abuse reports to mailboxes in this country while they block the replies. That's a general principle, if users block something they MUST NOT send mails to the (from their POV) blackholes, replies won't work. You could recommend that users blocking IPs should also refuse to transport messages to the blackhole. >>> 9. What do your peers or members of the Internet community say >>> about the list. >> They all say it's bad for various conflicting reasons, none of them >> related to any incident in the last five years. > :-) Not sure how we could encode that in a BCP. How about simply removing (7) and (9) ? Or replace it by a general advice "try to find and evaluate opinions of third parties about the list in question". My interpretation of (7) would cover "OPM is for IRC geeks, therefore it can't be good". And that's wrong. For (9) I got "read NANAE", but admins should not waste time there, unless they really like it. [about "allows a third party to make blocking decisions"] >> actually a list does NEVER make blocking decisions for a list >> user, because nobody is forced to use it. How about "uses the >> proposals of a third party to make blocking decisions". > Not sure which part you think is badly worded here. Please elaborate. - If a system or network administrator allows a third party to make - blocking decisions for its network, then the administrator MUST [...] + If a system or network administrator uses the proposals of a third + party to make blocking decisions, then the administrator MUST [...] >> s/through a mechanism such as/on/ No nonsense please, if it has >> no Web site it's anyway bogus. > It's entirely conceivable that a DNSBL's public presence might be > purely a yahoo-groups mailing list, or NANABL, or some-such. No, this is not entirely conceivable for a DNSBL with its own zone. If it can answer queries for 2.0.0.127.dnsbl.example "hosts", then it can also answer a query for host dnsbl.example, and they can then arrange that "GET dnsbl.example HTTP/1.0" returns something useful. If it's a FAQ explaining how to use a YahoGroup or NANABl it's not ideal, but acceptable as least common denominator. It's a good convention, it should be recommended. My attempts to convince Jeff that say http://multi.surbl.org should work, and that http://surbl.org (without "www" label) should of course also work, failed. But maybe he'll believe it if you state it as SHOULD... :-) A low hanging fruit, please don't miss it. It also simplifies the documentation of tools querying DNSBLs, "... queries x.y.example, for technical listing details see http://y.example". If it's not predictable where a DNSBL has at least a HTTP redirection to its policy it only makes the maintenance of such tools more difficult. [upper limit for a listing] > We've mulled over this a lot. Gone back and forth. In the end we > said 6 months because if we put no limit on then it's no help - a > DNSBL could just set the limit at 30 years. Yes, I'm not very happy with RFCI listings where the evidence is several years old (of course RFCI is a set of RHSBLs today, no more DNSBL, and likewise SURBL is no real DNSBL, but most parts of your draft also work for RHSBLs). But "6 months" is still an unnecesary magic number. If it's the stated listing policy to note "postmaster@ bounced 2003-04-01, and will be listed until they request it in a MAIL FROM postmaster@, and click on an URL in the reply", then that's as it is, not nice, but also not unreasonable. Maybe what you really want is that lists MUST publish the upper limit in their policy (?) > this is very well covered by the last point in this section - > that a temporary listing can easily be extended by (for example) > receiving more spam from this IP/range. Yes, a second case where reading the I-D bottom up could be better than top down If you insist on a magic number 6 months is certainly long enough, maybe already too long. >>> However, longer periods SHOULD NOT be used since it is possible >>> that an IP address or domain can change hands, possibly being >>> allocated to a non-abusive user. >> Add "unless it's the stated list policy to cause collateral damage >> for users getting their IPs from spam-supporting organizations." > Even the organisation can change hands. See above. Caveat emptor. If a tainted IP is worthless, this could be a part of the "excommunication after XAB" concept. Maybe only RIRs can clean tainted IPs. Of course users need to know that they're in for a fundamentalistic armageddon with this approach. [127.255.255.255] >> Was that concept already tested anywhere ? > It has been discussed both here and in many other places. If the "namedroppers" and similar cabals like it it's fine. [RFC 1918] > list != result. We're not talking about the result IP here. Sorry, I got that wrong. If a DNSBL lists private IPs in addition to the known 127.0.0.2 test entry it should be very clear about it in its policy. Maybe repeat this as "security consideration", it could cause havoc. Please add an informative reference to RFC 3330, it has a nice fresh overview of all special IPv4 addresses. There ought to be something similar for IPv6, but I don't know where. >>> In particular, most DNSBLs use a positive response for 127.0.0.2 >> s/most/many/ and s/for/of/ > I think "most" is fine. The second change is correct. I try to use "combined lists" where possible, limiting the number of DNS queries, and for combined lists 127.0.0.2 is only one of the positive responses. Proposed text: | In particular, DNSBLs use a positive response of 127.0.0.2 or | other values in the 127.0.0.0/8 range excluding 127.0.0.0/31 | (see RFC 4632 for the notation). >> You should also mention that lists SHOULD support 127.0.0.2 as >> "always listed" test entry, and 127.0.0.1 for the opposite (never >> listed), without ever returning 127.0.0.1 as a result. > Good point. We'll consider adding that. It's a good test for DNSBL > validity. Yes, that's the idea. DNS based tools won't directly check q=ns to catch any 127.255.255.255 condition. Two test queries (127.0.0.2 as listed, 127.0.0.1 as not listed) could detect "osirusoft" stunts. Or whatever "monkeys" finally did for its formal net suicide. Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 09:32:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFWn1-0005ZG-Ap; Fri, 09 Feb 2007 09:31:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFWmz-0005ZB-Tp for asrg@ietf.org; Fri, 09 Feb 2007 09:31:49 -0500 Received: from bigsky.scconsult.com ([66.73.230.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFWmw-0001c8-0i for asrg@ietf.org; Fri, 09 Feb 2007 09:31:49 -0500 Received: from bigsky.scconsult.com (localhost [127.0.0.1]) by bigsky.scconsult.com (Postfix) with ESMTP id 00B414129E6 for ; Fri, 9 Feb 2007 09:31:44 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> X-Message-Flag: Use of Microsoft mail clients is the primary cause of cracked systems. Please switch! Date: Fri, 9 Feb 2007 09:31:40 -0500 To: asrg@ietf.org From: Bill Cole Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org At 11:44 PM -0500 2/8/07, Matt Sergeant wrote: >On 8-Feb-07, at 11:21 PM, Douglas Otis wrote: [...] >>3.3. Content of DNSBL Zone File SHOULD Be Limited. >> >>The DNSBL "query root" SHOULD be below the registered domain, so >>that the DNSBL information is not conflated with domain housekeeping >>information (e.g., name server, MX or SPF records). By using this >>approach, DNSBL queries would take the form of >>".dnsbl.example.com" rather than ".example.com". >>--- >> >>This would be a problem only when zone transfers are used to distribute >>data. > >... which covers all public DNSBLs, surely? I think not. DNSBL operators seem to be very fond of rbldnsd, which does not implement zone transfers. I can't speak for how Spamhaus moves zones to its authoritative servers or in from primary sources like the CBL, but their data feeds to big users are via rsync of rbldnsd data. HOWEVER, Mr. Otis is missing a more important aspect. Putting a DNSBL right on a registered domain means that the roots for the registry-level domain (i.e. the gtld-servers.net machines for a .com) can be put in a bad spot for a shutdown. The recommended shutdown procedure (as well as simply wiping out the zone) leaves any ongoing DNS burden primarily on the nameservers for the parent zone of the DNSBL, and it would be bad for DNSBL operators to dump that on others. -- Bill Cole bill@scconsult.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 10:18:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXSz-000830-Fw; Fri, 09 Feb 2007 10:15:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXSw-00082u-RU for asrg@ietf.org; Fri, 09 Feb 2007 10:15:10 -0500 Received: from mail48.messagelabs.com ([193.109.255.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HFXSv-0000PJ-5W for asrg@ietf.org; Fri, 09 Feb 2007 10:15:10 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-16.tower-48.messagelabs.com!1171034107!1760350!1 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 27394 invoked from network); 9 Feb 2007 15:15:07 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-16.tower-48.messagelabs.com with SMTP; 9 Feb 2007 15:15:07 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 15:15:07 +0000 Received: (qmail 5500 invoked from network); 9 Feb 2007 15:15:06 -0000 Received: from unknown (HELO ?10.100.0.124?) (10.100.0.124) by matt?dev.int.star.co.uk with SMTP; 9 Feb 2007 15:15:06 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] DNSBL BCP v.2.0 Date: Fri, 9 Feb 2007 10:14:50 -0500 To: Daniel Feenberg X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Feb 2007 15:15:07.0102 (UTC) FILETIME=[14FB1FE0:01C74C5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Tony Finch , asrg@ietf.org, Nick@habeas.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 9-Feb-07, at 7:46 AM, Daniel Feenberg wrote: >> I strongly believe this is covered by the verbiage in this >> section. Should a criminal spammer find himself listed in the SBL >> (for example), he should be allowed to immediately request >> removal, and be granted that. As soon as he spams, he should be >> immediately relisted. And the limits on removals be made harder >> for him/her - see the second to last sentence in that first >> paragraph. The intention is to make innocent listings easy to >> remove, and criminal listings harder to remove. > > Is this always desirable? No. That's why it's a SHOULD. > If removal must be automatic, doesn't that unnecesarily give the > spammer twice as long on the IP address? Technically yes. But the majority of spammers aren't going to go through the removal process, simply because they don't want to end up having that discussion. A good example of a DNSBL that honours immediate removal requests is the CBL. One of the very first DNSBLs (the one that became MAPS RSS) also did this. > It seems like that would double the amount of uncaught spam. I > would have thought that confirming a delisting with the ASN abuse > contact or providing reverse name look to a non-generic host name > would be reasonable precaustions a DNSBL might wish to impose > before delisting an address, and that in any case it should be up > to list policy. Absolutely. This BCP is just a list of recommendations for that policy (especially the SHOULD parts). We think automatic removals are best practice because they help keep FPs low, but not every DNSBL will agree. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 10:47:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXxj-0004HR-M3; Fri, 09 Feb 2007 10:46:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFXxj-0004HG-2f for asrg@ietf.org; Fri, 09 Feb 2007 10:46:59 -0500 Received: from mail50.messagelabs.com ([195.245.230.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HFXxg-0005GN-LS for asrg@ietf.org; Fri, 09 Feb 2007 10:46:59 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-22.tower-50.messagelabs.com!1171036014!6467357!1 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 13606 invoked from network); 9 Feb 2007 15:46:54 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-22.tower-50.messagelabs.com with SMTP; 9 Feb 2007 15:46:54 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 15:46:54 +0000 Received: (qmail 5535 invoked from network); 9 Feb 2007 15:46:53 -0000 Received: from unknown (HELO ?10.100.0.124?) (10.100.0.124) by matt?dev.int.star.co.uk with SMTP; 9 Feb 2007 15:46:53 -0000 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Fri, 9 Feb 2007 10:46:37 -0500 To: Bill Cole X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Feb 2007 15:46:54.0246 (UTC) FILETIME=[85BA3460:01C74C61] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 9-Feb-07, at 9:31 AM, Bill Cole wrote: >>> This would be a problem only when zone transfers are used to >>> distribute >>> data. >> >> ... which covers all public DNSBLs, surely? > > I think not. DNSBL operators seem to be very fond of rbldnsd, which > does not implement zone transfers. My bad - I consider a zone transfer in this day and age to be an rsync :) > Putting a DNSBL right on a registered domain means that the roots > for the registry-level domain (i.e. the gtld-servers.net machines > for a .com) can be put in a bad spot for a shutdown. The > recommended shutdown procedure (as well as simply wiping out the > zone) leaves any ongoing DNS burden primarily on the nameservers > for the parent zone of the DNSBL, and it would be bad for DNSBL > operators to dump that on others. Right - this was our original intention. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 13:39:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFabf-0002SY-MM; Fri, 09 Feb 2007 13:36:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFabe-0002ST-2u for asrg@ietf.org; Fri, 09 Feb 2007 13:36:22 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFabc-0001Jt-Lf for asrg@ietf.org; Fri, 09 Feb 2007 13:36:22 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l19IaFsI011106 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Feb 2007 10:36:15 -0800 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <82DC29B0-3543-4F56-A6A4-0E0CBBDF2A50@mail-abuse.org> Content-Transfer-Encoding: quoted-printable From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Fri, 9 Feb 2007 10:36:24 -0800 To: Bill Cole X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 9, 2007, at 6:31 AM, Bill Cole wrote: > At 11:44 PM -0500 2/8/07, Matt Sergeant wrote: >> On 8-Feb-07, at 11:21 PM, Douglas Otis wrote: > >>> 3.3. Content of DNSBL Zone File SHOULD Be Limited. >>> >>> The DNSBL "query root" SHOULD be below the registered domain, so >>> that the DNSBL information is not conflated with domain housekeeping >>> information (e.g., name server, MX or SPF records). By using this >>> approach, DNSBL queries would take the form of >>> ".dnsbl.example.com" rather than ".example.com". >>> --- >>> >>> This would be a problem only when zone transfers are used to >>> distribute data. >> >> ... which covers all public DNSBLs, surely? > > I think not. DNSBL operators seem to be very fond of rbldnsd, which =20= > does not implement zone transfers. I can't speak for how Spamhaus =20 > moves zones to its authoritative servers or in from primary sources =20= > like the CBL, but their data feeds to big users are via rsync of =20 > rbldnsd data. When a DNSBL is successful at blocking bad actors controlling perhaps =20= thousands of systems, defending against a DDoS becomes a major =20 concern. Even the mention of SPF in this document indicates an =20 extreme naivet=E9 about DDoS risks. I had hoped to make a presentation =20= in MAAWG about this concern, but the board decided this might upset =20 investments made by key promoters of Sender-ID. Anyone should be =20 able to register their SMTP path. An inherently safe approach would =20 be to first authenticate the SMTP client, and then associate various =20 originating domains with SMTP client names. A similar strategy could =20= indicate the possibility of a DKIM replay. There are many ways this =20 can be safely done and still achieve similar goals. Although Frank scoffed at the DDoS concerns related to SPF, testing =20 scripts feed with various input parameters that parse and expand SPF =20 records suggests there should be significant warnings associated with =20= this approach. It would seem that this DNSBL draft might be more =20 concerned about seeing DNSBLs go away. This might be sooner than =20 anyone may have wanted. Having them go away "gracefully" still means =20= someone is paying for bandwidth without any benefit. Zone transfers are unhelpful for two reasons as they are: 1) not responsive to changing behaviors 2) prone to attack unless defended by ACLs Suggestions that web servers should be used and share the same name =20 server as that of the DNSBL places even greater burdens upon those =20 attempting to defend their service. Why not mention the use of TXT =20 records as a means of noting contact information? Why must this be =20 done via a web site? Why avoid flexibility? Where is the =20 compassion? : ) > Putting a DNSBL right on a registered domain means that the roots =20 > for the registry-level domain (i.e. the gtld-servers.net machines =20 > for a .com) can be put in a bad spot for a shutdown. There are many labels involved in a BL transaction using =20 d.c.b.a.example.com. When example.com wants to gracefully shutdown =20 as described (although this is not likely to achieve the desired =20 result of stopping undesired transactions), this can be done at 'a' =20 labels just as well. These labels must be avoided within any shared =20 zone anyway. The statement about where the zone should exist is not =20 needed. The wording used simply indicates a lack of consideration =20 given related threats. > The recommended shutdown procedure (as well as simply wiping out =20 > the zone) leaves any ongoing DNS burden primarily on the =20 > nameservers for the parent zone of the DNSBL, and it would be bad =20 > for DNSBL operators to dump that on others. Returning records for each transaction will quickly cause removal of =20 DNSBLs likely embedded in some script that an MTA operator may not =20 even be aware of. An announcement that DNSBL 'X' is about to stop =20 functioning in this manner should get operators attention. Those =20 ignoring the warning will quickly make corrections thereafter. =20 Otherwise, expect wasted traffic to continue for years. This =20 sentence mentions SPF, where this is to be considerate of DNS TLDs? =20 What about being considerate to the Internet as a whole? I posted slides presented to the ISOI II at: http://www.sonic.net/~dougotis/isoi/ These slides are similar to those presented at the DNS-OP WG. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 15:38:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFcTB-0001Zj-GI; Fri, 09 Feb 2007 15:35:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFcTA-0001YM-62 for asrg@ietf.org; Fri, 09 Feb 2007 15:35:44 -0500 Received: from mail48.messagelabs.com ([193.109.255.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HFcT8-0002pn-G5 for asrg@ietf.org; Fri, 09 Feb 2007 15:35:44 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-8.tower-48.messagelabs.com!1171053340!3791533!1 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 8331 invoked from network); 9 Feb 2007 20:35:40 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-8.tower-48.messagelabs.com with SMTP; 9 Feb 2007 20:35:40 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 20:35:40 +0000 Received: (qmail 5915 invoked from network); 9 Feb 2007 20:35:40 -0000 Received: from unknown (HELO ?10.100.0.124?) (10.100.0.124) by matt?dev.int.star.co.uk with SMTP; 9 Feb 2007 20:35:40 -0000 In-Reply-To: <82DC29B0-3543-4F56-A6A4-0E0CBBDF2A50@mail-abuse.org> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <82DC29B0-3543-4F56-A6A4-0E0CBBDF2A50@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <875303C3-8714-4495-87A5-65E1F2959FEE@messagelabs.com> Content-Transfer-Encoding: quoted-printable From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Fri, 9 Feb 2007 15:35:22 -0500 To: Douglas Otis X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 09 Feb 2007 20:35:40.0623 (UTC) FILETIME=[DD0D85F0:01C74C89] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On=209-Feb-07,=20at=201:36=20PM,=20Douglas=20Otis=20wrote: >=20Even=20the=20mention=20of=20SPF=20in=20this=20document=20indicates=20a= n=20extreme=20=20 >=20naivet=E9=20about=20DDoS=20risks. Not=20really.=20The=20mention=20of=20SPF=20should=20go=20-=20it=20was=20a=20= bad=20choice.=20The=20=20 rest=20of=20your=20email=20seemed=20to=20have=20nothing=20whatsoever=20to=20= do=20with=20this=20=20 draft,=20but=20perhaps=20if=20you=20want=20to=20re-word=20it=20without=20g= etting=20all=20=20 wrapped=20up=20in=20the=20presence=20of=20three=20letters=20in=20the=20dra= ft=20then=20it=20=20 might=20be=20clearer=20what=20you're=20trying=20to=20say. Matt. ______________________________________________________________________ This=20email=20has=20been=20scanned=20by=20the=20MessageLabs=20Email=20Sec= urity=20System. For=20more=20information=20please=20visit=20http://www.messagelabs.com/ema= il=20 ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 16:19:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFd84-0004b9-P8; Fri, 09 Feb 2007 16:18:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFd83-0004b0-E3 for asrg@ietf.org; Fri, 09 Feb 2007 16:17:59 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFd82-0001QZ-0N for asrg@ietf.org; Fri, 09 Feb 2007 16:17:59 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l19LA1X04895 for ; Fri, 9 Feb 2007 16:10:01 -0500 (EST) Received: from [47.9.16.19] ([47.9.16.19] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 16:17:53 -0500 Message-ID: <45CCE4FC.3090402@nortel.com> Date: Fri, 09 Feb 2007 16:17:48 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <82DC29B0-3543-4F56-A6A4-0E0CBBDF2A50@mail-abuse.org> In-Reply-To: <82DC29B0-3543-4F56-A6A4-0E0CBBDF2A50@mail-abuse.org> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Feb 2007 21:17:54.0398 (UTC) FILETIME=[C34CE7E0:01C74C8F] X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org [FYI: I'm mostly just observing, letting the discussion run... But this deserved comment in terms of the intent behind the BCP] Douglas Otis wrote: > > On Feb 9, 2007, at 6:31 AM, Bill Cole wrote: >> I think not. DNSBL operators seem to be very fond of rbldnsd, which >> does not implement zone transfers. I can't speak for how Spamhaus >> moves zones to its authoritative servers or in from primary sources >> like the CBL, but their data feeds to big users are via rsync of >> rbldnsd data. > When a DNSBL is successful at blocking bad actors controlling perhaps > thousands of systems, defending against a DDoS becomes a major concern. Yes, but I don't think anything in the BCP predisposes compliant operators putting themselves at risk of DDOS or any other hazard more than is minimally necessary to provide the service in the first place. As a general principle, we tried to avoid anything that would do that. > It would seem that this DNSBL draft might be more > concerned about seeing DNSBLs go away. This might be sooner than anyone > may have wanted. Having them go away "gracefully" still means someone > is paying for bandwidth without any benefit. DNSBLs going away ungracefully has been a source of considerable adverse press about them. The suggested process appears to be the best way to reduce bandwidth (both for the DNSBL and third parties) without listing the world. You seem to prefer the blacklist the world concept (wildcarding results). That's a VERY VERY bad idea because reality causes everyone shutting down that way to be perceived as irresponsible idiots, and damages the reputation of DNSBLs in general. The ripples of the OSIRUS and Monkeys shutdowns are still reverberating and smear all subsequent DNSBLs. The intent of the described process is this: 1) The registered domain remains useful and unflooded with DNS queries (whether regular queries or wild resolvers). (This was an issue with both Osirus and Monkeys) 2) The TLD servers aren't flooded (for each query or wild resolvers) 3) the world isn't blacklisted 4) The user of the DNSBL eventually notices, without suffering a complete loss of email. By doing the DNSBL's base zone below the registered domain, you can have a NS server separate from the registered domain. You can shut down such a DNSBL by setting the DNSBL's NS to point somewhere in 127/8 (other than 127.0.0.0/24, say[+]). Since the NS TTL has been set high, a DNSBL query won't requery it (off the registered domain's NS) very frequently. Since no NS responds from the 127/8 address, the query times out. Causing the user's email to be delayed by the query timeout, not 100% blacklisted. The user's admins eventually notice the delay, and remove the entry. It's been suggested that setting the DNSBL's NS record to "." would do the same, but there seems to be indications that some resolvers don't handle that well. One of the things we have to consider is that once a DNSBL becomes popular, its name becomes somewhaet of a deadzone for a very long time. If you let the registered domain expire as a way of killing the DNSBL, wildcarding (perhaps by a domain squatter acquiring the domain, or Verisign deploying whatever that was again) will have catastrophic results. In some cases, you might have to keep the domain registered forever to avoid something nasty. [Try doing DNSBL queries against letter transpositions of "spamhaus.org" some day. You should find several typosquatters wildcarding to their web sites which means 100% blacklisting to some DNSBL query clients]. [blars.org appears to have simply been allowed to expire recently. But it's way too much a marginally used DNSBL to draw conclusions on what would happen if, say, spamhaus.org went away.] You did mention that the TXT record should include contact and/or explanatory info (as in a link). We obviously forgot that, and it should be added as a "SHOULD" or at least "RECOMMENDED". I'm not sure what the discussion about zone transfers is all about. I don't think many DNSBLS support real DNS zone transfers anymore. An AXFR transfer of a DNSBL like the XBL is hideously expensive. Most DNSBLs have settled on rsync, and other forms (various DNS protocol methods, wget, ftp etc) have been disappearing over time. It might be worth mentioning rsync as the "defacto standard DNSBL bulk transfer mechanism", but leave it at that. [+] Putting the NS on 127.0.0.1, say, could be extremely dangerous - the MTA using the DNSBL may be coresident with a DNS resolver that returns wierd results that we can't predict the MTA can handles properly. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 17:38:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFeJB-00025S-Ve; Fri, 09 Feb 2007 17:33:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFeJA-00025K-Oq for asrg@ietf.org; Fri, 09 Feb 2007 17:33:32 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFeJ8-000565-Dw for asrg@ietf.org; Fri, 09 Feb 2007 17:33:32 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HFeJ5-0003q5-51 for asrg@ietf.org; Fri, 09 Feb 2007 23:33:27 +0100 Received: from d254119.dialin.hansenet.de ([80.171.254.119]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Feb 2007 23:33:27 +0100 Received: from nobody by d254119.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Feb 2007 23:33:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Fri, 09 Feb 2007 23:14:31 +0100 Organization: Lines: 40 Message-ID: <45CCF247.610C@xyzzy.claranet.de> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <82DC29B0-3543-4F56-A6A4-0E0CBBDF2A50@mail-abuse.org> 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: d254119.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Asrg] 100:11 (was: DNSBL BCP v.2.0) X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Douglas Otis wrote: > Why not mention the use of TXT records as a means of > noting contact information? IIRC the name of that record is RP or similar, not TXT. > Why must this be done via a web site? Because http is quite popular for transporting more than 400 bytes. Nothing against gopher or whois, but... > I posted slides presented to the ISOI II at: > http://www.sonic.net/~dougotis/isoi/ Comparing the size of the message with the size of the final queries is bogus. The attacker has to sustain those queries from his own name server, and with that it's a factor near 9 (11 or 12 queries to the attacker, 100 queries to the victim). The a * b * c * d stuff ignores caches, it's nonsense. As an attacker with 102,400 bots I wouldn't bother to figure out who checks SPF and how their DNS caches work, and bet on ordinary "call back verification". Or let the bots flood the victim directly with bogus queries. And it won't surprise me if some SPF implementations already have a "NXDOMAIN processing limit" to catch your convoluted attempts based on malicious MX records. Terminate policies with "+all" is also bullshit, the fastest way to get a PASS for any IP is to use only "v=spf1 +all". Of course that's a really bad idea for somebody planning to stay on a white list, but some spammers might like the cheap PASS. Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 18:11:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFetK-0000xS-Oc; Fri, 09 Feb 2007 18:10:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFetK-0000xN-56 for asrg@ietf.org; Fri, 09 Feb 2007 18:10:54 -0500 Received: from xuxa.iecc.com ([208.31.42.42]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HFetG-0005Mz-Rf for asrg@ietf.org; Fri, 09 Feb 2007 18:10:54 -0500 Received: (qmail 17221 invoked from network); 9 Feb 2007 23:10:50 -0000 Received: from simone.iecc.com (208.31.42.47) by mail2.iecc.com with QMQP; 9 Feb 2007 23:10:50 -0000 Date: 9 Feb 2007 23:10:50 -0000 Message-ID: <20070209231050.87023.qmail@simone.iecc.com> From: John Levine To: asrg@ietf.org Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 In-Reply-To: <45CCE4FC.3090402@nortel.com> Organization: Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit X-Spam-Score: -4.3 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: clewis@nortel.com X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org >I'm not sure what the discussion about zone transfers is all about. I >don't think many DNSBLS support real DNS zone transfers anymore. Until recently, MAPS distributed its DNSBLs by AXFR and IXFR. If you happen to have a DNS server that does IXFR, it's not a bad way to do DNS updates. If you don't (like me), AXFR is dreadful. MAPS recently changed their setup and now tell me just to query their servers via a long name that includes a hash of my account number, which I do via a funky local cache that reformats the data on the fly into something easier for my mail servers to use. I don't know of anyone who distributes DNSBLs other than by rsync or FTP of files of CIDR ranges. R's, John _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 18:13:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFevX-0002Vc-Gi; Fri, 09 Feb 2007 18:13:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFevW-0002U1-D9 for asrg@ietf.org; Fri, 09 Feb 2007 18:13:10 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFevT-0005oa-Sq for asrg@ietf.org; Fri, 09 Feb 2007 18:13:10 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l19ND68v032717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Feb 2007 15:13:07 -0800 In-Reply-To: <45CCE4FC.3090402@nortel.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <82DC29B0-3543-4F56-A6A4-0E0CBBDF2A50@mail-abuse.org> <45CCE4FC.3090402@nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E29692B-316A-4A67-8291-68AACAABC772@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Fri, 9 Feb 2007 15:13:04 -0800 To: Chris Lewis X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 9, 2007, at 1:17 PM, Chris Lewis wrote: > [FYI: I'm mostly just observing, letting the discussion run... But > this > deserved comment in terms of the intent behind the BCP] > > Douglas Otis wrote: >> >> On Feb 9, 2007, at 6:31 AM, Bill Cole wrote: >>> I think not. DNSBL operators seem to be very fond of rbldnsd, >>> which does not implement zone transfers. I can't speak for how >>> Spamhaus moves zones to its authoritative servers or in from >>> primary sources like the CBL, but their data feeds to big users >>> are via rsync of rbldnsd data. > >> When a DNSBL is successful at blocking bad actors controlling >> perhaps thousands of systems, defending against a DDoS becomes a >> major concern. > > Yes, but I don't think anything in the BCP predisposes compliant > operators putting themselves at risk of DDOS or any other hazard > more than is minimally necessary to provide the service in the > first place. As a general principle, we tried to avoid anything > that would do that. Few seem to consider this aspect of providing BL services. >> It would seem that this DNSBL draft might be more concerned about >> seeing DNSBLs go away. This might be sooner than anyone may have >> wanted. Having them go away "gracefully" still means someone is >> paying for bandwidth without any benefit. > > DNSBLs going away ungracefully has been a source of considerable > adverse press about them. The suggested process appears to be the > best way to reduce bandwidth (both for the DNSBL and third parties) > without listing the world. You seem to prefer the blacklist the > world concept (wildcarding results). That's a VERY VERY bad idea > because reality causes everyone shutting down that way to be > perceived as irresponsible idiots, and damages the reputation of > DNSBLs in general. The ripples of the OSIRUS and Monkeys shutdowns > are still reverberating and smear all subsequent DNSBLs. Those offering a free service are not likely concerned about earning DNSBLs a bad reputation, especially they are bombarded by an ill considered scheme designed to keep the SMTP client nameless. There is a similar conversation on nanog about maps.vix.com. Here is a link to a possible solution. The point is not to be "graceful" but to get the transactions to stop. This requires some level of pain, but block all messages would be rather extreme. Suggesting that BL should forever return some type of safe response for time immemorial is not a good solution either. http://www.merit.edu/mail.archives/nanog/msg04555.html > The intent of the described process is this: > > 1) The registered domain remains useful and unflooded with DNS queries > (whether regular queries or wild resolvers). (This was an issue with > both Osirus and Monkeys) > 2) The TLD servers aren't flooded (for each query or wild resolvers) > 3) the world isn't blacklisted > 4) The user of the DNSBL eventually notices, without suffering a > complete loss of email. > > By doing the DNSBL's base zone below the registered domain, you can > have a NS server separate from the registered domain. You can shut > down such a DNSBL by setting the DNSBL's NS to point somewhere in > 127/8 (other than 127.0.0.0/24, say[+]). Since the NS TTL has been > set high, a DNSBL query won't requery it (off the registered > domain's NS) very frequently. Since no NS responds from the 127/8 > address, the query times out. Causing the user's email to be > delayed by the query timeout, not 100% blacklisted. The user's > admins eventually notice the delay, and remove the entry. Perhaps. This delay would be 35 seconds or so. Many that query list of lists quit after some timeout hoping some information has been obtained. Even this might not be noticed. Perhaps a list of NS would attract greater attention. As been mentioned, this requires a different structure. > It's been suggested that setting the DNSBL's NS record to "." would > do the same, but there seems to be indications that some resolvers > don't handle that well. And not nice. > One of the things we have to consider is that once a DNSBL becomes > popular, its name becomes somewhaet of a deadzone for a very long > time. If you let the registered domain expire as a way of killing > the DNSBL, wildcarding (perhaps by a domain squatter acquiring the > domain, or Verisign deploying whatever that was again) will have > catastrophic results. In some cases, you might have to keep the > domain registered forever to avoid something nasty. Review the referenced nanog message. There might be a better solution. > You did mention that the TXT record should include contact and/or > explanatory info (as in a link). We obviously forgot that, and it > should be added as a "SHOULD" or at least "RECOMMENDED". > > I'm not sure what the discussion about zone transfers is all > about. I don't think many DNSBLS support real DNS zone transfers > anymore. An AXFR transfer of a DNSBL like the XBL is hideously > expensive. Most DNSBLs have settled on rsync, and other forms > (various DNS protocol methods, wget, ftp etc) have been > disappearing over time. It might be worth mentioning rsync as the > "defacto standard DNSBL bulk transfer mechanism", but leave it at > that. The concern was about where the zone is located within the domain. This section is not needed. > [+] Putting the NS on 127.0.0.1, say, could be extremely dangerous > - the MTA using the DNSBL may be coresident with a DNS resolver > that returns wierd results that we can't predict the MTA can > handles properly. Agreed. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 18:27:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFf8g-0005LX-Us; Fri, 09 Feb 2007 18:26:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFf8f-0005LS-Ov for asrg@ietf.org; Fri, 09 Feb 2007 18:26:45 -0500 Received: from fruitbat.wordtothewise.com ([208.187.80.135] helo=m.wordtothewise.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFf8e-0007qU-GN for asrg@ietf.org; Fri, 09 Feb 2007 18:26:45 -0500 Received: from [10.3.2.25] (184.word-to-the-wise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id DF1D744E82C3 for ; Fri, 9 Feb 2007 15:26:33 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <20070209231050.87023.qmail@simone.iecc.com> References: <20070209231050.87023.qmail@simone.iecc.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <292B9C69-C76C-43F4-81B5-5ADFE51C9E01@blighty.com> Content-Transfer-Encoding: 7bit From: Steve Atkins Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Fri, 9 Feb 2007 15:26:30 -0800 To: ASRG list X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 9, 2007, at 3:10 PM, John Levine wrote: >> I'm not sure what the discussion about zone transfers is all >> about. I >> don't think many DNSBLS support real DNS zone transfers anymore. > > Until recently, MAPS distributed its DNSBLs by AXFR and IXFR. If you > happen to have a DNS server that does IXFR, it's not a bad way to do > DNS updates. If you don't (like me), AXFR is dreadful. > > MAPS recently changed their setup and now tell me just to query their > servers via a long name that includes a hash of my account number, > which I do via a funky local cache that reformats the data on the fly > into something easier for my mail servers to use. I don't know of > anyone who distributes DNSBLs other than by rsync or FTP of files of > CIDR ranges. ... which is a shame, as they're both really bad ways of doing it, but they work, they're easy to kludge together from existing tools and scale way better than AXFR. I have seen a couple of blacklists fairly recently that do still use AXFR, but they were way, way out in the long tail - probably entirely unused by anyone other than their operators. If they ever became popular their operators would switch to rsync pretty quickly, I suspect. Cheers, Steve _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 19:09:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFflW-0002Mp-42; Fri, 09 Feb 2007 19:06:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFflU-0002Mk-Mk for asrg@ietf.org; Fri, 09 Feb 2007 19:06:52 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFflT-0005O0-6y for asrg@ietf.org; Fri, 09 Feb 2007 19:06:52 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1A06kLt026095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Feb 2007 16:06:46 -0800 In-Reply-To: <45CCF247.610C@xyzzy.claranet.de> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <82DC29B0-3543-4F56-A6A4-0E0CBBDF2A50@mail-abuse.org> <45CCF247.610C@xyzzy.claranet.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] 100:11 (was: DNSBL BCP v.2.0) Date: Fri, 9 Feb 2007 16:06:44 -0800 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 9, 2007, at 2:14 PM, Frank Ellermann wrote: > Douglas Otis wrote: > >> Why not mention the use of TXT records as a means of noting >> contact information? > > IIRC the name of that record is RP or similar, not TXT. There are also TXT records that may accompany the A record. Often this indicates a contact method. >> Why must this be done via a web site? > > Because http is quite popular for transporting more than 400 > bytes. Nothing against gopher or whois, but... Whatever gets used must be robust against DDoS attack without costing a fortune. Other solutions might be more effective, so why rule them out. >> I posted slides presented to the ISOI II at: >> http://www.sonic.net/~dougotis/isoi/ > > Comparing the size of the message with the size of the final > queries is bogus. The attacker is sending spam anyway. Even email traffic should not be considered part of the attack overhead. This means the amplification is actually much much greater! > The attacker has to sustain those queries from his own name server, > and with that it's a factor near 9 (11 or 12 queries to the > attacker, 100 queries to the victim). The SPF macro language allows the same SPF script to utilize local- part elements of an email address to cause any subsequent lookup to occur. These scripts can enjoy a very long TTL and not be re- queried. The MX records and their targets then enjoy the difference between a negative cache TTL, where in many cases the number needed to seed an attack would not be many per local resolver. The reality this problem is actually worse than the numbers listed and virtually free to the attacker, unlike most direct attacks, or even spoofed recursive attacks. > The a * b * c * d stuff ignores caches, it's nonsense. Queries are randomized by the local-part as needed. Attacking queries will not be found within an cache. This is not nonsense. > As an attacker with 102,400 bots I wouldn't bother to figure out > who checks SPF and how their DNS caches work, and bet on ordinary > "call back verification". Or let the bots flood the victim > directly with bogus queries. SPF allows an attack to be reflected off of some ISPs resolvers at virtually no cost to their own resources. These attacks are done at the behest of the attacker when recipients attempt to process their SPF scripts. The attacker will still be able to send the same number of spams, while also completely melting down some targeted network. There will be very little evidence indicating how the attack is happening. The domains being queried or their victims might not be found in any message. > And it won't surprise me if some SPF implementations already have a > "NXDOMAIN processing limit" to catch your convoluted attempts based > on malicious MX records. In in the libraries I reviewed, many don't even limit the number of targets being accessed. What is a good limit for NXDOMAINs for SPF scripts? How can it be determined whether these scripts have been upgraded? Change the version of the script? Wildcard MX or SPF records could be the next ploy, where the game continues unabated. This SPF attack is virtually free to the attacker thanks to SPF's macro features. Why not simply authenticate the SMTP client and then associate various originating domains? One transaction and absolutely _no_ risk to the Internet. > Terminate policies with "+all" is also bullshit, the fastest way to > get a PASS for any IP is to use only "v=spf1 +all". Of course > that's a really bad idea for somebody planning to stay on a white > list, but some spammers might like the cheap PASS. bell.ca. "v=spf1 mx ip4:198.235.69.10 ip4:198.235.69.45 ip4:198.235.69.46 ip4:206.47.0.168 ip4:206.47.0.173 ip4:206.47.0.177 ip4:207.236.237.0/25 ip4:67.70.214.43 ip4:216.18.99.22 ip4:69.156.197.234 ip4:66.241.131.163 +all" The goal could be to list the IP addresses being used without SPF causing messages to be mysteriously lost, or to encourage use of very dangerous SPF script parsers. Executing script from anonymous sources is a basic problem. It is clear that MAAWG's Sender policy does not care about DDoS problem either. It can't always be about avoiding complaints and making money. Validate the SMTP client and this problem disappears. A simple scheme for associating domains provides a safe means for registering paths or authorizations of DKIM signatures. Providers must be willing to be held directly accountable for the messages they send by name. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 19:56:01 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgVq-0002gM-RD; Fri, 09 Feb 2007 19:54:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgVq-0002gH-4R for asrg@ietf.org; Fri, 09 Feb 2007 19:54:46 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFgVo-0004Pu-QT for asrg@ietf.org; Fri, 09 Feb 2007 19:54:46 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l1A0sgq04231 for ; Fri, 9 Feb 2007 19:54:42 -0500 (EST) Received: from [47.9.28.46] ([47.9.28.46] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 19:54:41 -0500 Message-ID: <45CD17CB.10503@nortel.com> Date: Fri, 09 Feb 2007 19:54:35 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <82DC29B0-3543-4F56-A6A4-0E0CBBDF2A50@mail-abuse.org> <45CCE4FC.3090402@nortel.com> <3E29692B-316A-4A67-8291-68AACAABC772@mail-abuse.org> In-Reply-To: <3E29692B-316A-4A67-8291-68AACAABC772@mail-abuse.org> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2007 00:54:42.0242 (UTC) FILETIME=[0C946220:01C74CAE] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Douglas Otis wrote: > Those offering a free service are not likely concerned about earning > DNSBLs a bad reputation, especially they are bombarded by an ill > considered scheme designed to keep the SMTP client nameless. Those offering a free service do everyone else trying/using the same thing a grave disservice by screwing up. > There is a similar conversation on nanog about maps.vix.com. > Here is a link to a possible solution. Look closer, Doug. It's the same solution. It should be, because the guy who introduced it in that posting to NANOG, is the same person who introduced it where we saw it ;-) _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 20:01:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgc5-0004v3-L7; Fri, 09 Feb 2007 20:01:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgc4-0004ul-7a for asrg@ietf.org; Fri, 09 Feb 2007 20:01:12 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFgc3-0005ta-12 for asrg@ietf.org; Fri, 09 Feb 2007 20:01:12 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l1A115m28553 for ; Fri, 9 Feb 2007 20:01:06 -0500 (EST) Received: from [47.9.28.46] ([47.9.28.46] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Feb 2007 20:01:05 -0500 Message-ID: <45CD194D.8020300@nortel.com> Date: Fri, 09 Feb 2007 20:01:01 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <82DC29B0-3543-4F56-A6A4-0E0CBBDF2A50@mail-abuse.org> <45CCE4FC.3090402@nortel.com> <3E29692B-316A-4A67-8291-68AACAABC772@mail-abuse.org> <45CD17CB.10503@nortel.com> In-Reply-To: <45CD17CB.10503@nortel.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Feb 2007 01:01:05.0867 (UTC) FILETIME=[F13CE9B0:01C74CAE] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Chris Lewis wrote: > Look closer, Doug. It's the same solution. > > It should be, because the guy who introduced it in that posting to > NANOG, is the same person who introduced it where we saw it ;-) Whoops, not quite, it takes into account that you shouldn't put IPs in NS records. A worked example like the NANOG one using 127 addresses would perhaps be best for the BCP. Should touch base with Jon to see why he used 192.0 instead of 127. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 20:14:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgmk-0005FW-Un; Fri, 09 Feb 2007 20:12:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFgmk-0005FP-0m for asrg@ietf.org; Fri, 09 Feb 2007 20:12:14 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFgmi-0007Zm-LO for asrg@ietf.org; Fri, 09 Feb 2007 20:12:13 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1A1CBlS003925 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Feb 2007 17:12:12 -0800 In-Reply-To: <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Fri, 9 Feb 2007 17:12:10 -0800 To: Matt Sergeant X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 8, 2007, at 8:44 PM, Matt Sergeant wrote: > On 8-Feb-07, at 11:21 PM, Douglas Otis wrote: > >>> I don't get the idea of an arbitrary magic number "6 months". >>> For a list with say bogon IPs it would be "as long as necessary", >>> unlimited. You address this later, but IMO no fixed limit also >>> here is clearer. >> >> Frank is right. 6 months does not make much sense. > > Please re-respond in light of my response to Frank here. > "6 months is reasonable for a long listing, and this is very well > covered by the last point in this section - that a temporary > listing can easily be extended by (for example) receiving more spam > from this IP/range." Listing intervals depend upon several factors. One might be related to who manages the ASN. Regularly enabling dormant IP addresses within a large, poorly managed network would be a very bad choice. What is the justification for 6 months? A period that represents typical IP ownership is not likely 6 months. Many of these systems are compromised and can be retasked to send spam once the IP address drops off a popular block list. How is 6 months reasonable for a long listing? Why not state a goal rather than setting some arbitrary period not based upon any information or rationale. >> --- >> 2.1.3. An Audit Trail SHOULD Be Maintained. >> >> A DNSBL SHOULD maintain an audit trail for all listings and SHOULD >> make it publicly available in an easy to find location, preferably >> on the DNSBL's web site. Please note that making audit trail data >> public does not entail revealing all information in the DNSBL >> administrator's possession relating to the listing; e.g., a DNSBL >> administrator MAY make the audit trail data selectively accessible >> in such a way that spam trap addresses are not disclosed. >> --- >> >> It is not possible to disclose _any_ email information without >> also disclosing where the message was obtained. It is simply >> impossible to fully redact a message to provide such an assurance >> of non-disclosure. > > Hence why this is a SHOULD not a MUST. It's a tricky line - compare > for example the disclosure given by PSBL (almost full spamtrap hit > contents) vs SBL. Both presumably maintain an internal audit trail, > but one is public and one is private, but both are reasonably well > run DNSBLs. Publicly listed messages likely represent a sacrificial source. There lies the rub. What happens when a spammer has an above average IQ? Your listed, but we can show you why? -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 20:29:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFh2P-00077M-4j; Fri, 09 Feb 2007 20:28:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFh2M-00077G-W4 for asrg@ietf.org; Fri, 09 Feb 2007 20:28:22 -0500 Received: from mail48.messagelabs.com ([193.109.255.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HFh2L-00021k-Iz for asrg@ietf.org; Fri, 09 Feb 2007 20:28:22 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-10.tower-48.messagelabs.com!1171070899!954353!3 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 17323 invoked from network); 10 Feb 2007 01:28:19 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-10.tower-48.messagelabs.com with SMTP; 10 Feb 2007 01:28:19 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Feb 2007 01:28:18 +0000 Received: (qmail 6038 invoked from network); 10 Feb 2007 01:28:18 -0000 Received: from unknown (HELO ?10.100.0.149?) (10.100.0.149) by matt?dev.int.star.co.uk with SMTP; 10 Feb 2007 01:28:18 -0000 In-Reply-To: <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Fri, 9 Feb 2007 20:28:02 -0500 To: Douglas Otis X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Feb 2007 01:28:18.0855 (UTC) FILETIME=[BE931B70:01C74CB2] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 9-Feb-07, at 8:12 PM, Douglas Otis wrote: >> "6 months is reasonable for a long listing, and this is very well >> covered by the last point in this section - that a temporary >> listing can easily be extended by (for example) receiving more >> spam from this IP/range." > > Listing intervals depend upon several factors. One might be > related to who manages the ASN. Regularly enabling dormant IP > addresses within a large, poorly managed network would be a very > bad choice. What is the justification for 6 months? We decided to pick an upper limit. We picked the most respected DNSBL (Spamhaus' SBL) to give us that limit - 6 months (for ROKSO SBL listings). A spamhaus listing will drop off if the ROKSO spammer stops spamming for 6 clear months. Remember we're not saying you have to wait the 6 months before re- checking listing criteria. If the event (e.g. spamming) re-occurs before that six months is up (say at month 3) you reset the timeout period. So a spammer suspends spamming from an IP for 6 months to wait out the timeout just to start spamming again, and you think that would be a bad thing? Frankly I think the internet community would be glad of the 6 month reprieve (and of course the subsequent relisting). > A period that represents typical IP ownership is not likely 6 > months. Many of these systems are compromised and can be retasked > to send spam once the IP address drops off a popular block list. > How is 6 months reasonable for a long listing? Why not state a > goal rather than setting some arbitrary period not based upon any > information or rationale. The goal is stated. If it needs to be clarified we should do that. >>> It is not possible to disclose _any_ email information without >>> also disclosing where the message was obtained. It is simply >>> impossible to fully redact a message to provide such an assurance >>> of non-disclosure. >> >> Hence why this is a SHOULD not a MUST. It's a tricky line - >> compare for example the disclosure given by PSBL (almost full >> spamtrap hit contents) vs SBL. Both presumably maintain an >> internal audit trail, but one is public and one is private, but >> both are reasonably well run DNSBLs. > > Publicly listed messages likely represent a sacrificial source. > There lies the rub. What happens when a spammer has an above > average IQ? Your listed, but we can show you why? Do you have an objection to this point being a SHOULD? Clearly DNSBLs maintain and even display audit trails and retain effectiveness. I'm lost by your argument here. The point of this section is that an audit trail is a valuable thing when there's a complaint about a listing, or some other issue, so even if it's not public the audit trail really should exist. I sincerely hope you're not suggesting that the MAPS dnsbl's don't maintain audit trails, even if they're not publicly available. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 21:03:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFha0-00042d-RJ; Fri, 09 Feb 2007 21:03:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFhZz-00042V-AJ for asrg@ietf.org; Fri, 09 Feb 2007 21:03:07 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFhZx-0008QJ-IT for asrg@ietf.org; Fri, 09 Feb 2007 21:03:07 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1A234Dg019574 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 9 Feb 2007 18:03:04 -0800 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Fri, 9 Feb 2007 18:03:03 -0800 To: Matt Sergeant X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 9, 2007, at 5:28 PM, Matt Sergeant wrote: > On 9-Feb-07, at 8:12 PM, Douglas Otis wrote: > >>> "6 months is reasonable for a long listing, and this is very well >>> covered by the last point in this section - that a temporary >>> listing can easily be extended by (for example) receiving more >>> spam from this IP/range." >> >> Listing intervals depend upon several factors. One might be >> related to who manages the ASN. Regularly enabling dormant IP >> addresses within a large, poorly managed network would be a very >> bad choice. What is the justification for 6 months? > > We decided to pick an upper limit. We picked the most respected > DNSBL (Spamhaus' SBL) to give us that limit - 6 months (for ROKSO > SBL listings). A spamhaus listing will drop off if the ROKSO > spammer stops spamming for 6 clear months. Spamhaus is a very good organization. The fact they use 6 months does not mean everyone should use 6 months. For those using multiple lists, having different intervals increases protection when policies vary. There are a vast number of IP addresses controlled by bad actors where playing a waiting game would be made easier when DSNBL operators standardize this rather fundamental criteria. Not stating this interval has much more merit than stating it would ever have. What problem is being solved? Those managing the list will likely adopt policies that minimize the administration of the list in most cases. The draft already says that repeated occurrences can exponentially extend this interval. Would an occurrence within the same 6 months be counted as one? Does the IP address need to be removed from the list before repeated offenses are counted? > Remember we're not saying you have to wait the 6 months before re- > checking listing criteria. If the event (e.g. spamming) re-occurs > before that six months is up (say at month 3) you reset the timeout > period. > > So a spammer suspends spamming from an IP for 6 months to wait out > the timeout just to start spamming again, and you think that would > be a bad thing? Frankly I think the internet community would be > glad of the 6 month reprieve (and of course the subsequent relisting). When nothing has changed with respect to the IP address ownership, why not apply intervals according to the general management of the address space, rather than a pedantic treatment of each IP address individually? >> A period that represents typical IP ownership is not likely 6 >> months. Many of these systems are compromised and can be retasked >> to send spam once the IP address drops off a popular block list. >> How is 6 months reasonable for a long listing? Why not state a >> goal rather than setting some arbitrary period not based upon any >> information or rationale. > > The goal is stated. If it needs to be clarified we should do that. DNSBL operators should mimic Spamhaus policies? Don't suggest there is some magic period. >>>> It is not possible to disclose _any_ email information without >>>> also disclosing where the message was obtained. It is simply >>>> impossible to fully redact a message to provide such an >>>> assurance of non-disclosure. >>> >>> Hence why this is a SHOULD not a MUST. It's a tricky line - >>> compare for example the disclosure given by PSBL (almost full >>> spamtrap hit contents) vs SBL. Both presumably maintain an >>> internal audit trail, but one is public and one is private, but >>> both are reasonably well run DNSBLs. >> >> Publicly listed messages likely represent a sacrificial source. >> There lies the rub. What happens when a spammer has an above >> average IQ? Your listed, but we can show you why? > > Do you have an objection to this point being a SHOULD? Clearly > DNSBLs maintain and even display audit trails and retain > effectiveness. I'm lost by your argument here. The point of this > section is that an audit trail is a valuable thing when there's a > complaint about a listing, or some other issue, so even if it's not > public the audit trail really should exist. An audit trail should exist. There are considerations not covered in this draft about what can be made public. Those considerations should be included. This could brace users when they hear something that they don't want to hear. "I can't show you the message." > I sincerely hope you're not suggesting that the MAPS dnsbl's don't > maintain audit trails, even if they're not publicly available. Don't worry, we are keeping storage companies in business. : ) -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 21:19:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFhnl-0007Nf-CW; Fri, 09 Feb 2007 21:17:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFhnj-0007Na-QK for asrg@ietf.org; Fri, 09 Feb 2007 21:17:19 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFhni-0004SX-8i for asrg@ietf.org; Fri, 09 Feb 2007 21:17:19 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HFhnb-0007bR-6x for asrg@ietf.org; Sat, 10 Feb 2007 03:17:11 +0100 Received: from d254119.dialin.hansenet.de ([80.171.254.119]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Feb 2007 03:17:11 +0100 Received: from nobody by d254119.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Feb 2007 03:17:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Sat, 10 Feb 2007 03:12:26 +0100 Organization: Lines: 120 Message-ID: <45CD2A0A.79F0@xyzzy.claranet.de> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <82DC29B0-3543-4F56-A6A4-0E0CBBDF2A50@mail-abuse.org> <45CCF247.610C@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: d254119.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Subject: [Asrg] Re: 100:11 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Douglas Otis wrote: > There are also TXT records that may accompany the A record. > Often this indicates a contact method. If you're talking about TXT records accompanying DNSBL listings they're generally URLs, the exp= in SPF is a similar idea. > Whatever gets used must be robust against DDoS attack without > costing a fortune. Other solutions might be more effective, > so why rule them out. URLs are fine, they work for everybody, and you don't need I18N considerations for http, it's a solved problem. I'm a "whois" fan, but there are cases where "http" has a few advantages. >> Comparing the size of the message with the size of the final >> queries is bogus. > The attacker is sending spam anyway. Even email traffic should > not be considered part of the attack overhead. This means the > amplification is actually much much greater! No, it means you've to compare queries answered by the attacker with queries sent to the victim. And that's a factor 9 with mx- mechanisms in SPF, no matter what the attacker does. > The SPF macro language allows the same SPF script to utilize > local-part elements of an email address There's no such thing as "SPF scripts". You've enumerated the macros in your PDF, they're all derived from the input IP, the checked address, and the HELO identity. The PTR stuff might appear to be a bit obscure, but actually it is what any MTA checking reverse DNS does, once per session. And completely unusable for any kind of attack. > The MX records and their targets then enjoy the difference > between a negative cache TTL Whatever they enjoy or not, there's a limit of ten names per MX record in SPF evaluations. With different local parts the attacker can cause queries to different bogus MX records on his own server (per mail). So he got rid of 1 of 11 queries sent to his own server, if it's the same cached SPF policy. He still has to answer the ten MX queries, each with 10 names in the domain of the victim. But in your PDF you say a*b*c*d, one of that is used local parts, another is recipients per mail. With an assumption that all recipients check SPF at their MUA, clearly against a recommendation in RFC 4408. Ingnoring that - the number of local parts and recipients is still irrelevant for the amplification of at most 10 queries per MX. The attacker can drop the complete SPF business and try to abuse "call back verification". > Queries are randomized by the local-part as needed. Attacking > queries will not be found within an cache. This is not nonsense. The "randomized" stuff are mx:%{l}.attacker.example mechanisms, queries to the attacker. One of your a*b*c*d factors was the number of recipients of the same mail, the same local part. > The attacker will still be able to send the same number of > spams, while also completely melting down some targeted network. While combining spam with DDoS attacks might be a fine art, I'd pick a more direct approach and try to either spam or DDoS, not some combo depending on an unknown number of recipients checking SPF behind their border MX, against several SHOULDs in RFC 4408. > In in the libraries I reviewed, many don't even limit the number > of targets being accessed. What is a good limit for NXDOMAINs > for SPF scripts? Evaluation => library. SPF policies aren't affected by your convoluted attack recipes, nobody uses ten mx-mechanism each with ten names, and implementations were always encouraged (SHOULD) to limit their efforts in addition to the MUST limits. No working policy needs to be "upgraded", talking about many non-existing names in MX records was and is always a bad idea. > Why not simply authenticate the SMTP client and then associate > various originating domains? The recommended SPF HELO check comes before the MAIL FROM checks. If you don't like the latter you can still do the former, it has the nice feature to work everywhere, not only at the border. Of course receivers could impose their own rules on HELO without checking what the alleged sender proposes. But receivers trying to follow the RFC 2821 rules might like a kind of permission to be stricter offered in a "v=spf1 a -all" or similar policy. > bell.ca. "v=spf1 mx ip4:198.235.69.10 ip4:198.235.69.45 > ip4:198.235.69.46 ip4:206.47.0.168 ip4:206.47.0.173 ip4:206.47.0.177 > ip4:207.236.237.0/25 ip4:67.70.214.43 ip4:216.18.99.22 > ip4:69.156.197.234 ip4:66.241.131.163 +all" A bogus policy, so what ? Anybody can claim to be HELO bell.ca or to send MAIL FROM: > The goal could be to list the IP addresses being used without > SPF causing messages to be mysteriously lost SPF doesn't lose mails mysteriously. A FAIL detected at the border is simply rejected. The policy shown above will attract spammers to abuse bell.ca whereever it pleases them. If their goal is to publish obscure lists of IPs they better dont't use "v=spf1", they could say "our ips" without "+all" at the end. > Executing script from anonymous sources is a basic problem. Yes, fortunately SPF is no script, although you apparently argue that MX records are a fundamental security problem. Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 09 22:17:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFiia-0003Xi-Rm; Fri, 09 Feb 2007 22:16:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFiiZ-0003Wq-QC for asrg@ietf.org; Fri, 09 Feb 2007 22:16:03 -0500 Received: from bigsky.scconsult.com ([66.73.230.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFiiW-0003VM-Uy for asrg@ietf.org; Fri, 09 Feb 2007 22:16:03 -0500 Received: from bigsky.scconsult.com (localhost [127.0.0.1]) by bigsky.scconsult.com (Postfix) with ESMTP id E3DAA4130AE for ; Fri, 9 Feb 2007 22:15:59 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <45CD194D.8020300@nortel.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <82DC29B0-3543-4F56-A6A4-0E0CBBDF2A50@mail-abuse.org> <45CCE4FC.3090402@nortel.com> <3E29692B-316A-4A67-8291-68AACAABC772@mail-abuse.org> <45CD17CB.10503@nortel.com> <45CD194D.8020300@nortel.com> X-Message-Flag: Use of Microsoft mail clients is the primary cause of cracked systems. Please switch! Date: Fri, 9 Feb 2007 22:15:57 -0500 To: asrg@ietf.org From: Bill Cole Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org At 8:01 PM -0500 2/9/07, Chris Lewis imposed structure on a stream of electrons, yielding: >Chris Lewis wrote: > >> Look closer, Doug. It's the same solution. >> >> It should be, because the guy who introduced it in that posting to >> NANOG, is the same person who introduced it where we saw it ;-) > >Whoops, not quite, it takes into account that you shouldn't put IPs in >NS records. A worked example like the NANOG one using 127 addresses >would perhaps be best for the BCP. Should touch base with Jon to see >why he used 192.0 instead of 127. I believe his idea is that it would always go out on the wire for any machine instead of into the possibly less uniform world of loopback handling. I am not sure that makes a significant difference, except that in some environments the packet on the wire to a 192.0.2/24 address will elicit an explicit response rather than go off into nowhere, while on many (most?) hosts a packet to a 127/8 address other than 127.0.0.1 will stay on the machine and get no response. On the good side, a lot of packets aimed at 192.0.2/24 on a path through default gateways may be noticeable to someone who can slap the mail admin to attention. -- Bill Cole bill@scconsult.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Feb 10 01:48:21 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFlzT-0005rH-GP; Sat, 10 Feb 2007 01:45:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFlzT-0005rC-20 for asrg@ietf.org; Sat, 10 Feb 2007 01:45:43 -0500 Received: from fr6.webmaillogin.com ([216.40.35.70] helo=webmaillogin.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFlzR-0002Un-6M for asrg@ietf.org; Sat, 10 Feb 2007 01:45:43 -0500 Received: from [76.187.176.198] (account gep2a@terabites.com) by bk3.webmaillogin.com (CommuniGate Pro WebUser 5.0.9) with HTTP id 5683589 for asrg@ietf.org; Sat, 10 Feb 2007 01:47:51 -0500 From: Subject: Re: [Asrg] How do we do something about spam? To: asrg@ietf.org X-Mailer: CommuniGate Pro WebUser v5.0.9 Date: Sat, 10 Feb 2007 00:47:51 -0600 Message-ID: In-Reply-To: References: X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format="flowed" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.2 (/) X-Scan-Signature: bc751b94b9e719c152b6b70b67620ccf X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org [blocking executable attachments] >> And that is really rather easy... you simply block any >> HTML or attachments (and particularly EXECUTABLE >> attachments) that isn't coming from a sender that is >>known >> and trusted by the recipient TO SEND THEM EXECUTABLE >> CONTENT. > > Pray tell, how am _I_ to block the executable content >from some dialup > luser on level3's machine? All _I_ can do is block his >emissions from > _my_ machine. What one does is to block incoming messages based on a fine-grained whitelist, and with a default for non-whitelisted senders which is at least "safe" (no attachments, no HTML, less than some maxmium size). Instead of a gross no-nogo whitelist, the whitelist would list which features would be expected (and allowed) in E-mails from familiar and trusted senders. After that initial triage, the remaining E-mails would still be checked by a SpamAssassin-type content filter (which could actually do a quite respectable job, given that text-as-image, embedded links, scripting, and most all the other classic spammer tricks would be simply ineffective. >> Note that MOST users (probably 98-99%) will not >>whitelist >> ANYBODY to send them executable content in E-mails...! > > Are you considering .jpg to be executable? No, although that could be its own whitelist/permissions category. I wouldn't allow ANY image types for non-whitelisted senders, mainly because that allows spammers to send "text as image" to avoid content scanning. >> The other way that botnets are recruited are by people >> visiting infectious Web sites, but that is a problem for >>a >> different list. > > But the *spam* emitted by those machines _is_ a problem >for this list. Absolutely. But if we put measures into effect to make one very unlikely to ever get their machine infected via an incoming E-mail, then we can hugely reduce spambot recruitment. [next comment] > Subject: [Asrg] please disregard message from me sent to >asrg list by accident > My apologies. Can't go trusting >"autocomplete" to always do the > right thing. I wonder if the fellow who is working on > per-correspondent statistical > profiles will incorporate flagging for confirmation of >outbounds as > well that do not > match what is normally sent _to_ a peer: that feature >might have helped in this > case. While outbound spam detection might be useful at an ISP it's not likely to make a big dent in spam, simply because spammers either avoid the ISP's restricted mail servers or because they don't use a traditional ISP at all. Also note that some "customers" represent a large array of subusers (say, a Starbuck's). One can't reasonably expect those E-mail messages to resemble each other...! [next comment] >[...at the risk of giving spammers new idea, what if] >there is a > stealth virus that watches who you send executable >attachments to and > every once in a while attaches itself to one of those >emails by > infecting the application that you are already sending? The fact is that very few folks, Internet-wise, ever send legitimate executable files as attachments to anybody. And few people will ever whitelist ANYBODY to send them executable attachments (or similarly dangerous ActiveX or scripting etc). Those people (and they are a sizeable majoirty of the folks on the net, I believe) will basically NEVER get any E-mail viruses or worms. Those who DO expect to get E-mail messages containing executables from their correspondents are probably also savvy enough (most of them, at least) to not be taken in by bogus messages pretending to be something they are not. Now, it is certainly possible that a rogue program COULD corrupt a (say) compilation, so an in-theory-clean program was in fact infected BEFORE SENDING. But again, we've still put a MAJOR crimp in virus/worm distribution, and if we do that well enough the spammers will give up on that venue (much like they've mostly given up on boot sector viruses on floppies). >> Note that MOST users (probably 98-99%) will not >>whitelist ANYBODY >> to send them executable content in E-mails...! > > From a quick survey, I would say that 90% of the >participants on > this list don't even consider it a possibility that a >silly windows > virus in an email attachment could infect their machine. Sure, if you're running a (say) Alpha processor or some such, or for that matter if you're using an IBM mainframe for your E-mails, then a Windows virus isn't going to do much to you. On the other hand, most of the participants on this list are a whole lot more savvy anyhow than the folks who are most likely to get their machines infected. That's why it's not at all adequate to build defenses into (say) Exchange; they need to be in Outlook and Outlook Express (for example) so that the great unwashed masses will have (and use) those defenses. >Most of the > rest would be adequately protected. Some though may >actively seek the > viruses so they can disassemble them. But then, this >isn't a typical > user population. And those who wish to receive them for such research purposes could simply ignore the warnings and enable them. Again, they probably aren't the problem areas for zombie recruitment. > A substantial portion of the net user population are >actively > exchanging executable files. Sure, and some people don't use condoms, either. That doesn't mean that we should do anything to enable or promote that sort of unsafe behavior. > I even get the occasional >executable > file from my dad forwarded through a long chain of >friends. He > complains sometimes about not being able to open them at >home but > forwards them to his office where they will run. Obviously that's evidence of malfeasance by his office's system admins. When I get such a "long list of forwards" of executables, I generally look at who sent it to me, see if it looks like they INTENDED to send it (or was it a hostile alien bot from their machine which sent it?), etc etc. And even then, I tend to put it in my "zoo" (critter quarantine) folder, for several months and then may eventually check it out if nothing has indicated a problem with the file based on other, less cautious recipients. >> The other way that botnets are recruited are by people >>visiting >> infectious Web sites, but that is a problem for a >>different list. > > There are lots of other vectors for passing malicious >code to > machines willing to suck it in. Perhaps, but in any case OUR task here is dealing with E-mail. Our charter is not "the infinitely robust operating system". Not that that's a bad thing, but it's not really our problem HERE, at the moment. > But I don't believe in blocking legitimate activity to >stop a few > criminals that also use that activity. The point is that you're not "blocking" ANYTHING that the recipient wants to receive. That's because the recipient can whitelist anybody they like to send them any kind of content they like. It only just says that (probably bogus) mail from unknown/untrusted senders will be quarantined and probably never released. > If an ISP can >block executable > attachments in the "hope" of preventing a users machine >from getting > infected I don't propose that the filtering be done by the ISP, although the principle certainly doesn't preclude the filtering from being done at the ISP, but (again) under the specific direction (perhaps the default one) set by the individual recipient. > then they can just as easily unplug that users >machine from > the net IF it gets infected and starts abusing the net. The problem is that even an infected machine might still need to send occasional, legitimate E-mail messages. They also might need access to the Net to locate and download disinfection software, etc. Disconnecting a computer from the Net is not a good solution, IMHO. >If an ISP > wants to be proactive they could supply anti-virus tools >like a Linux > installer for their customers. Many of the bigger ISPs DO provide antispam software, but antispam software (with few exceptions) only identifies and blocks KNOWN exploits. Most viruses are at their most dangerous and prolific BEFORE they are recognized by ANY antispam program. The nice thing about what I propose is that most folks would simply never receive an E-mail virus ever again, even if they didn't update their viruses defenses for many years. No more daily/weekly/monthly updates of virus signatures. [next comment] >> ...a FAR better solution (rather >>than >> attempting to block spam AFTER the botnets are >>recruited) >> is to block the virus/worm code-containing E-mail >>messages >> BEFORE they infect those computers. >> > Ideally. On the other hand, that option is often not in >our hands. I believe it is probably desirable to implement such a filter at the RECIPIENT, either at the recipient's ISP, or at the recipient's machine itself. ISPs can recommend solutions. >> And that is really rather easy... you simply block any >> HTML or attachments (and particularly EXECUTABLE >> attachments) that isn't coming from a sender that is >>known >> and trusted by the recipient TO SEND THEM EXECUTABLE >> CONTENT. >> > Recipients are very often not in a position to make that >judgement. And by default, executable attachments would be disabled from delivery to most users. They could re-enable that (or other dangerous stuff) but only after being warned about the hazards, and why they should not do so unless they know EXACTLY what they are doing and WHY they are doing it, etc. > Also, how many of those trojans spread via browser >exploits, spyware, or > other similar techniques? Some, surely. But our charter HERE isn't really "Web browser safety", that's really an issue for another group. Meanwhile, I still believe that eliminating E-mail as a vector for virus/worm distribution will ENORMOUSLY help both the virus/worm problem, AND the spam problem. > The email exploit vector is >mostly focussing > on getting people to visit websites rather than actual >distribution of > exploit code. Sometimes yes, sometimes no. Increasingly, Web browsers are being configured out-of-the-box to not run executable content without checking with the user, first. (And that process could probably be improved further). > Now the idea of suing people who allow their hosts to >stay infected is > one I like. A few headline making cases and we *might* >have results. I don't think that suing other victims is ultimately a very good solution to the problem. [next comment] >> simple... I know that a lot of y'all have this fixation >>on >> IP-based solutions, ... > The reason people have a fixation on IP-based, or >signature-based > identification mechanisms is simple. > > Without a guarantee of 'identity', you can't whitelist >someone. Well, you certainly can't whitelist them on the basis of IP address; I might send E-mails during my vacation from a cruise ship Internet cafe or from a post office Internet E-mail center above a post office in Beijing. What matters more isn't the IP address, it's whether I send E-mail that still looks like what I send to a specific recipient. And I don't even think it really matters all that much whether we have a "guarantee of identity" anyhow, although it might be nice (if it's possible without major inconvenience). > You'll > end up adding a whitelist entry which viruses will forge >mail from in > order to get to your inbox. Viruses on some other machine will probably not know what YOUR whitelist permissions are based on. And individual recipients are likely to have different whitelist permissions anyhow. The result is a twisty and narrow path which is difficult for a virus or worm to navigate through. I'm not saying that it's impossible that viruses won't suddenly be more specific about whose From: addresses they forge (say, Borland or Symantec or someone that 'more' users might otherwise trust to send them executable attachment). But most viruses won't know WHICH recipients are set up to receive THAT sort of content from THAT E-mail address. > A whitelist is simply an end-user accredited reputation >service. Like > all reputation mechanisms, it makes no sense if the >entity being queried > for can not be proven to be the same as the one being >vouched for. I disagree that "it makes no sense". I don't believe that it HAS to be 100.0000% perfect. I think it basically has to be good enough that spammers and worm authors decide their time is better invested doing something else. [next comment] > There should be a generalized rule to not automatically >process > information from unknown sources. Processing includes >fetching images, > running scripts, validating digital signatures, and >verifying IP address > authorization (especially when this might require >hundreds of > transactions). I think that's one reasonable interpretation. Things which COULD be dangerous, or which are commonly used to avoid antispam content scanning, ought to simply be considered "a priori" evidence of hostile intent if it hasn't been negotiated and cleared with the individual recipient in advance. > Such a rule will not expose internal >handling and > minimizes risks associated with DDoS attacks. Yes. > Only when a _trusted_ source has been verified, should >the message be > annotated. A recipient's address book could be one >method of > determining a trusted domain where out-of-band >verification techniques > can be employed. I don't think it's probably necessary (or even desirable) to use more elaborate "verification techniques". I might be visiting a friend and need to send one of MY E-mail messages from HIS machine. That shouldn't cause any grief, really. > A means to correlate DKIM domains with that of a >verified SMTP client > could permit DKIM serving as a basis of acceptance. I believe that vanity or personal domains should be able to be used from inhabitual locations. That's why I believe these sorts of 'verified SMTP client' stuff is misguided. (It's neither necessary nor suffient to determine 'spamminess"). [next comment] >> The reason people have a fixation on IP-based, or >>signature-based >> identification mechanisms is simple. There is an old adage among programmers... "Software should be as simple as posssible, BUT NO SIMPLER!!!" [next comment] > Put another way, zombie botnets are the enabling >technology of spam > (phishing, etc.) > > Easier said than done I realize, but it's inherently >illegal to create > and operate zombie botnets, and I don't mean just in the >US, most > anywhere on the planet. [snip] > It's as if I could make this message appear in 100 >million mailboxes > in the next few hours, despite many efforts to the >contrary. > > I couldn't. You couldn't. > > It takes a zombie botnet. > > There are other issues, but I'm focusing on this one as >the most > egregious and, I hope, easiest to agree on in terms of >contribution to > the problem and legal/moral unambiguity. I agree... it is much harder to get the spam problem under control simply because of spambot recruitment. And I don't think it's all that hard to take a BIG bite out of that. [next comment] > By making spam illegal, the act of transmitting a high >volume of > unsolicited messages would then clearly serve as >evidence of crime. Right, but probably not on the part of the OWNER of that infected machine. He is probably just another innocent victim himself. > This would place accountability onto the provider. The >efforts > behind SPF and DKIM are aimed at passing blame to a >hapless > customer. Thousand of domains might share an SPF >authorized server > which is likely to have only a few IP addresses. An example would be a domain provider like Domain Direct or GoDaddy. But as a customer of EACH of those, I still could be traveling and need to send a message (using MY domain name) from a cruise ship Internet cafe or post office E-mail kiosk. I have NO control over which SMTP server processes my message. > Making spam illegal would make networks many orders of >magnitude safer. CAN-SPAM has done REMARKABLY little to cut down on spamming. I think a far better solution is simply to allow the recipient to efficiently refuse mail they don't want, or don't trust. > Make a law that requires >providers sign all > public messages with their own keys. There should even >be laws that > prohibit signing with a customer's key. So what about mailing lists, such as Yahoogroups? > Customers can >reference > specific keys used on their behalf instead. There >should be laws > against the use of highly danger authorization schemes, >such as SPF/ > Sender-ID. I think SPF is a very poor solution. > Poisoning or destroying DNS is easily >accomplish with > this loathsome technology. A technology also aimed at >side stepping > accountability. I don't like SPF either. >> There is no other way we know of to send out on the >>order of one >> billion emails per day for a cost which even approaches >>the >> expected value of those messages and would so >>successfully evade >> already commonplace blocking and filtering methods. >> >> Does anyone disagree with that? > > Enforcement must make any spam illegal AND hold >providers > accountable. I don't think "providers" have all that much control. > To ensure enforcement, allow anyone >damaged to seek > legal relief. Talk about encouraging rampant lawsuits. (What happens when the spammers THEMSELVES sue as if they are the injured party...??!) > There are few providers that want to consider their >accountability as > part of the cost of doing business. No one can afford >to clean up > the mess being made. The way that spam will ultimately be controlled is by making it hard enough that it's more trouble than it's worth. > Content or intent do not need to be considered. The >volume and lack > of solicitation provides key differences. I'll provide a counter-example. A manufacturer does not "solicit" customer service E-mails (well, at least not from specific, known consumers). They still need to be able to receive e-mails (at least of "limited" types) from previously unknown-to-them senders. >The lack of >solicitation > allows for rather easy methods of enforcement. One >grows weary > logging trespasses that can only be considered privately >as bad. I think legal means are ultimately problematical because of the indeterminate jurisdictions involved. What's more, the problem can be solved adequately without lawyers and courts. > Those making these private assessments remain exposed to >civil > proceeding as a result. Spam must be illegal to stop >it. I disagree. Among other things, it is VERY difficult to prove in a court of law WHO caused the spam to be sent. People will stop sending spam when it ceases to be worthwhile. [next comment] > Providers must control access, block abusers, and be >held accountable > when they fail to do so. When someone spams, they must >be blocked. So you block Aunt Matilda because her machine got infected. Now what? > Sending volumes of unsolicited messages is rather easy >to detect, How do you know (and prove) that they are unsolicited? > where > miscreants can be blocked quickly. When this traffic is >from customers > using compromised systems, then each problematic >customer's outbound > messages must be blocked. I don't think that must be done. I believe my approach allows them to continue to send legitimate mail, and allows an effective triage of legitimate from illegitimate mail. > Of course, the next concern might be malware placed in >websites, even > things like Wikipedia might contain malware. There must >be efforts made > to ensure blogs are properly defanged as well. Agreed, but that is a separate issue than OUR charter HERE. I am concerned about E-MAIL as a vector. [next comment] > Make spam illegal and hold providers accountable >instead. Who do you sue? How do you prove who caused the spam to be sent? What court has jurisdiction? Who has to pay the lawyers involved? Gordon Peterson http://personal.terabites.com 1977-2007 Thirty year anniversary of local area networking _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Feb 10 04:28:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFoUp-0002Fr-0n; Sat, 10 Feb 2007 04:26:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFoUo-0002Fm-FR for asrg@ietf.org; Sat, 10 Feb 2007 04:26:14 -0500 Received: from mail2.panix.com ([166.84.1.73]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFoUn-0006r2-VZ for asrg@ietf.org; Sat, 10 Feb 2007 04:26:14 -0500 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail2.panix.com (Postfix) with ESMTP id CFECFCACC5 for ; Sat, 10 Feb 2007 04:26:02 -0500 (EST) Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id l1A9Q2k26581; Sat, 10 Feb 2007 04:26:02 -0500 (EST) Date: Sat, 10 Feb 2007 04:26:02 -0500 (EST) Message-Id: <200702100926.l1A9Q2k26581@panix5.panix.com> From: Seth Breidbart To: asrg@ietf.org In-reply-to: (gep2@terabites.com) Subject: Re: [Asrg] How do we do something about spam? References: X-Spam-Score: 0.0 (/) X-Scan-Signature: b5299d0955d21ceeb18e25a232290fec X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org wrote: [blocking executable attachments] >> Pray tell, how am _I_ to block the executable content from some >>dialup luser on level3's machine? All _I_ can do is block his >>emissions from _my_ machine. > What one does is to block incoming messages based on a > fine-grained whitelist, and with a default for > non-whitelisted senders which is at least "safe" (no > attachments, no HTML, less than some maxmium size). Most spam I get fits that criteria. Therefore, it won't do me much good. If I could stop the level3 luser from getting infected, that would help a lot more; but any solution that requires _everybody_ to do something is mentioned in the FUSSP pages. >> Are you considering .jpg to be executable? > > No, But it is, at least with many viewers and a properly-malformed .jpg file. >> But the *spam* emitted by those machines _is_ a problem >>for this list. > > Absolutely. But if we put measures into effect to make > one very unlikely to ever get their machine infected via > an incoming E-mail, then we can hugely reduce spambot > recruitment. See FUSSP. I can block stuff from very few machines. All of us together [tinaout] can block stuff from a lot of machines, but still a very small percentage of the Internet. > While outbound spam detection might be useful at an ISP > it's not likely to make a big dent in spam, simply because > spammers either avoid the ISP's restricted mail servers or > because they don't use a traditional ISP at all. Blocking outgoing Port 25 makes it hard to bypass the ISP's (or someone else's) servers. > But again, we've still put a MAJOR crimp in virus/worm > distribution, Are you sure that infected websites aren't currently a bigger factor than email viruses? > and if we do that well enough the spammers > will give up on that venue (much like they've mostly given > up on boot sector viruses on floppies). How much good has it done that they've given up on boot sector viruses in floppies? >> A substantial portion of the net user population are actively >>exchanging executable files. > > Sure, and some people don't use condoms, either. That > doesn't mean that we should do anything to enable or > promote that sort of unsafe behavior. ISPs that don't allow their customers to do what those customers want tend to become ex-ISPs. > I don't propose that the filtering be done by the ISP, > although the principle certainly doesn't preclude the > filtering from being done at the ISP, but (again) under > the specific direction (perhaps the default one) set by > the individual recipient. And by the fifth time the recipient has to whitelist somebody he's going to say "the hell with this waste of effort" and whitelist *. >> then they can just as easily unplug that users machine from the net >>IF it gets infected and starts abusing the net. > > The problem is that even an infected machine might still > need to send occasional, legitimate E-mail messages. I don't care. > They also might need access to the Net to locate and download > disinfection software, etc. That's what sandboxes are for. Hijack all connections to the ISP's disinfection site. > Disconnecting a computer from the Net is not a good > solution, IMHO. It works for me. That computer stops sending me spam. > Meanwhile, I still believe that eliminating E-mail as a > vector for virus/worm distribution will ENORMOUSLY help > both the virus/worm problem, AND the spam problem. How much did eliminating boot sector virus propagation accomplish toward those goals? >> The email exploit vector is mostly focussing on getting people to >>visit websites rather than actual distribution of exploit code. > > Sometimes yes, sometimes no. Increasingly, Web browsers > are being configured out-of-the-box to not run executable > content without checking with the user, first. (And that > process could probably be improved further). And how many users are immune to social engineering? > I don't think that suing other victims is ultimately a > very good solution to the problem. You prefer to let them stay connected and continue to spew. >> You'll end up adding a whitelist entry which viruses will forge >>mail from in order to get to your inbox. > > Viruses on some other machine will probably not know what > YOUR whitelist permissions are based on. They don't care. They'll find that you get mail from X, and forge mail from X. Eventually, they'll hit an X you've whitelisted. > And individual recipients are likely to have different whitelist > permissions anyhow. The result is a twisty and narrow path which is > difficult for a virus or worm to navigate through. See "flood distribution". > I don't think it's probably necessary (or even desirable) > to use more elaborate "verification techniques". I might > be visiting a friend and need to send one of MY E-mail > messages from HIS machine. That shouldn't cause any > grief, really. So if you're whitelisted, any virus that claims to be you coming from anywhere gets through on your whitelist entry. There goes protection. > I believe that vanity or personal domains should be able > to be used from inhabitual locations. Mine can be used from anywhere: I know how to ssh. (There's also SUBMIT and other such verified protocols.) > I agree... it is much harder to get the spam problem under > control simply because of spambot recruitment. > > And I don't think it's all that hard to take a BIG bite > out of that. Come back when you've actually done that and tell us how hard it was. At that point, you'll have some credibility. >> By making spam illegal, the act of transmitting a high volume of >>unsolicited messages would then clearly serve as evidence of crime. > > Right, but probably not on the part of the OWNER of that > infected machine. He is probably just another innocent > victim himself. He isn't innocent. See "attractive nuisance". > An example would be a domain provider like Domain Direct > or GoDaddy. But as a customer of EACH of those, I still > could be traveling and need to send a message (using MY > domain name) from a cruise ship Internet cafe or post > office E-mail kiosk. I have NO control over which SMTP > server processes my message. Then you aren't sufficiently competent to be trusted with email. My email comes from Panix's mailservers, whether I'm at home, at some random hotel (like now), in some airport lounge, or anywhere else. >> Making spam illegal would make networks many orders of >>magnitude safer. > > CAN-SPAM has done REMARKABLY little to cut down on > spamming. The major effect of They-CAN-SPAM was to prevent California from actually making spam illegal. > I think a far better solution is simply to allow the > recipient to efficiently refuse mail they don't want, or > don't trust. They already can, they don't need your (or my) "allowing". Ever hear the saying "My server, my rules"? >> Make a law that requires providers sign all public messages with >>their own keys. There should even be laws that prohibit signing >>with a customer's key. > > So what about mailing lists, such as Yahoogroups? What about them? Yahoo can sign them (and pass on the signatures of whoever sent the mail to yahoo). >> Customers can reference specific keys used on their behalf instead. >>There should be laws against the use of highly danger authorization >>schemes, such as SPF/ Sender-ID. There should be laws against making stupid suggestions about what there should be laws against. (Oops) > I think SPF is a very poor solution. I think it's a good solution to a specific problem (which isn't spam). >> Poisoning or destroying DNS is easily accomplish with this >>loathsome technology. What are you talking about? I have SPF set up for some of my domains; I haven't noticed any destruction of DNS. >> A technology also aimed at side stepping accountability. How is me stating that only specific IPs are authorized to send mail from my domains "side stepping accountability"? I would think it makes me _more_ accountable for mail I actually send, and less for mail forged to appear from me. Do you think I should be accountable for mail forgery done by a spammer if he happens to choose me as his victim this hour? >> Enforcement must make any spam illegal AND hold providers >>accountable. > > I don't think "providers" have all that much control. They have all the power, hence as much control as they want. >> To ensure enforcement, allow anyone damaged to seek legal relief. > > Talk about encouraging rampant lawsuits. (What happens > when the spammers THEMSELVES sue as if they are the > injured party...??!) You mean like they do now? They lose. > The way that spam will ultimately be controlled is by > making it hard enough that it's more trouble than it's > worth. There's no permanent victory in an arms race. > A manufacturer does not "solicit" customer service E-mails > (well, at least not from specific, known consumers). Yes, they do, by their very nature. > I think legal means are ultimately problematical because > of the indeterminate jurisdictions involved. What's more, > the problem can be solved adequately without lawyers and > courts. Like it has been? Your FUSSP doesn't seem to be working. >> Spam must be illegal to stop it. > > I disagree. > > Among other things, it is VERY difficult to prove in a > court of law WHO caused the spam to be sent. No, it isn't, for someone competent. And if everyone along the chain is considered responsible, proving _some_ of it is easy. >> Providers must control access, block abusers, and be held >>accountable when they fail to do so. When someone spams, they must >>be blocked. > > So you block Aunt Matilda because her machine got > infected. Now what? Now I don't get any spam from your Aunt Matilda. I think that's a good thing. >> Sending volumes of unsolicited messages is rather easy >>to detect, > > How do you know (and prove) that they are unsolicited? The recipients say so, and the sender can't prove otherwise. >> When this traffic is from customers using compromised systems, >>then each problematic customer's outbound messages must be blocked. > > I don't think that must be done. I believe my approach > allows them to continue to send legitimate mail, and > allows an effective triage of legitimate from illegitimate > mail. I don't know why you think a spam zombie sending me plaintext 419's is legitimate mail. > I am concerned about E-MAIL as a vector. But apparently not about spam per se. >> Make spam illegal and hold providers accountable instead. > > Who do you sue? The provider. > How do you prove who caused the spam to be sent? That's the point: I don't have to. I prove the spam came to me from somewhere in Southern Bell's network, and therefore Southern Bell is responsible. If they want to turn around and sue their customer or instrument their network to catch incoming infections, that's fine with me. Now they'll have an _incentive_ to, and to block infected customers. > What court has jurisdiction? Whichever one the law says. > Who has to pay the lawyers involved? Whatever the law says. Seth _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sat Feb 10 20:40:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG3c4-0000Xp-7g; Sat, 10 Feb 2007 20:34:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG3c2-0000TD-GT for asrg@ietf.org; Sat, 10 Feb 2007 20:34:42 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG3c1-0003po-Pu for asrg@ietf.org; Sat, 10 Feb 2007 20:34:42 -0500 Received: from [192.168.2.40] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1B1YcGR030412 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Sat, 10 Feb 2007 17:34:38 -0800 Subject: Re: [Asrg] Re: 100:11 From: Douglas Otis To: asrg@ietf.org In-Reply-To: <45CD2A0A.79F0@xyzzy.claranet.de> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <82DC29B0-3543-4F56-A6A4-0E0CBBDF2A50@mail-abuse.org> <45CCF247.610C@xyzzy.claranet.de> <45CD2A0A.79F0@xyzzy.claranet.de> Content-Type: text/plain Date: Sat, 10 Feb 2007 17:34:38 -0800 Message-Id: <1171157678.3123.526.camel@dcore.sonic.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Sat, 2007-02-10 at 03:12 +0100, Frank Ellermann wrote: > Douglas Otis wrote: > >> Comparing the size of the message with the size of the final > >> queries is bogus. > > > The attacker is sending spam anyway. Even email traffic should > > not be considered part of the attack overhead. This means the > > amplification is actually much much greater! > > No, it means you've to compare queries answered by the attacker > with queries sent to the victim. And that's a factor 9 with mx- > mechanisms in SPF, no matter what the attacker does. SPF records staging an attack may have very long TTLs and utilize local-part components of an email-address for generating subsequent DNS transactions. The macro expansion of SPF scripts allows the _same_ record to generate different attacking transactions. SPF macro expansion of local-part elements into subsequent DNS transactions is a tremendous gift provided to an attacker. This macro expansion feature eliminates further consumption of an attacker's resources. SPF allows attacks to be virtually free and impossible to stop or defend against. Nonexistent targets of MX records is just _one_ means to stage an SPF facilitated attack. Your calculations continue to overlook the likely difference between the TTL of the MX record versus the negative cache TTL of bogus target A records, and the advantages obtained from label compression. Once the negative caching period has elapsed, the attack sequence can then reuse seeded MX records published with long TTLs. Such an attack can continue for hours, where the overhead needed to seed the sequence will be fairly small in comparison, and can be neglected. > > The SPF macro language allows the same SPF script to utilize > > local-part elements of an email address > > There's no such thing as "SPF scripts". SPF records will often appear completely meaningless without input parameters and their related macro expansion. SPF records include commands that transform character strings, reorder label sequences, mix different elements of the various input parameters, overlay DNS transactions with CIDR masks, test existence of A records, include or redirect the processing of a series of SPF record transactions, etcetera, etcetera. Describing SPF as anything less that a scripting language would be a misrepresentation. While this language is limited, it provides powerful capabilities that can effectively stage DDoS attacks or greatly assist in poisoning DNS caches. > You've enumerated the macros in your PDF, they're all derived from the > input IP, the checked address, and the HELO identity. The checked "address" could be for the PRA. The script might be run once again for the MailFrom, and perhaps one more time for a DKIM domain. Limits established for SPF processes are for each "address" being independently checked. The PRA, MAILFROM and DKIM domains represent a possibility for a long list of names checked per message. > The PTR stuff might appear to be a bit obscure, but actually it > is what any MTA checking reverse DNS does, once per session. > And completely unusable for any kind of attack. I agree. Validating just the SMTP client is unlikely to result in dangerous amplifications. However, SPF scripts attempt to collect addresses used by _all_ SMTP clients that might be utilized by an originating domain. A safe way to associate thousands of different SMTP clients with that of some originating domain would be by "named reference". This can be done within one small and safe transaction. Alas, this is far from true with SPF's demand for an entire IP address set. > > The MX records and their targets then enjoy the difference > > between a negative cache TTL > > Whatever they enjoy or not, there's a limit of ten names per > MX record in SPF evaluations. Many SPF script parsers fail to limit even the number of names resolved in MX records. Even so, there are ten MX records being processed with perhaps 10 or more targets each. > With different local parts the attacker can cause queries to different > bogus MX records on his own server (per mail). So he got rid of 1 of > 11 queries sent to his own server, if it's the same cached SPF policy. This would be true only the _first_ time the MX record is used. > He still has to answer the ten MX queries, each with 10 names > in the domain of the victim. Label compression unfortunately works in favor of an attacker, in addition to differences between negative caching TTLs and the TTL of the MX records. MX records can be reused without causing added overhead for the attacker after negative caching of its bogus targets have expired. This is what was meant by "seeding" the attack, and why the calculations still underestimate the risk. > But in your PDF you say a*b*c*d, one of that is used local parts, > another is recipients per mail. With an assumption that all > recipients check SPF at their MUA, clearly against a recommendation in > RFC 4408. This number includes all MSAs (including MUAs). Where is the recommendation against checking SPF at the MUA in RFC 4408? Here is the _only_ text mentioning MUAs: 2.4. Checking Authorization ... Typically, such checks are done by a receiving MTA, but can be performed elsewhere in the mail processing chain so long as the required information is available and reliable. 2.5.5. SoftFail ... The domain owner wants to discourage the use of this host and thus desires limited feedback when a "SoftFail" result occurs. For example, the recipient's Mail User Agent (MUA) could highlight the "SoftFail" status, or the receiving MTA could give the sender a message using a technique called "greylisting" whereby the MTA can issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the first time the message is received, but accept it the second time. 8.1. Macro Definitions ... The "r" macro expands to the name of the receiving MTA. This SHOULD be a fully qualified domain name, but if one does not exist (as when the checking is done by a MUA) or if policy restrictions dictate otherwise, the word "unknown" SHOULD be substituted. The domain name may be different from the name found in the MX record that the client MTA used to locate the receiving MTA. 10.2. SPF-Authorized E-Mail May Contain Other False Identities The "MAIL FROM" and "HELO" identity authorizations must not be construed to provide more assurance than they do. It is entirely possible for a malicious sender to inject a message using his own domain in the identities used by SPF, to have that domain's SPF record authorize the sending host, and yet the message can easily list other identities in its header. Unless the user or the MUA takes care to note that the authorized identity does not match the other more commonly-presented identities (such as the From: header field), the user may be lulled into a false sense of security. Section 10.2 even seems to require SPF checking be done at the MUA. Prohibitions of MUA checking is not within the security consideration section either. It has not stopped MUA plugins like Spamassassin, or those for Thunderbird, Outlook or Outlook express either. To quote Wietse Venema: "Junk mail is war. RFCs do not apply." > Ignoring that - the number of local parts and recipients is > still irrelevant for the amplification of at most 10 queries > per MX. The attacker can drop the complete SPF business and > try to abuse "call back verification". Don't ignore label compression (where nefarious tricks might also be used), and of course, the differences between negative caching and the TTL of reused MX RRs. Greatly extending negative caching will create other problems. Whether there are random queries for bogus MX, SPF, or A records, the attack is made virtually free with SPF. Why would someone want to expose themselves by attacking using other methods, when SPF allows the attacker to completely hide, where even logs are not likely to assist in tracing the source of the virtually free attack? > > Queries are randomized by the local-part as needed. Attacking > > queries will not be found within an cache. This is not nonsense. > > The "randomized" stuff are mx:%{l}.attacker.example mechanisms, > queries to the attacker. One of your a*b*c*d factors was the > number of recipients of the same mail, the same local part. In the MX record attack example, the "random" query would likely repeat after a negative caching period. Other attacks may never need to repeat and would still not expend any of the attacker's resources beyond the initial record queries. > > The attacker will still be able to send the same number of > > spams, while also completely melting down some targeted network. > > While combining spam with DDoS attacks might be a fine art, I'd > pick a more direct approach and try to either spam or DDoS, not > some combo depending on an unknown number of recipients checking > SPF behind their border MX, against several SHOULDs in RFC 4408. A direct attack would expose which systems are compromised. Direct attacks provide valuable information, especially for those wanting this information. The baseline of the example attack starts at 508 Kbit/msg where the message would be sent anyway. Use of SPF script parsers is easily detected by bad actors, where recipients using SPF script parsers are made well known. The macro language of SPF even facilitates this canvassing effort as well. > > In in the libraries I reviewed, many don't even limit the number > > of targets being accessed. What is a good limit for NXDOMAINs > > for SPF scripts? > > Evaluation => library. SPF policies aren't affected by your > convoluted attack recipes, nobody uses ten mx-mechanism each with > ten names, and implementations were always encouraged (SHOULD) to > limit their efforts in addition to the MUST limits. No working > policy needs to be "upgraded", talking about many non-existing > names in MX records was and is always a bad idea. Sigh. The attack is staged by a bad actor. The bad actor creates the MX records with perhaps 20 or more victim targets. Many of the SPF script parsers will attempt to resolve all targets for each of the 10 MX records. They might attempt to do this once for the PRA, and when that fails, attempt to do this again for the MAILFROM. There might even be another attempt to process one or more DKIM domains. Each MAILFROM and DKIM script can happily end with '+all'. > > Why not simply authenticate the SMTP client and then associate > > various originating domains? > > The recommended SPF HELO check comes before the MAIL FROM checks. > > If you don't like the latter you can still do the former, it has > the nice feature to work everywhere, not only at the border. Of > course receivers could impose their own rules on HELO without > checking what the alleged sender proposes. But receivers trying > to follow the RFC 2821 rules might like a kind of permission to > be stricter offered in a "v=spf1 a -all" or similar policy. Alas, v=spf1 does not provide a scope definition nor would this prevent bad actors from listing all scopes. SPF represents an extreme danger for the Internet as a whole. > > bell.ca. "v=spf1 mx ip4:198.235.69.10 ip4:198.235.69.45 > > ip4:198.235.69.46 ip4:206.47.0.168 ip4:206.47.0.173 ip4:206.47.0.177 > > ip4:207.236.237.0/25 ip4:67.70.214.43 ip4:216.18.99.22 > > ip4:69.156.197.234 ip4:66.241.131.163 +all" > > A bogus policy, so what ? Anybody can claim to be HELO bell.ca > or to send MAIL FROM: This allows the listing of IP addresses to permit white-listing by those providers who _insist_ on using SPF records for this purpose, such as AOL. This was the reason given for the comment made in the presentation. > > The goal could be to list the IP addresses being used without > > SPF causing messages to be mysteriously lost > > SPF doesn't lose mails mysteriously. A FAIL detected at the > border is simply rejected. The policy shown above will attract > spammers to abuse bell.ca where ever it pleases them. If their > goal is to publish obscure lists of IPs they better dont't use > "v=spf1", they could say "our ips" without "+all" at the end. Some MTAs may check SPF before issuing DSNs. Acceptance may have been based upon the PRA, where the DSN checking might occur after a message has been forwarded, and thereby rejected. These messages may then mysteriously vanish as a result. SPF offers virtually no recipient protection, as it often checks unseen headers. SPF can not be safely applied at the MUA, however there are those who will try such an unsafe practice. SPF/Sender-ID is simply unsafe from several perspectives. Providers should adopt conventions for using APL records (RFC3123), and avoid using TXT records altogether, especially SPF records. > Executing script from anonymous sources is a basic problem. > > Yes, fortunately SPF is no script, although you apparently argue > that MX records are a fundamental security problem. No, the macro capability of the SPF script language is a _security_ threat! Scripts often accept input parameters and remain in their original form. When run, scripts are then "interpreted" a "command" at a time. This definition becomes clearer after substituting "mechanism" and "macro" used by SPF for the word "command". SPF is truly a scripting language. Why say otherwise? -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Sun Feb 11 23:22:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGSco-00024g-Q1; Sun, 11 Feb 2007 23:17:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGScn-0001zZ-5p for asrg@ietf.org; Sun, 11 Feb 2007 23:17:09 -0500 Received: from main.gmane.org ([80.91.229.2] helo=ciao.gmane.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGScl-0003Z1-Dt for asrg@ietf.org; Sun, 11 Feb 2007 23:17:09 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HGSca-0001P3-VD for asrg@ietf.org; Mon, 12 Feb 2007 05:16:56 +0100 Received: from du-001-047.access.de.clara.net ([212.82.227.47]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Feb 2007 05:16:56 +0100 Received: from nobody by du-001-047.access.de.clara.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 12 Feb 2007 05:16:56 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: asrg@ietf.org From: Frank Ellermann Date: Mon, 12 Feb 2007 05:03:44 +0100 Organization: Lines: 93 Message-ID: <45CFE720.4AB1@xyzzy.claranet.de> References: <17856.62286.468183.171586@world.std.com> <20070131215235.9381.qmail@simone.iecc.com> <17857.9992.58654.806936@world.std.com> <3B6ADE70-B1CF-459F-AFA5-49B3B2A60F50@mail-abuse.org> <45C21084.3CF2@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-047.access.de.clara.net X-Mailer: Mozilla 3.0 (OS/2; U) X-Spam-Score: 0.5 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Subject: [Asrg] Re: How about we do something about spam? X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Douglas Otis wrote: > SPF does not protect the HELO as checking is optional Please look up RFC 2119 OPTIONAL / MAY vs. RECOMMENDED / SHOULD. For checkers trying to figure out an empty MAIL FROM:<> it was always required to use the HELO identity. And no, there are no SPF policies for domain literals, checkers would report a result NONE in this and similar cases. > SPF does not prevent bounces sent to those that did not send > the message without also reducing email's delivery integrity. That's not the case, "reject any FAIL at your border" is the very idea of RMX (one of SPF's predecessors). > Few SPF records have settings that operate in this mode as a > result. Folks are free to publish records only enumerating PASSing IPs, if they can't or don't wish to decide what to do with the rest of the world. There are various scenarios where that can be a good choice. I leave your DKIM "ideas" for DKIM experts here. > SPF expects recipients to not only check an MX record, but to > resolve the addresses for each target within an MX record and > to do this ten times over. As far as the policy uses an mx mechanism, and there are 10 MXs. In reality SPF is about _sending_ IPs, using the mx mechanism is already unusual, because it's about MTAs _receiving_ mails for the domain in question. Using 10 MXs is far more unusual, after all the name server for the domain would like to answer a query=mx without TCP. Ideally including the relevant IPs, avoiding additional questions. MTAs having trouble with query=mx would be also quite unusual. > Instead, verify the host of the SMTP client Yes, that's the first step, see above. > then check for domain associations using a single DNS > transaction. This would be far safer in comparison. That doesn't work for domains using more than one mail provider to send their mails. All my ISPs would ask me what I'm smoking if I'd propose to "associate" their outbound MTAs with a domain xyzzy.dnsalias.org or similar. On the other hand I could in theory associate this domain with their services using SPF include:first.isp.example (etc.) For your idea it would be more straight forward to revive 821 reverse routes, but unfortunately that failed a giggle test. >> Great, Can-Spam, legal enforcement, and RFC 3865 to the rescue. >> Is that a new all-time low in the history of the IRTF-ASRG ? > Spam must be made illegal. There should be no need for RFC3865, > or for legal provisions that say it is okay to spam provided your > message has a link that allows opting-out of this line of products. A good part of the spam I get has opt-out links, nobody uses this. It would be also hopeless to opt-out all local parts of a domain. As you wrote later "opt-out" doesn't work. > There should be an international agreement that bulk sending > of unsolicited messages is illegal. Until that exists and works I'm more interested in the technical sides of the spam problem. Or of "misdirected bounces" wrt SPF and 2821bis. IANAL and all. > Spam would end very quickly, and infections rates would decline. From an IETF POV RFC 3865 offers anything that's needed for this kind of legal FUSSP. > RFCs should be aimed at identifying who is _transmitting_ the > messages first. If it's an SPF FAIL it wasn't xyzzy.claranet.de, problem solved as far as I'm concerned. Similar GMane where I post this message. And if it's an SPF PASS it's either me, or a problem between me, my ISP, and another user of this ISP (= none of your problems) - they can add op=auth to their policy when they are ready for it. Frank _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Feb 12 12:23:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGeqZ-0001ra-5q; Mon, 12 Feb 2007 12:20:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGeqT-0001nE-C4 for asrg@ietf.org; Mon, 12 Feb 2007 12:20:05 -0500 Received: from bodger.sergeant.org ([62.173.71.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HGenu-0006M2-Ke for asrg@ietf.org; Mon, 12 Feb 2007 12:17:29 -0500 Received: (qmail 10845 invoked by uid 510); 12 Feb 2007 17:17:11 -0000 Received: from bas2-kitchener06-1096651761.dsl.bell.ca (HELO [192.168.2.11]) (65.93.147.241) by bodger.sergeant.org (qpsmtpd/0.28) with ESMTP; Mon, 12 Feb 2007 17:17:11 +0000 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Mon, 12 Feb 2007 12:16:37 -0500 To: Douglas Otis X-Mailer: Apple Mail (2.752.3) X-Qpsmtpd-Auth: True X-Spam-Status: unknown X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 9-Feb-07, at 9:03 PM, Douglas Otis wrote: >>> A period that represents typical IP ownership is not likely 6 >>> months. Many of these systems are compromised and can be >>> retasked to send spam once the IP address drops off a popular >>> block list. How is 6 months reasonable for a long listing? Why >>> not state a goal rather than setting some arbitrary period not >>> based upon any information or rationale. >> >> The goal is stated. If it needs to be clarified we should do that. > > DNSBL operators should mimic Spamhaus policies? Don't suggest > there is some magic period. Our belief: There needs to be a sensible maximum time of listing should the entry no longer meet the listing criteria. We think 6 months is a sensible maximum. This BCP is in NO WAY suggesting that an IP/range shouldn't ever be listed for longer than 6 months, but that if your listing criteria is no longer met then the entry should time out after a maximum of 6 months. Clearly we can state this better. I'll try and get Nick to use something from the above paragraph. >>> Publicly listed messages likely represent a sacrificial source. >>> There lies the rub. What happens when a spammer has an above >>> average IQ? Your listed, but we can show you why? >> >> Do you have an objection to this point being a SHOULD? Clearly >> DNSBLs maintain and even display audit trails and retain >> effectiveness. I'm lost by your argument here. The point of this >> section is that an audit trail is a valuable thing when there's a >> complaint about a listing, or some other issue, so even if it's >> not public the audit trail really should exist. > > An audit trail should exist. There are considerations not covered > in this draft about what can be made public. Those considerations > should be included. This could brace users when they hear > something that they don't want to hear. "I can't show you the > message." Good point. How about: A DNSBL SHOULD maintain an audit trail for all listings and it is RECOMMENDED that it is made publicly available in an easy to find location, preferably on the DNSBL's web site. Please note that making audit trail data public does not entail revealing all information in the DNSBL administrator's possession relating to the listing; e.g., a DNSBL administrator MAY make the audit trail data selectively accessible in such a way as to not disclose information that might assist spammers, such as the contents of an email received by the DNSBL's spam trap. Matt. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Feb 12 13:24:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGfoT-0007m0-M3; Mon, 12 Feb 2007 13:22:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGfoS-0007lt-Cp for asrg@ietf.org; Mon, 12 Feb 2007 13:22:04 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGfoP-0007of-1A for asrg@ietf.org; Mon, 12 Feb 2007 13:22:04 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l1CILw518442 for ; Mon, 12 Feb 2007 13:21:58 -0500 (EST) Received: from [47.129.150.3] ([47.129.150.3] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 13:21:40 -0500 Message-ID: <45D0B031.9080506@nortel.com> Date: Mon, 12 Feb 2007 13:21:37 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: ASRG Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Feb 2007 18:21:40.0672 (UTC) FILETIME=[A41B9C00:01C74ED2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Matt Sergeant wrote: > On 9-Feb-07, at 9:03 PM, Douglas Otis wrote: > >>>> A period that represents typical IP ownership is not likely 6 >>>> months. Many of these systems are compromised and can be retasked >>>> to send spam once the IP address drops off a popular block list. >>>> How is 6 months reasonable for a long listing? Why not state a goal >>>> rather than setting some arbitrary period not based upon any >>>> information or rationale. >>> >>> The goal is stated. If it needs to be clarified we should do that. >> >> DNSBL operators should mimic Spamhaus policies? Don't suggest there >> is some magic period. > > Our belief: There needs to be a sensible maximum time of listing should > the entry no longer meet the listing criteria. > > We think 6 months is a sensible maximum. This BCP is in NO WAY > suggesting that an IP/range shouldn't ever be listed for longer than 6 > months, but that if your listing criteria is no longer met then the > entry should time out after a maximum of 6 months. > > Clearly we can state this better. I'll try and get Nick to use something > from the above paragraph. Good idea. I can see that that section is being misunderstood. > >>>> Publicly listed messages likely represent a sacrificial source. >>>> There lies the rub. What happens when a spammer has an above >>>> average IQ? Your listed, but we can show you why? >>> >>> Do you have an objection to this point being a SHOULD? Clearly DNSBLs >>> maintain and even display audit trails and retain effectiveness. I'm >>> lost by your argument here. The point of this section is that an >>> audit trail is a valuable thing when there's a complaint about a >>> listing, or some other issue, so even if it's not public the audit >>> trail really should exist. >> >> An audit trail should exist. There are considerations not covered in >> this draft about what can be made public. Those considerations should >> be included. This could brace users when they hear something that >> they don't want to hear. "I can't show you the message." > > Good point. How about: > > A DNSBL SHOULD maintain an audit trail for all listings and it is > RECOMMENDED that it is made publicly available in an easy to find > location, preferably on the DNSBL's web site. Please note that > making audit trail data public does not entail revealing all > information in the DNSBL administrator's possession relating to the > listing; e.g., a DNSBL administrator MAY make the audit trail data > selectively accessible in such a way as to not disclose information > that might assist spammers, such as the contents of an email received > by the DNSBL's spam trap. I like. Just change the last "the" to "a". _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Feb 12 14:00:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGgPR-0002Xx-O5; Mon, 12 Feb 2007 14:00:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGgPP-0002VW-N8 for asrg@ietf.org; Mon, 12 Feb 2007 14:00:15 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGgPN-0005W8-4s for asrg@ietf.org; Mon, 12 Feb 2007 14:00:15 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1CJ09jx010329 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Feb 2007 11:00:10 -0800 In-Reply-To: <45CFE720.4AB1@xyzzy.claranet.de> References: <17856.62286.468183.171586@world.std.com> <20070131215235.9381.qmail@simone.iecc.com> <17857.9992.58654.806936@world.std.com> <3B6ADE70-B1CF-459F-AFA5-49B3B2A60F50@mail-abuse.org> <45C21084.3CF2@xyzzy.claranet.de> <45CFE720.4AB1@xyzzy.claranet.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68139010-8639-4EBD-A6E4-3E785AAACF0B@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: How about we do something about spam? Date: Mon, 12 Feb 2007 11:00:12 -0800 To: Frank Ellermann X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.5 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 11, 2007, at 8:03 PM, Frank Ellermann wrote: > Douglas Otis wrote: > >> SPF does not protect the HELO as checking is optional > > Please look up RFC 2119 OPTIONAL / MAY vs. RECOMMENDED / SHOULD. > For checkers trying to figure out an empty MAIL FROM:<> it was > always required to use the HELO identity. Nothing prevents bad actors from including a throw-away domain within MAILFROM to bypass most HELO checks. The recipient might also use Sender-ID procedures that ignore both HELO and even MAILFROM when a PRA has been confirmed. > And no, there are no SPF policies for domain literals, checkers > would report a result NONE in this and similar cases. The DKIM-DOSP draft accommodates even IP literals with a "named reference" authorization scheme. There should be a convention added to authorize domains below SMTP Client host-names. For example, an SMTP client host-name "mx-01.example.com" should first induce a check for "example.com". >> SPF does not prevent bounces sent to those that did not send the >> message without also reducing email's delivery integrity. > > That's not the case, "reject any FAIL at your border" is the very > idea of RMX (one of SPF's predecessors). When messages can not be delivered to forwarded accounts, that might be seen as reducing email's delivery integrity. When there is a possible risk that a PRA provides acceptance, and then MAILFROM qualifies DSNs, this might cause messages to vanish. >> Few SPF records have settings that operate in this mode as a result. > > Folks are free to publish records only enumerating PASSing IPs, if > they can't or don't wish to decide what to do with the rest of the > world. There are various scenarios where that can be a good > choice. I leave your DKIM "ideas" for DKIM experts here. Advocating use of SPF checking at email borders gives bad actors a resource free method for indirectly DDoS attacking any domain. >> SPF expects recipients to not only check an MX record, but to >> resolve the addresses for each target within an MX record and to >> do this ten times over. > > As far as the policy uses an mx mechanism, and there are 10 MXs. > > In reality SPF is about _sending_ IPs, using the mx mechanism is > already unusual, because it's about MTAs _receiving_ mails for the > domain in question. Using 10 MXs is far more unusual, after all > the name server for the domain would like to answer a query=mx > without TCP. Ideally including the relevant IPs, avoiding > additional questions. > > MTAs having trouble with query=mx would be also quite unusual. Some domains approach the 10 MX RR limits. The concept of including 10 separate SPF records is not only due limitations in the TXT RR size, but that different domains might be employed. Some SPF scripts default to an MX/24 answer and assume outbound systems are often numerically close to inbound systems. While some MTA may confirm the existence of an MX RR, how many resolve all MTA target addresses, and then do this 10 times over? SPF allows bad actors to embed this behavior for millions of emails sent by responding to just the initial DNS queries. Once it becomes clear the spam will be sent anyway, SPF simply offers a virtually free method to stage a DDoS attack against any domain. >> Instead, verify the host of the SMTP client > > Yes, that's the first step, see above. Too bad this is optional, and encumbered with a DDoS risk when using SPF/Sender-ID. >> then check for domain associations using a single DNS >> transaction. This would be far safer in comparison. > > That doesn't work for domains using more than one mail provider to > send their mails. All my ISPs would ask me what I'm smoking if I'd > propose to "associate" their outbound MTAs with a domain > xyzzy.dnsalias.org or similar. Actually a "named reference" works even when there are millions of different providers for an originating domain. The provider does not offer the authorization for the originating domain. These domains might be found anywhere within the message. This might be the MAILFROM, From, Sender, Resent-*. Each field could have a different "named reference" authorization. Which authorization is checked depends upon which originator is being trusted. To use DNS, the authorization is located within each originating domain. Originating domains can "authorize" HELOs or even DKIM signatures. There are no limits in the number of domains that can be authorized in this manner. The "named reference" check involves a safe, single, small DNS transaction. > On the other hand I could in theory associate this domain with > their services using SPF include:first.isp.example (etc.) > > For your idea it would be more straight forward to revive 821 > reverse routes, but unfortunately that failed a giggle test. You misunderstand the suggestion. The scheme only requires a convention for where the "named reference" labels are placed within the originating domain. This does not require anything as complex as reverse routes, etc. The originating domain would directly list all authorized domains. >>> Great, Can-Spam, legal enforcement, and RFC 3865 to the rescue. >>> Is that a new all-time low in the history of the IRTF-ASRG ? >> >> Spam must be made illegal. There should be no need for RFC3865, >> or for legal provisions that say it is okay to spam provided your >> message has a link that allows opting-out of this line of products. > > A good part of the spam I get has opt-out links, nobody uses this. > It would be also hopeless to opt-out all local parts of a domain. > As you wrote later "opt-out" doesn't work. Agreed. It is not safe to use Opt-Out links, and as structured in the CAN-SPAM law, it does not ensure this response does not cause even more spam. Clicking on the Opt-Out link acknowledges a level of ignorance with respect to browser security. Browser security remains a primary weak link, but spam remains a primary infection vector for these exploits. Spam must be made illegal. >> There should be an international agreement that bulk sending of >> unsolicited messages is illegal. > > Until that exists and works I'm more interested in the technical > sides of the spam problem. Or of "misdirected bounces" wrt SPF and > 2821bis. IANAL and all. While I agree with your goals, SPF is simply not safe. >> Spam would end very quickly, and infections rates would decline. > > From an IETF POV RFC 3865 offers anything that's needed for this > kind of legal FUSSP. You might be right, but I find this hard to believe. >> RFCs should be aimed at identifying who is _transmitting_ the >> messages first. > > If it's an SPF FAIL it wasn't xyzzy.claranet.de, problem solved as > far as I'm concerned. Similar GMane where I post this message. > > And if it's an SPF PASS it's either me, or a problem between me, my > ISP, and another user of this ISP (= none of your problems) - they > can add op=auth to their policy when they are ready for it. In theory, you would be right, although this will likely cause some of your messages to not be delivered when forwarded. In practice, this is an extremely dangerous mechanism for a DDoS standpoint that should not be employed. This approach can be changed to utilize a single "named reference" instead. When a "named reference" is used in conjunction with DKIM, even forwarded messages will not be lost, even those signed by your "authorized" provider. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Feb 12 14:11:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGgaJ-00019m-EH; Mon, 12 Feb 2007 14:11:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGgaI-00019e-4S for asrg@ietf.org; Mon, 12 Feb 2007 14:11:30 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGgaG-0007F8-Nx for asrg@ietf.org; Mon, 12 Feb 2007 14:11:30 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1CJBRCm017172 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Feb 2007 11:11:28 -0800 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Mon, 12 Feb 2007 11:11:31 -0800 To: Matt Sergeant X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 12, 2007, at 9:16 AM, Matt Sergeant wrote: > On 9-Feb-07, at 9:03 PM, Douglas Otis wrote: > >>>> A period that represents typical IP ownership is not likely 6 >>>> months. Many of these systems are compromised and can be >>>> retasked to send spam once the IP address drops off a popular >>>> block list. How is 6 months reasonable for a long listing? Why >>>> not state a goal rather than setting some arbitrary period not >>>> based upon any information or rationale. >>> >>> The goal is stated. If it needs to be clarified we should do that. >> >> DNSBL operators should mimic Spamhaus policies? Don't suggest >> there is some magic period. > > Our belief: There needs to be a sensible maximum time of listing > should the entry no longer meet the listing criteria. > > We think 6 months is a sensible maximum. This BCP is in NO WAY > suggesting that an IP/range shouldn't ever be listed for longer > than 6 months, but that if your listing criteria is no longer met > then the entry should time out after a maximum of 6 months. 6 months is not a sensible maximum in may cases. If an interval must be mentioned, why not say a year or less. A year is likely to be a typical interval for service purchases. Most spam sources are compromised systems. Increasing the block cycle rate will just increase the number of times a compromised system can spew spam before being once again blocked. When the owner of the IP address actually wants to send valid email, they can make a request to expedite a removal process in most cases. What makes 6 months sound reasonable???? > Clearly we can state this better. I'll try and get Nick to use > something from the above paragraph. > >>>> Publicly listed messages likely represent a sacrificial source. >>>> There lies the rub. What happens when a spammer has an above >>>> average IQ? Your listed, but we can show you why? >>> >>> Do you have an objection to this point being a SHOULD? Clearly >>> DNSBLs maintain and even display audit trails and retain >>> effectiveness. I'm lost by your argument here. The point of this >>> section is that an audit trail is a valuable thing when there's a >>> complaint about a listing, or some other issue, so even if it's >>> not public the audit trail really should exist. >> >> An audit trail should exist. There are considerations not covered >> in this draft about what can be made public. Those considerations >> should be included. This could brace users when they hear >> something that they don't want to hear. "I can't show you the >> message." > > Good point. How about: > > A DNSBL SHOULD maintain an audit trail for all listings and it is > RECOMMENDED that it is made publicly available in an easy to find > location, preferably on the DNSBL's web site. Please note that > making audit trail data public does not entail revealing all > information in the DNSBL administrator's possession relating to the > listing; e.g., a DNSBL administrator MAY make the audit trail data > selectively accessible in such a way as to not disclose information > that might assist spammers, such as the contents of an email > received > by the DNSBL's spam trap. Better. Chris is right about changing to "a DNSBL spam trap". -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Feb 12 14:45:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGh5E-0002fR-2Q; Mon, 12 Feb 2007 14:43:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGh5B-0002ei-1e for asrg@ietf.org; Mon, 12 Feb 2007 14:43:25 -0500 Received: from bodger.sergeant.org ([62.173.71.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HGh59-0003Wi-L9 for asrg@ietf.org; Mon, 12 Feb 2007 14:43:25 -0500 Received: (qmail 14659 invoked by uid 510); 12 Feb 2007 19:43:29 -0000 Received: from bas2-kitchener06-1096651761.dsl.bell.ca (HELO [192.168.2.11]) (65.93.147.241) by bodger.sergeant.org (qpsmtpd/0.28) with ESMTP; Mon, 12 Feb 2007 19:43:29 +0000 In-Reply-To: <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Mon, 12 Feb 2007 14:42:56 -0500 To: Douglas Otis X-Mailer: Apple Mail (2.752.3) X-Qpsmtpd-Auth: True X-Spam-Status: unknown X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 12-Feb-07, at 2:11 PM, Douglas Otis wrote: > 6 months is not a sensible maximum in may cases. If an interval > must be mentioned, why not say a year or less. A year is likely to > be a typical interval for service purchases. Most spam sources are > compromised systems. Increasing the block cycle rate will just > increase the number of times a compromised system can spew spam > before being once again blocked. When the owner of the IP address > actually wants to send valid email, they can make a request to > expedite a removal process in most cases. What makes 6 months > sound reasonable???? 6 months is entirely arbitrary. As is your suggestion of "a year or less". You have to pick what sounds sensible and that sounded sensible to the authors and those who run public DNSBLs that we consulted. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Feb 12 14:45:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGh5j-00038H-3F; Mon, 12 Feb 2007 14:43:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGh5h-000389-Sm for asrg@ietf.org; Mon, 12 Feb 2007 14:43:57 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGh5g-0003bN-Jp for asrg@ietf.org; Mon, 12 Feb 2007 14:43:57 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l1CJhr708966 for ; Mon, 12 Feb 2007 14:43:53 -0500 (EST) Received: from [47.129.150.3] ([47.129.150.3] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Feb 2007 14:43:53 -0500 Message-ID: <45D0C376.7030909@nortel.com> Date: Mon, 12 Feb 2007 14:43:50 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: ASRG Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> In-Reply-To: <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Feb 2007 19:43:53.0099 (UTC) FILETIME=[20103DB0:01C74EDE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Douglas Otis wrote: > > On Feb 12, 2007, at 9:16 AM, Matt Sergeant wrote: > >> On 9-Feb-07, at 9:03 PM, Douglas Otis wrote: >> >>>>> A period that represents typical IP ownership is not likely 6 >>>>> months. Many of these systems are compromised and can be retasked >>>>> to send spam once the IP address drops off a popular block list. >>>>> How is 6 months reasonable for a long listing? Why not state a >>>>> goal rather than setting some arbitrary period not based upon any >>>>> information or rationale. >>>> >>>> The goal is stated. If it needs to be clarified we should do that. >>> >>> DNSBL operators should mimic Spamhaus policies? Don't suggest there >>> is some magic period. >> >> Our belief: There needs to be a sensible maximum time of listing >> should the entry no longer meet the listing criteria. >> >> We think 6 months is a sensible maximum. This BCP is in NO WAY >> suggesting that an IP/range shouldn't ever be listed for longer than 6 >> months, but that if your listing criteria is no longer met then the >> entry should time out after a maximum of 6 months. > > 6 months is not a sensible maximum in may cases. If an interval must > be mentioned, why not say a year or less. A year is likely to be a > typical interval for service purchases. Most spam sources are > compromised systems. Increasing the block cycle rate will just increase > the number of times a compromised system can spew spam before being once > again blocked. When the owner of the IP address actually wants to send > valid email, they can make a request to expedite a removal process in > most cases. What makes 6 months sound reasonable???? We have to remember that DNSBLs have very widely varying expiration intervals, based upon how they list and in some cases sheer size. SpamCop's initial expiration is a day or two. But some DNSBLs are forever. I believe that listings, absent "later redetection of malicious behaviour", should have a timeout. For a SBL-ish list, 6 months of "no repeat behaviour" is a reasonable max. For a "straight compromise" DNSBL (like CBL, ORDB etc) it hardly makes sense to hold entries so long, especially when so much of it is dynamic, or at least, not nearly as long lived as a stationary MTA. But aside from things like geo-based DNSBLs, I think all DNSBLs should have some sort of timeout (again, absent repeat detections). Otherwise, we litter IPv4 with IP space that's difficult to use. I pity the poor people who have to reuse AGIS space... I don't think we want to litter the BCP with stuff like that. I'd like to avoid it. But I think saying that a reasonable timeout is a good idea. Matt's altered wording is better I think. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Feb 12 15:15:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGhZE-0003po-4w; Mon, 12 Feb 2007 15:14:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGhZC-0003pi-ET for asrg@ietf.org; Mon, 12 Feb 2007 15:14:26 -0500 Received: from mail1.nber.org ([66.251.72.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGhZB-0001OW-1l for asrg@ietf.org; Mon, 12 Feb 2007 15:14:26 -0500 Received: from mail1 (root@localhost) by mail1.nber.org (8.12.11.20060308/8.12.11) with SMTP id l1CKEGT9002949 for ; Mon, 12 Feb 2007 15:14:17 -0500 Received: from nber1.nber.org (nber1.nber.org [66.251.72.71]) by mail1.nber.org (8.12.11.20060308/8.12.11) with ESMTP id l1CKEEMd002910; Mon, 12 Feb 2007 15:14:15 -0500 Received: from nber1.nber.org (localhost [127.0.0.1]) by nber1.nber.org (8.12.10+Sun/8.12.10) with ESMTP id l1CKEEnE000847; Mon, 12 Feb 2007 15:14:14 -0500 (EST) Received: from localhost (feenberg@localhost) by nber1.nber.org (8.12.10+Sun/8.12.9/Submit) with ESMTP id l1CKEDOc000844; Mon, 12 Feb 2007 15:14:13 -0500 (EST) X-Authentication-Warning: nber1.nber.org: feenberg owned process doing -bs Date: Mon, 12 Feb 2007 15:14:13 -0500 (EST) From: Daniel Feenberg To: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 In-Reply-To: Message-ID: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Mon, 12 Feb 2007, Matt Sergeant wrote: > On 9-Feb-07, at 9:03 PM, Douglas Otis wrote: > ... >>>> Publicly listed messages likely represent a sacrificial source. There >>>> lies the rub. What happens when a spammer has an above average IQ? Your >>>> listed, but we can show you why? >>> >>> Do you have an objection to this point being a SHOULD? Clearly DNSBLs >>> maintain and even display audit trails and retain effectiveness. I'm lost >>> by your argument here. The point of this section is that an audit trail is >>> a valuable thing when there's a complaint about a listing, or some other >>> issue, so even if it's not public the audit trail really should exist. >> >> An audit trail should exist. There are considerations not covered in this >> draft about what can be made public. Those considerations should be >> included. This could brace users when they hear something that they don't >> want to hear. "I can't show you the message." > > Good point. How about: > > A DNSBL SHOULD maintain an audit trail for all listings and it is > RECOMMENDED that it is made publicly available in an easy to find > location, preferably on the DNSBL's web site. Please note that > making audit trail data public does not entail revealing all > information in the DNSBL administrator's possession relating to the > listing; e.g., a DNSBL administrator MAY make the audit trail data > selectively accessible in such a way as to not disclose information > that might assist spammers, such as the contents of an email received > by the DNSBL's spam trap. > > Matt. > > > I think there is positive value in diversity of audit trail policy. If all DNSBLs have no audit trail, then spammer's can't listwash, but it is also true that operators of websites and MTAs with security problems will not receive useful information about what is going wrong, and this may delay corrections. If for instance, a webmaster is responsible for multiple web pages that generate email, and only one is defective, it helps to know which one. If some DNSBLs have detailed audit information available that will help such sources, without giving spammer's the ability to listwash all spamtraps. Since the best outcome is achived by a mix of policies, it hardly seems necessary to anoint one as "best". Daniel Feenberg _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Feb 12 16:40:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGisM-0003Qc-30; Mon, 12 Feb 2007 16:38:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGisK-0003QV-9Y for asrg@ietf.org; Mon, 12 Feb 2007 16:38:16 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGisI-0001wd-Uc for asrg@ietf.org; Mon, 12 Feb 2007 16:38:16 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1CLcBep009118 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Feb 2007 13:38:12 -0800 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Mon, 12 Feb 2007 13:38:15 -0800 To: Daniel Feenberg X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ASRG , Matt Sergeant X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 12, 2007, at 12:14 PM, Daniel Feenberg wrote: > > > On Mon, 12 Feb 2007, Matt Sergeant wrote: > >> On 9-Feb-07, at 9:03 PM, Douglas Otis wrote: >> >> Good point. How about: >> >> A DNSBL SHOULD maintain an audit trail for all listings and it is >> RECOMMENDED that it is made publicly available in an easy to find >> location, preferably on the DNSBL's web site. Please note that >> making audit trail data public does not entail revealing all >> information in the DNSBL administrator's possession relating to >> the listing; e.g., a DNSBL administrator MAY make the audit trail >> data selectively accessible in such a way as to not disclose >> information that might assist spammers, such as the contents of >> an email received by the DNSBL's spam trap. > > I think there is positive value in diversity of audit trail policy. > If all DNSBLs have no audit trail, then spammer's can't listwash, > but it is also true that operators of websites and MTAs with > security problems will not receive useful information about what is > going wrong, and this may delay corrections. If for instance, a > webmaster is responsible for multiple web pages that generate > email, and only one is defective, it helps to know which one. > > If some DNSBLs have detailed audit information available that will > help such sources, without giving spammer's the ability to listwash > all spamtraps. > > Since the best outcome is achived by a mix of policies, it hardly > seems necessary to anoint one as "best". I read "selectively accessible" as meaning both trap and content redaction. This means clever spammers may not produce an audit trail visible to the public. It might be good to mention this somewhere. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Feb 12 17:29:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGjel-000405-U6; Mon, 12 Feb 2007 17:28:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGjek-000400-Nh for asrg@ietf.org; Mon, 12 Feb 2007 17:28:18 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGjej-00038I-CM for asrg@ietf.org; Mon, 12 Feb 2007 17:28:18 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1CMSGGn020009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Feb 2007 14:28:16 -0800 In-Reply-To: <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Mon, 12 Feb 2007 14:28:20 -0800 To: Matt Sergeant X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 12, 2007, at 11:42 AM, Matt Sergeant wrote: > On 12-Feb-07, at 2:11 PM, Douglas Otis wrote: > >> 6 months is not a sensible maximum in may cases. If an interval >> must be mentioned, why not say a year or less. A year is likely >> to be a typical interval for service purchases. Most spam sources >> are compromised systems. Increasing the block cycle rate will >> just increase the number of times a compromised system can spew >> spam before being once again blocked. When the owner of the IP >> address actually wants to send valid email, they can make a >> request to expedite a removal process in most cases. What makes 6 >> months sound reasonable???? > > 6 months is entirely arbitrary. As is your suggestion of "a year or > less". You have to pick what sounds sensible and that sounded > sensible to the authors and those who run public DNSBLs that we > consulted. A year is likely to be a typical interval for bulk service agreements. Why not punish negligent network providers? Why should providers be able to assume their negligence will be quickly expunged? A period regarding IP address acquisition offers a valid basis for some conditioned maximal value. What justification, beyond the SpamHaus policy, is available? Why not seven years as used by Fair Credit Reporting Act? Longer periods are more likely to ensure future abuse is prevented. Credit agencies are not required to even generate reports in less than one year without compensation. A provider's negligence then hurting next year's customer seems like a good incentive to ensure abuse is quickly stopped. There are ample tools available to track abuse emerging from a network. Affecting the bottom line offers powerful corrective incentives. The AGIS address space has been impaired by the number of blocks made using BGP. This is an example where some blocks will be very long, complete, and appropriately reflect prior negligence. Why not hold the provider's accountable beyond a typical contract period? Why suggest a BCP that takes the sting out of negligence? -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Mon Feb 12 22:50:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGodh-0006GN-Jd; Mon, 12 Feb 2007 22:47:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGodg-0006GF-5t for asrg@ietf.org; Mon, 12 Feb 2007 22:47:32 -0500 Received: from bodger.sergeant.org ([62.173.71.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HGodd-0000Ct-5v for asrg@ietf.org; Mon, 12 Feb 2007 22:47:32 -0500 Received: (qmail 2609 invoked by uid 510); 13 Feb 2007 03:47:27 -0000 Received: from bas2-kitchener06-1096651761.dsl.bell.ca (HELO [192.168.2.11]) (65.93.147.241) by bodger.sergeant.org (qpsmtpd/0.28) with ESMTP; Tue, 13 Feb 2007 03:47:27 +0000 In-Reply-To: <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Mon, 12 Feb 2007 22:46:59 -0500 To: Douglas Otis X-Mailer: Apple Mail (2.752.3) X-Qpsmtpd-Auth: True X-Spam-Status: unknown X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 12-Feb-07, at 5:28 PM, Douglas Otis wrote: > A year is likely to be a typical interval for bulk service agreements. I'm not sure why you keep persisting on this point. If the criteria for the DNSBL is something like "a known spammer has service on this IP/range" then after (or before) the timeout period the DNSBL must re- check that the spammer still has service on that IP/range, and confirm that indeed the spammer does. Thus the listing is extended beyond the 6 month period. It could last forever for all we care, as long as the listing criteria STILL EXISTS. I'll repeat myself again: this BCP in NO WAY forces delisting after the timeout period. It makes that clear - you just choose not to read that part for some reason. I'm done arguing this with you now. We'll discuss between the authors if we think 6 months is the wrong time period but you haven't presented any decent argument for it IMHO. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Feb 13 01:03:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGqft-0003qC-H2; Tue, 13 Feb 2007 00:57:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGqfs-0003pz-1F for asrg@ietf.org; Tue, 13 Feb 2007 00:57:56 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGqfq-0002bs-LG for asrg@ietf.org; Tue, 13 Feb 2007 00:57:56 -0500 Received: from [192.168.2.43] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1D5vrHZ017220 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 12 Feb 2007 21:57:53 -0800 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Mon, 12 Feb 2007 21:57:48 -0800 To: Matt Sergeant X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 12, 2007, at 7:46 PM, Matt Sergeant wrote: > On 12-Feb-07, at 5:28 PM, Douglas Otis wrote: > >> A year is likely to be a typical interval for bulk service >> agreements. > > I'm not sure why you keep persisting on this point. If the criteria > for the DNSBL is something like "a known spammer has service on > this IP/range" then after (or before) the timeout period the DNSBL > must re-check that the spammer still has service on that IP/range, > and confirm that indeed the spammer does. Thus the listing is > extended beyond the 6 month period. It could last forever for all > we care, as long as the listing criteria STILL EXISTS. There are at least two entities to be considered with respect to a reasonable listing duration. One might be the individual entity administering the system directly associated with the IP address. Another would be the entity providing the IP address and routing from their ASN. The duration of any listing must consider the behavior of _both_. A high density of bad actors within an ASN SHOULD extend duration well into a year and be sure to cover a typical contract period. The goal of the DNSBL operator is often to alter the behavior of the network provider. In such cases it is pointless to focus upon individual IP addresses when the network provider is truly negligent. > I'll repeat myself again: this BCP in NO WAY forces delisting after > the timeout period. It makes that clear - you just choose not to > read that part for some reason. > > I'm done arguing this with you now. We'll discuss between the > authors if we think 6 months is the wrong time period but you > haven't presented any decent argument for it IMHO. On the contrary. You have not presented cogent arguments as to why 6 months is a suitable listing duration, especially when a provider is negligent. Individual treatment of IP addresses must be predicated upon the provider enforcing an AUP policy that precludes spamming. Any provider that offers unlimited services to spammers should never expect IP address delisting within an interval as short as 6 months. This is being far to generous. In the case of individual IP addresses within a well managed ASN, a request can be made to expedite delistings. Again, when the typical contract is by the year, automatic delisting within six months is still likely too soon. While a six month duration might be selected as a means to reduce delisting requests, a poorly managed ASN should still delay a delisting over a much longer period. Incidents of abuse can not always be considered by individual IP addresses, but in conjunction with the ASN as a whole. Please don't say this should be based upon what _sounds_ reasonable. Perspectives differ between network and email providers, and those operating DNSBLs. The goal of DNSBL operators is to reduce the tide of spam, which ironically is not always a shared motivation, especially when charges are by bits per second. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Feb 13 09:25:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGyY1-00024y-7M; Tue, 13 Feb 2007 09:22:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGyXz-000241-LU for asrg@ietf.org; Tue, 13 Feb 2007 09:22:19 -0500 Received: from mail48.messagelabs.com ([193.109.255.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HGyXy-0002gL-9r for asrg@ietf.org; Tue, 13 Feb 2007 09:22:19 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-11.tower-48.messagelabs.com!1171376534!12154771!3 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 26370 invoked from network); 13 Feb 2007 14:22:14 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-11.tower-48.messagelabs.com with SMTP; 13 Feb 2007 14:22:14 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 14:22:14 +0000 Received: (qmail 15752 invoked from network); 13 Feb 2007 14:22:13 -0000 Received: from unknown (HELO ?10.100.0.139?) (10.100.0.139) by matt?dev.int.star.co.uk with SMTP; 13 Feb 2007 14:22:13 -0000 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Tue, 13 Feb 2007 09:21:48 -0500 To: Douglas Otis X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Feb 2007 14:22:14.0466 (UTC) FILETIME=[5B984A20:01C74F7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 13-Feb-07, at 12:57 AM, Douglas Otis wrote: > There are at least two entities to be considered with respect to a > reasonable listing duration. One might be the individual entity > administering the system directly associated with the IP address. > Another would be the entity providing the IP address and routing > from their ASN. The duration of any listing must consider the > behavior of _both_. A high density of bad actors within an ASN > SHOULD extend duration well into a year and be sure to cover a > typical contract period. The goal of the DNSBL operator is often > to alter the behavior of the network provider. In such cases it is > pointless to focus upon individual IP addresses when the network > provider is truly negligent. Nothing in this draft prevents this. > Individual treatment of IP addresses must be predicated upon the > provider enforcing an AUP policy that precludes spamming. Any > provider that offers unlimited services to spammers should never > expect IP address delisting within an interval as short as 6 > months. This is being far to generous. In the case of individual > IP addresses within a well managed ASN, a request can be made to > expedite delistings. Again, when the typical contract is by the > year, automatic delisting within six months is still likely too soon. Nothing in this draft prevents this. > While a six month duration might be selected as a means to reduce > delisting requests, a poorly managed ASN should still delay a > delisting over a much longer period. Incidents of abuse can not > always be considered by individual IP addresses, but in conjunction > with the ASN as a whole. Nothing in this draft prevents this. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Feb 13 14:05:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2uq-0002Ww-Jn; Tue, 13 Feb 2007 14:02:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH2up-0002Sv-64 for asrg@ietf.org; Tue, 13 Feb 2007 14:02:11 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH2um-0003kr-Pp for asrg@ietf.org; Tue, 13 Feb 2007 14:02:11 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1DJ234F001121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Feb 2007 11:02:04 -0800 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Tue, 13 Feb 2007 11:02:02 -0800 To: Matt Sergeant X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 13, 2007, at 6:21 AM, Matt Sergeant wrote: > On 13-Feb-07, at 12:57 AM, Douglas Otis wrote: > >> There are at least two entities to be considered with respect to a >> reasonable listing duration. One might be the individual entity >> administering the system directly associated with the IP address. >> Another would be the entity providing the IP address and routing >> from their ASN. The duration of any listing must consider the >> behavior of _both_. A high density of bad actors within an ASN >> SHOULD extend duration well into a year and be sure to cover a >> typical contract period. The goal of the DNSBL operator is often >> to alter the behavior of the network provider. In such cases it >> is pointless to focus upon individual IP addresses when the >> network provider is truly negligent. > > Nothing in this draft prevents this. ,--- |For more aggressive spammers (e.g., those operating their |own ISP) the temporary period MAY be as much as six (6) months. |However, longer periods SHOULD NOT be used since it is possible |that an IP address or domain can change hands, possibly being |allocated to a non-abusive user. '--- The foremost goal of a DNSBL is to prevent spam! This is largely accomplished by changing the behavior of the _network_ providers (ISPs). The typical maximal duration SHOULD bridge contracts and impact the _network_ provider's revenue. This makes the the DNSBL effective at changing the behavior of the network provider. Of course, cooperative providers deserve continuous evaluation, but is draft is written from an obtuse perspective of individual IP addresses and has ignored the role of the network providers. What is the goal of the DNSBL? There are at least two entities involved in sending spam, email and network providers. DNSBL needs to ensure that preventing spam remains in everyone's mutual interest and is prohibited within the network provider's AUPs. A short duration of 6 months is not likely to cover a typical contract _as stated in the draft_! If anything, this alone justifies a longer maximal listing duration when the provider permits spam. How about: To affect network providers that permit spam as evidenced by a high percentage of spam sources within their ASN, the maximal listing duration SHOULD BE a period of one year or more. This is to specifically affect their ability to profit from spam. When the provider is otherwise effective at prohibiting spam, the maximal duration SHOULD BE less than an year, where a duration of six months is likely adequate. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Feb 13 14:40:52 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH3Vn-0006YG-E7; Tue, 13 Feb 2007 14:40:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH3Vm-0006YA-Cg for asrg@ietf.org; Tue, 13 Feb 2007 14:40:22 -0500 Received: from mail48.messagelabs.com ([193.109.255.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HH3Vl-000881-1l for asrg@ietf.org; Tue, 13 Feb 2007 14:40:22 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-24.tower-48.messagelabs.com!1171395618!11135713!1 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 17080 invoked from network); 13 Feb 2007 19:40:19 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-24.tower-48.messagelabs.com with SMTP; 13 Feb 2007 19:40:19 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 19:40:18 +0000 Received: (qmail 16874 invoked from network); 13 Feb 2007 19:40:18 -0000 Received: from unknown (HELO ?10.100.0.139?) (10.100.0.139) by matt?dev.int.star.co.uk with SMTP; 13 Feb 2007 19:40:18 -0000 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1FACF48D-A892-46E1-A962-39685BB484FF@messagelabs.com> Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Tue, 13 Feb 2007 14:39:54 -0500 To: Douglas Otis X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Feb 2007 19:40:18.0875 (UTC) FILETIME=[CACA00B0:01C74FA6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 13-Feb-07, at 2:02 PM, Douglas Otis wrote: >> Nothing in this draft prevents this. > > ,--- > |For more aggressive spammers (e.g., those operating their > |own ISP) the temporary period MAY be as much as six (6) months. > |However, longer periods SHOULD NOT be used since it is possible > |that an IP address or domain can change hands, possibly being > |allocated to a non-abusive user. > '--- ,--- | Note that all listings being temporary does not mean that some | listings will not remain after the initial timeout period. If the | DNSBL administrator determines that the conditions for listing | still exists, then the timer for determining timeouts MAY be | renewed. '--- ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Feb 13 14:49:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH3eZ-0002pM-N0; Tue, 13 Feb 2007 14:49:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH3eX-0002oX-FR for asrg@ietf.org; Tue, 13 Feb 2007 14:49:25 -0500 Received: from mail48.messagelabs.com ([193.109.255.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HH3eW-0000XU-4f for asrg@ietf.org; Tue, 13 Feb 2007 14:49:25 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-11.tower-48.messagelabs.com!1171396162!12157234!1 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 5652 invoked from network); 13 Feb 2007 19:49:22 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-11.tower-48.messagelabs.com with SMTP; 13 Feb 2007 19:49:22 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 19:49:21 +0000 Received: (qmail 16881 invoked from network); 13 Feb 2007 19:49:21 -0000 Received: from unknown (HELO ?10.100.0.139?) (10.100.0.139) by matt?dev.int.star.co.uk with SMTP; 13 Feb 2007 19:49:21 -0000 In-Reply-To: <1FACF48D-A892-46E1-A962-39685BB484FF@messagelabs.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <1FACF48D-A892-46E1-A962-39685BB484FF@messagelabs.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8AF48373-48E9-410A-91DC-12FF68350314@messagelabs.com> Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Tue, 13 Feb 2007 14:48:57 -0500 To: Matt Sergeant X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Feb 2007 19:49:22.0027 (UTC) FILETIME=[0E886BB0:01C74FA8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 13-Feb-07, at 2:39 PM, Matt Sergeant wrote: > ,--- > | Note that all listings being temporary does not mean that some > | listings will not remain after the initial timeout period. If the > | DNSBL administrator determines that the conditions for listing > | still exists, then the timer for determining timeouts MAY be > | renewed. > '--- Maybe I could put this better as: What is the purpose of stating that listings should time out? The purpose is to ensure that DNSBL owners continue to check the reason for listing. Otherwise they aren't solving the spam problem, they are just listing because they're too lazy to check. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Feb 13 17:59:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH6aJ-000638-EV; Tue, 13 Feb 2007 17:57:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HH6aI-00062v-6B for asrg@ietf.org; Tue, 13 Feb 2007 17:57:14 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HH6aG-0003d0-R6 for asrg@ietf.org; Tue, 13 Feb 2007 17:57:14 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1DMvB6V016874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Feb 2007 14:57:12 -0800 In-Reply-To: <8AF48373-48E9-410A-91DC-12FF68350314@messagelabs.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <1FACF48D-A892-46E1-A962-39685BB484FF@messagelabs.com> <8AF48373-48E9-410A-91DC-12FF68350314@messagelabs.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6A4ACE6E-54C3-4309-88EB-2F528F2DAE08@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Tue, 13 Feb 2007 14:57:10 -0800 To: Matt Sergeant X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 13, 2007, at 11:48 AM, Matt Sergeant wrote: > On 13-Feb-07, at 2:39 PM, Matt Sergeant wrote: > >> ,--- >> | Note that all listings being temporary does not mean that some >> | listings will not remain after the initial timeout period. If the >> | DNSBL administrator determines that the conditions for listing >> | still exists, then the timer for determining timeouts MAY be >> | renewed. >> '--- > > Maybe I could put this better as: What is the purpose of stating > that listings should time out? > > The purpose is to ensure that DNSBL owners continue to check the > reason for listing. Otherwise they aren't solving the spam problem, > they are just listing because they're too lazy to check. ,--- |For more aggressive spammers (e.g., those operating their |own ISP) the temporary period MAY be as much as six (6) months. |However, longer periods SHOULD NOT be used since it is possible |that an IP address or domain can change hands, possibly being |allocated to a non-abusive user. '--- Matt, The percentage of abusive IP addresses within an ASN must determine the duration established in listing specific IP addresses within the ASN. The goal is to stop the source of spam, which can only happen when network providers enforce AUPs prohibiting spam. Some DNSBLs ignore listed sources over a period as necessitated by overall spam volumes. Revisiting traffic sooner than an interval effective at stopping a network provider's behavior requires significant expenditures by DNSBL operators. Audit trails and network bandwidth have a cost. What justifies increasing the costs of DNSBLs to facilitate marketing of services by a spam friendly network provider, as this draft suggests? Even credit agencies are not required to issue a report in less than a year without compensation. Why ensure a spam friendly provider's next customer is not affected by the provider's negligence? How will this reduce the level of spam? This draft's recommended practice allows providers to ignore spam, as it ignores the role a network provider must play in stopping spam. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 07:04:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHInL-0000MK-Vx; Wed, 14 Feb 2007 06:59:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHInL-0000M8-1N for asrg@ietf.org; Wed, 14 Feb 2007 06:59:31 -0500 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHInJ-0001mT-PM for asrg@ietf.org; Wed, 14 Feb 2007 06:59:31 -0500 Received: from pc6 (1Cust1.tnt24.lnd4.gbr.da.uu.net [62.188.151.1]) by ranger.systems.pipex.net (Postfix) with SMTP id 41461E000297; Wed, 14 Feb 2007 11:59:15 +0000 (GMT) Message-ID: <00b901c75026$f01d9b80$0601a8c0@pc6> From: "Tom Petch" To: "Matt Sergeant" References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net><45CBBFE3.E2@xyzzy.claranet.de><61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com><39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org><3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org><5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com><32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org><1FACF48D-A892-46E1-A962-39685BB484FF@messagelabs.com> <8AF48373-48E9-410A-91DC-12FF68350314@messagelabs.com> Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Wed, 14 Feb 2007 11:46:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tom Petch List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org I think that this I-D would benefit from additional paragraphs of 'stating the obvious'. Specifically, you assume a detailed knowedge of what a DNSBL is and make reference to various fields therein; I think you should summarise in two or three sentences what DNS records there are likely to be containing what data. Second, perhaps before that, you should explain who uses a DNSBL and how, even though, or perhaps because, such people are not the target audience - currently you only mention the why; again one paragraph of two or three sentences. Finally, you assume a detailed knowledge of (r)DNS and zones - again, I think that you should explain more and include a normative reference to the relevant RFC. I think too that most of your existing references are normative, ie something that must be understood if the I-D is to make any sense. Tom Petch _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 09:05:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHKiO-0005PN-TI; Wed, 14 Feb 2007 09:02:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHKiM-0005PG-Tu for asrg@ietf.org; Wed, 14 Feb 2007 09:02:30 -0500 Received: from bigsky.scconsult.com ([66.73.230.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHKiL-000094-Ax for asrg@ietf.org; Wed, 14 Feb 2007 09:02:30 -0500 Received: from bigsky.scconsult.com (localhost [127.0.0.1]) by bigsky.scconsult.com (Postfix) with ESMTP id A5F9F41BF11 for ; Wed, 14 Feb 2007 09:02:28 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> X-Message-Flag: Use of Microsoft mail clients is the primary cause of cracked systems. Please switch! Date: Wed, 14 Feb 2007 09:02:24 -0500 To: ASRG From: Bill Cole Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org At 9:57 PM -0800 2/12/07, Douglas Otis wrote: >On Feb 12, 2007, at 7:46 PM, Matt Sergeant wrote: > >>On 12-Feb-07, at 5:28 PM, Douglas Otis wrote: >> >>>A year is likely to be a typical interval for bulk service agreements. >> >>I'm not sure why you keep persisting on this point. If the criteria >>for the DNSBL is something like "a known spammer has service on >>this IP/range" then after (or before) the timeout period the DNSBL >>must re-check that the spammer still has service on that IP/range, >>and confirm that indeed the spammer does. Thus the listing is >>extended beyond the 6 month period. It could last forever for all >>we care, as long as the listing criteria STILL EXISTS. > >There are at least two entities to be considered with respect to a >reasonable listing duration. One might be the individual entity >administering the system directly associated with the IP address. >Another would be the entity providing the IP address and routing >from their ASN. The duration of any listing must consider the >behavior of _both_. A high density of bad actors within an ASN >SHOULD extend duration well into a year and be sure to cover a >typical contract period. The goal of the DNSBL operator is often >to alter the behavior of the network provider. In such cases it is >pointless to focus upon individual IP addresses when the network >provider is truly negligent. > >>I'll repeat myself again: this BCP in NO WAY forces delisting after >>the timeout period. It makes that clear - you just choose not to >>read that part for some reason. >> >>I'm done arguing this with you now. We'll discuss between the >>authors if we think 6 months is the wrong time period but you >>haven't presented any decent argument for it IMHO. > >On the contrary. You have not presented cogent arguments as to why >6 months is a suitable listing duration, especially when a provider >is negligent. Because the BCP does not say that and you are inventing that concept by not reading carefully enough. If the listing criteria remains true, the entire paragraph talking about 6 months is completely irrelevant. >Individual treatment of IP addresses must be predicated upon the >provider enforcing an AUP policy that precludes spamming. Says who? That appears to be fodder for listing policy of a specific DNSBL, not for an operational BCP document. There are DNSBL's that are insensitive to ISP policy or its enforcement. The CBL is an example, and it is arguably the most useful primary DNSBL in operation, with only the aggregates that include it being more comprehensive. >Any provider that offers unlimited services to spammers should never >expect IP address delisting within an interval as short as 6 months. >This is being far to generous. In the case of individual IP >addresses within a well managed ASN, a request can be made to >expedite delistings. Again, when the typical contract is by the >year, automatic delisting within six months is still likely too soon. This would only make sense if you believed the BCP prohibits listing standards that look at ASN-level behavior as a contributing factor to a listing. I don't think it does. For example, one could operate a DNSBL where a listing is documented to mean "This address space has a history of being assigned by its RIR-registered owner to people with 4-letter surnames." When that DNSBL listed the space I use, and I found it untenable to remain in the space because of the geniuses who think all DNSBL's mean the same thing, the 6-month clock would not start. What would start the 6-month clock would be AT&T going bankrupt and returning the block to ARIN. >While a six month duration might be selected as a means to reduce >delisting requests, a poorly managed ASN should still delay a >delisting over a much longer period. Incidents of abuse can not >always be considered by individual IP addresses, but in conjunction >with the ASN as a whole. There's nothing in the BCP that requires listing standards to ignore ASN behavior, or to include ASN behavior. That is a detail that is out of scope for the BCP, but including ASN behavior as a factor in a particular list (e.g. something like SPEWS but run competently and rigorously to documented testable standards) >Please don't say this should be based upon what _sounds_ reasonable. >Perspectives differ between network and email providers, and those >operating DNSBLs. The goal of DNSBL operators is to reduce the tide >of spam, Not always. Historically the goals have seemed to include defaming creditors, making political statements about the ethics of various network operators, and demonstrating the clue deficiencies of the mail technical community. In that last class of DNSBL, the target members have been people who think all DNSBL's are about the same things. -- Bill Cole bill@scconsult.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 13:52:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHPBo-0006Rs-3B; Wed, 14 Feb 2007 13:49:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHPBn-0006Q7-3k for asrg@ietf.org; Wed, 14 Feb 2007 13:49:11 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHPBl-0005Sn-Hi for asrg@ietf.org; Wed, 14 Feb 2007 13:49:11 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1EIn6IK030388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Feb 2007 10:49:07 -0800 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Wed, 14 Feb 2007 10:49:06 -0800 To: Bill Cole X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 14, 2007, at 6:02 AM, Bill Cole wrote: > At 9:57 PM -0800 2/12/07, Douglas Otis wrote: >> On Feb 12, 2007, at 7:46 PM, Matt Sergeant wrote: >> >> On the contrary. You have not presented cogent arguments as to >> why 6 months is a suitable listing duration, especially when a >> provider is negligent. > > Because the BCP does not say that and you are inventing that > concept by not reading carefully enough. > > If the listing criteria remains true, the entire paragraph talking > about 6 months is completely irrelevant. Listing policies regarding duration must consider behaviors of specific IP addresses and that of that of the network provider associated with the ASN. ,--- |For more aggressive spammers (e.g., those operating their |own ISP) the temporary period MAY be as much as six (6) months. |However, longer periods SHOULD NOT be used since it is possible |that an IP address or domain can change hands, possibly being |allocated to a non-abusive user. '--- This statement ignores network provider's role, and rewards bad behavior by ensuring their ability to market IP addresses within their poorly managed ASN. The goal is not about making DNSBLs essential by coddling spam-friendly providers, as this statement recommends. The goal of the DNSBL is to convince network providers it is in their interest to enforce AUPs that prohibit spamming. I hope you agree. >> Individual treatment of IP addresses must be predicated upon the >> provider enforcing an AUP policy that precludes spamming. > > Says who? > > That appears to be fodder for listing policy of a specific DNSBL, > not for an operational BCP document. This draft states that bad behavior of the network provider SHOULD be accommodated by ensuring their ability to market their IP address space. Best Current Practices of a DNSBL is to convince network providers they SHOULD enforce AUPs prohibiting spamming. As such, the BCP must consider the level of abuse from the ASN of the network provider as a significant factor in establishing the duration of a block listing. The current draft insists on the opposite, and this can NEVER be considered a BCP! > There are DNSBL's that are insensitive to ISP policy or its > enforcement. The CBL is an example, and it is arguably the most > useful primary DNSBL in operation, with only the aggregates that > include it being more comprehensive. The CBL of abuseat.org is an automated listing that specifically excludes intended SMTP clients. The goal of the CBL is to prevent proxy and infected related abuse. You are not saying that Spam is okay as long as it is intended, or that this represents a best practice? >> Any provider that offers unlimited services to spammers should >> never expect IP address delisting within an interval as short as 6 >> months. >> This is being far to generous. In the case of individual IP >> addresses within a well managed ASN, a request can be made to >> expedite delistings. Again, when the typical contract is by the >> year, automatic delisting within six months is still likely too soon. > > This would only make sense if you believed the BCP prohibits > listing standards that look at ASN-level behavior as a contributing > factor to a listing. I don't think it does. Carefully read the last sentence of the quoted text. Limiting the duration of a listing to 6 months is specifically to ensure the network provider's ability to market address space. When network providers are spam-friendly, the duration of the listing SHOULD extend beyond the typical service contract. Don't think of DNSBLs as only stopping abuse after it arrives. Well managed DNSBLs prevent spam from ever being sent, and stopping spam at the source represents a Best Best Practice. > For example, one could operate a DNSBL where a listing is > documented to mean "This address space has a history of being > assigned by its RIR-registered owner to people with 4-letter > surnames." When that DNSBL listed the space I use, and I found it > untenable to remain in the space because of the geniuses who think > all DNSBL's mean the same thing, the 6-month clock would not start. > What would start the 6-month clock would be AT&T going bankrupt > and returning the block to ARIN. This is irrelevant. Again, there are two actors benefiting from spam. One actor might be the network provider selling an IP address and network bandwidth. There is also the bad actor that might briefly be able to send spam from a network provider that enforces an AUP prohibiting spam. Whether a block duration should extend beyond the typical contract duration should depend upon whether there is a substantial amount of spam abuse emerging from the ASN. Resources are required to track abuse. These resources should be reserved for those network providers attempting to enforce an AUP prohibiting spam. >> While a six month duration might be selected as a means to reduce >> delisting requests, a poorly managed ASN should still delay a >> delisting over a much longer period. Incidents of abuse can not >> always be considered by individual IP addresses, but in >> conjunction with the ASN as a whole. > > There's nothing in the BCP that requires listing standards to > ignore ASN behavior, or to include ASN behavior. That is a detail > that is out of scope for the BCP, but including ASN behavior as a > factor in a particular list (e.g. something like SPEWS but run > competently and rigorously to documented testable standards) DNSBL best practices should consider ASN behavior when establishing a listing duration. ASN behavior must not be out of scope in any DNSBL best practices draft. SPEWS considers the behavior of the network provider, and recognized the futility of attempting to play wack-a- mole with IP addresses alone. Network providers must enforce AUPs that prohibit spamming, if spam is to be abated. Considering ASN behavior is clearly a best practice. >> Please don't say this should be based upon what _sounds_ >> reasonable. Perspectives differ between network and email >> providers, and those operating DNSBLs. The goal of DNSBL >> operators is to reduce the tide of spam, > > Not always. Historically the goals have seemed to include defaming > creditors, making political statements about the ethics of various > network operators, and demonstrating the clue deficiencies of the > mail technical community. > > In that last class of DNSBL, the target members have been people > who think all DNSBL's are about the same things. The best practices for the operation of a DNSBL is to be effective at abating spam from being sent in the first place. Spam is a vector for infection either directly or indirectly by offering dangerous links. Spam can lead to DDoS attacks (especially with SPF/Sender-ID being used by the recipients). At more than 80% of the current email traffic, spam has dramatically placed the resource burden onto the recipient. The industry and the Internet internationally must prohibit spamming. The CAN-SPAM law must be changed to prohibit spamming. The best practices of a DNSBL should be aimed specifically at convincing network provider to enforce AUPs that prohibit spamming, which is a tool still allowed by CAN-SPAM. Blocking durations should not be based on personal grudges, dislikes, or politics. Policies should be consistently applied, not by treating each IP address individually, but in conjunction with the ASN as a whole. Any DNSBL policy worth its salt must consider how to persuade the cooperation of network providers. Such persuasion can only occur when ASNs as a whole plays a role in DNSBL policies. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 14:28:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHPmu-0002n9-1X; Wed, 14 Feb 2007 14:27:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHPms-0002n4-LZ for asrg@ietf.org; Wed, 14 Feb 2007 14:27:30 -0500 Received: from bigsky.scconsult.com ([66.73.230.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHPmp-0000ww-QQ for asrg@ietf.org; Wed, 14 Feb 2007 14:27:30 -0500 Received: from bigsky.scconsult.com (localhost [127.0.0.1]) by bigsky.scconsult.com (Postfix) with ESMTP id 24D2C41C31B for ; Wed, 14 Feb 2007 14:27:27 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> X-Message-Flag: Use of Microsoft mail clients is the primary cause of cracked systems. Please switch! Date: Wed, 14 Feb 2007 14:27:23 -0500 To: ASRG From: Bill Cole Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org At 10:49 AM -0800 2/14/07, Douglas Otis wrote: >On Feb 14, 2007, at 6:02 AM, Bill Cole wrote: > >>At 9:57 PM -0800 2/12/07, Douglas Otis wrote: >>>On Feb 12, 2007, at 7:46 PM, Matt Sergeant wrote: >>> >>>On the contrary. You have not presented cogent arguments as to >>>why 6 months is a suitable listing duration, especially when a >>>provider is negligent. >> >>Because the BCP does not say that and you are inventing that >>concept by not reading carefully enough. >> >>If the listing criteria remains true, the entire paragraph talking >>about 6 months is completely irrelevant. > >Listing policies regarding duration must consider behaviors of >specific IP addresses and that of that of the network provider >associated with the ASN. >,--- >|For more aggressive spammers (e.g., those operating their >|own ISP) the temporary period MAY be as much as six (6) months. >|However, longer periods SHOULD NOT be used since it is possible >|that an IP address or domain can change hands, possibly being >|allocated to a non-abusive user. >'--- > >This statement ignores network provider's role, and rewards bad >behavior by ensuring their ability to market IP addresses within >their poorly managed ASN. As Matt and I have already pointed out, you are ignoring what the draft actually says in favor of believing that it says something you feel like arguing with. Feel free to do so wherever you like. I won't bother you with responses you refuse to even read. -- Bill Cole bill@scconsult.com _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 15:01:20 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQHp-0004Sf-Lo; Wed, 14 Feb 2007 14:59:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQHo-0004RG-Eh for asrg@ietf.org; Wed, 14 Feb 2007 14:59:28 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHQHn-0004S6-3f for asrg@ietf.org; Wed, 14 Feb 2007 14:59:28 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1EJxKR0012212 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Feb 2007 11:59:20 -0800 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Wed, 14 Feb 2007 11:59:18 -0800 To: Bill Cole X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 14, 2007, at 11:27 AM, Bill Cole wrote: > At 10:49 AM -0800 2/14/07, Douglas Otis wrote: >> >> Listing policies regarding duration must consider behaviors of >> specific IP addresses and that of that of the network provider >> associated with the ASN. >> ,--- >> |For more aggressive spammers (e.g., those operating their >> |own ISP) the temporary period MAY be as much as six (6) months. >> |However, longer periods SHOULD NOT be used since it is possible >> |that an IP address or domain can change hands, possibly being >> |allocated to a non-abusive user. >> '--- >> >> This statement ignores network provider's role, and rewards bad >> behavior by ensuring their ability to market IP addresses within >> their poorly managed ASN. > > > As Matt and I have already pointed out, you are ignoring what the > draft actually says in favor of believing that it says something > you feel like arguing with. Feel free to do so wherever you like. I > won't bother you with responses you refuse to even read. No where within this entire draft is the role of the network provider mentioned or properly considered. This represents a _major_ shortcoming in a draft purporting to provide advice to DNSBL operators! The note Matt referenced pertains to condition continuing with respect to a _specific_ IP address. This ignores the role of the network provider. While listings are indeed of individual IP addresses, policy should not be limited to individual IP addresses. The entire ASN _must_ be considered. Do you understand what is meant by ASN? Do you agree network providers plays a significant role in abating spam? It is completely absurd to recommend spam-friendly ISPs have their IP addresses delisted promptly. What incentive is there for spam- friendly ISPs to change their behavior? Shouldn't this aspect of policy be considered in any DNSBL best practices? -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 15:14:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQV6-0002wk-TF; Wed, 14 Feb 2007 15:13:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQV5-0002wf-LY for asrg@ietf.org; Wed, 14 Feb 2007 15:13:11 -0500 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHQV4-0005YI-6M for asrg@ietf.org; Wed, 14 Feb 2007 15:13:11 -0500 Received: by ug-out-1314.google.com with SMTP id 72so326522ugd for ; Wed, 14 Feb 2007 12:13:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=pePGVbn9GZTpnidOBlCT4mEoRPcSk4BBIvhPknK9p19ZC6HPqtyYeRhcsDRO7L8jB3dk24kCwghJWdsRJtzGJPEWcbuXjaFG1KbjPDSwkSm1SsbQs0GuZ5kHbxiQKS1uQ3c6zSlTbQumSdIE6ARnu90iNeEuewyHWnnKfswZZuU= Received: by 10.115.106.7 with SMTP id i7mr672840wam.1171483987584; Wed, 14 Feb 2007 12:13:07 -0800 (PST) Received: by 10.114.198.4 with HTTP; Wed, 14 Feb 2007 12:13:07 -0800 (PST) Message-ID: <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> Date: Wed, 14 Feb 2007 20:13:07 +0000 From: "Peter Bowyer" To: ASRG Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> X-Google-Sender-Auth: 72cd13deb9945905 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 14/02/07, Douglas Otis wrote: > > On Feb 14, 2007, at 11:27 AM, Bill Cole wrote: > > As Matt and I have already pointed out, you are ignoring what the > > draft actually says in favor of believing that it says something > > you feel like arguing with. Feel free to do so wherever you like. I > > won't bother you with responses you refuse to even read. > > No where within this entire draft is the role of the network provider > mentioned or properly considered. This represents a _major_ > shortcoming in a draft purporting to provide advice to DNSBL > operators! That's presumably because the draft addresses the operational processes of a DNSBL, not its policies. Your points are advice on policy - which, however sensible, are not within the scope of the draft as currently written. > The note Matt referenced pertains to condition continuing > with respect to a _specific_ IP address. This ignores the role of > the network provider. While listings are indeed of individual IP > addresses, policy should not be limited to individual IP addresses. > The entire ASN _must_ be considered. If that's part of the published policy of the DNSBL, and hence the users of the DNSBL are expecting it, then certainly. But again, this is policy, not process. > > Do you understand what is meant by ASN? A little disingenuous, perhaps? > Do you agree network providers plays a significant role in abating spam? Not relevant within the scope of the draft. > It is completely absurd to recommend spam-friendly ISPs have their IP > addresses delisted promptly. The recommendation is that DNSBL operators have a refresh cycle, where they delist IPs that no longer meet their published criteria. If the operator has a policy of persistent listing as you suggest they should, then the refresh cycle will not result in de-listing because the criteria still apply. No problem there? > What incentive is there for spam- > friendly ISPs to change their behavior? Shouldn't this aspect of > policy be considered in any DNSBL best practices? No, because it's not part of operational best practice, it's part of the operator's policy-making process - which is subjective, politically-charged, and doesn't belong in the BCP. Peter -- Peter Bowyer Email: peter@bowyer.org _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 15:18:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQaU-0006IR-Vr; Wed, 14 Feb 2007 15:18:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHQaT-0006HP-4O for asrg@ietf.org; Wed, 14 Feb 2007 15:18:45 -0500 Received: from mail50.messagelabs.com ([195.245.230.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHQaR-00064D-OO for asrg@ietf.org; Wed, 14 Feb 2007 15:18:45 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-6.tower-50.messagelabs.com!1171484320!4568251!3 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 1958 invoked from network); 14 Feb 2007 20:18:41 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-6.tower-50.messagelabs.com with SMTP; 14 Feb 2007 20:18:41 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 20:18:40 +0000 Received: (qmail 20210 invoked from network); 14 Feb 2007 20:18:40 -0000 Received: from unknown (HELO ?10.100.0.139?) (10.100.0.139) by matt?dev.int.star.co.uk with SMTP; 14 Feb 2007 20:18:40 -0000 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Wed, 14 Feb 2007 15:18:13 -0500 To: Douglas Otis X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Feb 2007 20:18:40.0526 (UTC) FILETIME=[5117D2E0:01C75075] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 14-Feb-07, at 2:59 PM, Douglas Otis wrote: > No where within this entire draft is the role of the network > provider mentioned or properly considered. Correct. That's as it should be. The creator of a DNSBL decides its listing criteria. The draft does not hope to mandate on listing criteria, and nor should it. > The note Matt referenced pertains to condition continuing with > respect to a _specific_ IP address. Note that all listings being temporary does not mean that some listings will not remain after the initial timeout period. If the DNSBL administrator determines that the conditions for listing still exists, then the timer for determining timeouts MAY be renewed. It seems to say "listing", not "IP address". I think you need reading glasses :~) Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 17:09:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSGy-0001BJ-Ay; Wed, 14 Feb 2007 17:06:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSGx-0001B9-PM for asrg@ietf.org; Wed, 14 Feb 2007 17:06:43 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHSGv-0004ER-EA for asrg@ietf.org; Wed, 14 Feb 2007 17:06:43 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1EM6eB3010067 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 14 Feb 2007 14:06:40 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Wed, 14 Feb 2007 14:06:38 -0800 To: ASRG X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 14, 2007, at 12:18 PM, Matt Sergeant wrote: > On 14-Feb-07, at 2:59 PM, Douglas Otis wrote: > > >> No where within this entire draft is the role of the network >> provider mentioned or properly considered. >> > > Correct. That's as it should be. The creator of a DNSBL decides its > listing criteria. The draft does not hope to mandate on listing > criteria, and nor should it. > Matt, This draft however recommends a delisting policy (interval) that _specifically_ ignores the behavior of the ISP. >> The note Matt referenced pertains to condition continuing with >> respect to a _specific_ IP address. >> > > Note that all listings being temporary does not mean that some > listings will not remain after the initial timeout period. If the > DNSBL administrator determines that the conditions for listing > still exists, then the timer for determining timeouts MAY be > renewed. > > It seems to say "listing", not "IP address". I think you need > reading glasses :~) > A DNSBL listing is by IP address. This uses references similar to a reverse IP address lookup for PTR records. Surely you know that. I have not suggested that IP addresses be grouped by ASN, only that DNSBL delisting intervals be structured to induce the cooperation of network providers. Longer listings also reduce DNSBL resource expenditures, which is appropriate when the next network provider's customer, if there is one, is also likely to spam. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 17:31:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSdv-0006v3-VQ; Wed, 14 Feb 2007 17:30:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSdu-0006sR-8Z for asrg@ietf.org; Wed, 14 Feb 2007 17:30:26 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHSds-00068r-Sd for asrg@ietf.org; Wed, 14 Feb 2007 17:30:26 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1EMUFaA019519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Feb 2007 14:30:16 -0800 In-Reply-To: <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Wed, 14 Feb 2007 14:30:12 -0800 To: Peter Bowyer X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 14, 2007, at 12:13 PM, Peter Bowyer wrote: > On 14/02/07, Douglas Otis wrote: >> >> No where within this entire draft is the role of the network >> provider mentioned or properly considered. This represents a >> _major_ shortcoming in a draft purporting to provide advice to >> DNSBL operators! > > That's presumably because the draft addresses the operational > processes of a DNSBL, not its policies. Your points are advice on > policy - which, however sensible, are not within the scope of the > draft as currently written. A delisting interval is strictly related to DNSBL policy. The draft is not describing how to delist, but specifically when. This is about policy. Nothing but policy. >> The note Matt referenced pertains to conditions continuing with >> respect to a _specific_ IP address. This ignores the role of the >> network provider. While listings are indeed of individual IP >> addresses, policy should not be limited to individual IP >> addresses. The entire ASN _must_ be considered. > > If that's part of the published policy of the DNSBL, and hence the > users of the DNSBL are expecting it, then certainly. But again, > this is policy, not process. A delisting interval is purely about policy, especially when it specifically seeks to ignore the behavior of network providers. Short listing intervals for spam friendly network providers (as noted by the ASN as a whole) is recommending a bad practice. Don't be pedantic about IP addresses only to ignore the role of the network provider. >> Do you understand what is meant by ASN? > > A little disingenuous, perhaps? Don't you think this definition belongs in a BCP related to DNSBLs? >> Do you agree network providers plays a significant role in abating >> spam? > > Not relevant within the scope of the draft. Network providers and their behavior are not relevant to a DNSBL operator? If this draft is attempting to mandate that the role played by network providers are to be ignored, then yes. If this draft is attempting to define best practices aimed at abating spam, then absolutely not. Network provider's roles are significant. >> It is completely absurd to recommend spam-friendly ISPs have their >> IP addresses delisted promptly. > > The recommendation is that DNSBL operators have a refresh cycle, > where they delist IPs that no longer meet their published criteria. > If the operator has a policy of persistent listing as you suggest > they should, then the refresh cycle will not result in de-listing > because the criteria still apply. No problem there? Who said anything about a persistent listing? This is about an automatic delisting interval policy to favor those network providers that enforce an AUP that prohibits spamming. A automatic delisiting that extends beyond their typical contract period can act as an incentive for the network provider to change their policy. >> What incentive is there for spam-friendly ISPs to change their >> behavior? Shouldn't this aspect of policy be considered in any >> DNSBL best practices? > > No, because it's not part of operational best practice, it's part > of the operator's policy-making process - which is subjective, > politically-charged, and doesn't belong in the BCP. Then remove the nonsense about when to delist, and then don't fail to mention the role ASN plays with respect to the _operation_ of a DNSBL. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 17:33:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSgk-0001EU-Ga; Wed, 14 Feb 2007 17:33:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSgi-0001EK-Tk for asrg@ietf.org; Wed, 14 Feb 2007 17:33:20 -0500 Received: from mail48.messagelabs.com ([193.109.255.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHSgh-0006M4-IR for asrg@ietf.org; Wed, 14 Feb 2007 17:33:20 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-4.tower-48.messagelabs.com!1171492396!10949596!5 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 29901 invoked from network); 14 Feb 2007 22:33:17 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-4.tower-48.messagelabs.com with SMTP; 14 Feb 2007 22:33:16 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 22:33:16 +0000 Received: (qmail 20267 invoked from network); 14 Feb 2007 22:33:16 -0000 Received: from unknown (HELO ?10.100.0.139?) (10.100.0.139) by matt?dev.int.star.co.uk with SMTP; 14 Feb 2007 22:33:16 -0000 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Wed, 14 Feb 2007 17:32:50 -0500 To: Douglas Otis X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Feb 2007 22:33:16.0505 (UTC) FILETIME=[1EC06C90:01C75088] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ASRG , Peter Bowyer X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 14-Feb-07, at 5:30 PM, Douglas Otis wrote: > On Feb 14, 2007, at 12:13 PM, Peter Bowyer wrote: > >> On 14/02/07, Douglas Otis wrote: >>> >>> No where within this entire draft is the role of the network >>> provider mentioned or properly considered. This represents a >>> _major_ shortcoming in a draft purporting to provide advice to >>> DNSBL operators! >> >> That's presumably because the draft addresses the operational >> processes of a DNSBL, not its policies. Your points are advice on >> policy - which, however sensible, are not within the scope of the >> draft as currently written. > > A delisting interval is strictly related to DNSBL policy. The > draft is not describing how to delist, but specifically when. This > is about policy. Nothing but policy. Lets be more specific then: Your posts are all about listing criteria. This draft does not (and never will with me as an author) mandate listing criteria. That way lies madness. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 17:37:37 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSkd-0007TZ-RE; Wed, 14 Feb 2007 17:37:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSkc-0007TM-PE for asrg@ietf.org; Wed, 14 Feb 2007 17:37:22 -0500 Received: from mail48.messagelabs.com ([193.109.255.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHSkb-0006oj-Ch for asrg@ietf.org; Wed, 14 Feb 2007 17:37:22 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-23.tower-48.messagelabs.com!1171492639!10153644!1 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 5225 invoked from network); 14 Feb 2007 22:37:19 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-23.tower-48.messagelabs.com with SMTP; 14 Feb 2007 22:37:19 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 22:37:19 +0000 Received: (qmail 20274 invoked from network); 14 Feb 2007 22:37:19 -0000 Received: from unknown (HELO ?10.100.0.139?) (10.100.0.139) by matt?dev.int.star.co.uk with SMTP; 14 Feb 2007 22:37:19 -0000 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Wed, 14 Feb 2007 17:36:53 -0500 To: ASRG X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Feb 2007 22:37:19.0785 (UTC) FILETIME=[AFC20190:01C75088] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 14-Feb-07, at 5:06 PM, Douglas Otis wrote: > This draft however recommends a delisting policy (interval) that > _specifically_ ignores the behavior of the ISP. You are the only person who thinks that. Everyone else can see that's not the case. >>> The note Matt referenced pertains to condition continuing with >>> respect to a _specific_ IP address. >> >> Note that all listings being temporary does not mean that some >> listings will not remain after the initial timeout period. If the >> DNSBL administrator determines that the conditions for listing >> still exists, then the timer for determining timeouts MAY be >> renewed. >> >> It seems to say "listing", not "IP address". I think you need >> reading glasses :~) > > A DNSBL listing is by IP address. This uses references similar to > a reverse IP address lookup for PTR records. Surely you know that. We use the term "listing" in the draft to indicate a particular listing for a particular criteria. If the criteria causes the DNSBL to list a particular ASN for bad behaviour then the listing would consist of the range(s) belonging to that ASN. > I have not suggested that IP addresses be grouped by ASN, only that > DNSBL delisting intervals be structured to induce the cooperation > of network providers. That's a policy decision that the DNSBL can make. Nothing in this draft prevents that. > Longer listings also reduce DNSBL resource expenditures, which is > appropriate when the next network provider's customer, if there is > one, is also likely to spam. Sure. So there are two scenarios here to look at: 1) The listing is for the spammer. As long as he's spamming the listing remains. When he stops spamming we suggest that the maximum remaining time his IPs be listed is 6 months. Anything else is unfair to innocent parties who end up on a spammer's old IPs. 2) The listing is for the ASN/ISP for providing service to spammers. If the ISP stops signing up spammers then the listing will time out 6 months after the ISP stops signing up spammers. If they clean up their act we see no reason they should continue to be blocked. Whether the listing is for the spammer's individual IPs or for the ASN as a whole is, and should be, ENTIRELY up to the owner of the DNSBL. In no way do I advocate this BCP telling people what criteria they SHOULD use for their DNSBL, that way lies madness. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 17:53:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSzM-0007SF-J8; Wed, 14 Feb 2007 17:52:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHSzL-0007RU-8N for asrg@ietf.org; Wed, 14 Feb 2007 17:52:35 -0500 Received: from wr-out-0506.google.com ([64.233.184.236]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHSzI-0000E3-6L for asrg@ietf.org; Wed, 14 Feb 2007 17:52:35 -0500 Received: by wr-out-0506.google.com with SMTP id 55so635806wri for ; Wed, 14 Feb 2007 14:52:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=jSq2UJaoHAFgExvztGWEbaqW17u9PLkvP2fc3AG1jfpXcdkn3N+MBnqigLYe2dROGFDIjPS8SBDVvwlX2awZEuihPQQw1icQJ85VlMRvvXmNWxWOmiHkoyOjWtOlBo160iMfgEOgf36/tZ/Ak+BzzpQIUc+2L9ZiQGoaURbfuEY= Received: by 10.114.170.1 with SMTP id s1mr806369wae.1171493551518; Wed, 14 Feb 2007 14:52:31 -0800 (PST) Received: by 10.114.198.4 with HTTP; Wed, 14 Feb 2007 14:52:31 -0800 (PST) Message-ID: <56152ae90702141452v592936b4l435c679f4bff23a3@mail.gmail.com> Date: Wed, 14 Feb 2007 22:52:31 +0000 From: "Peter Bowyer" To: ASRG Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 In-Reply-To: <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> X-Google-Sender-Auth: b63775bf35529129 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 14/02/07, Matt Sergeant wrote: > On 14-Feb-07, at 5:30 PM, Douglas Otis wrote: > > > On Feb 14, 2007, at 12:13 PM, Peter Bowyer wrote: > > > >> On 14/02/07, Douglas Otis wrote: > >>> > >>> No where within this entire draft is the role of the network > >>> provider mentioned or properly considered. This represents a > >>> _major_ shortcoming in a draft purporting to provide advice to > >>> DNSBL operators! > >> > >> That's presumably because the draft addresses the operational > >> processes of a DNSBL, not its policies. Your points are advice on > >> policy - which, however sensible, are not within the scope of the > >> draft as currently written. > > > > A delisting interval is strictly related to DNSBL policy. The > > draft is not describing how to delist, but specifically when. This > > is about policy. Nothing but policy. > > Lets be more specific then: Your posts are all about listing > criteria. This draft does not (and never will with me as an author) > mandate listing criteria. That way lies madness. Absolutely. Diversity of policy amongst DNSBLs is good. Mandating process in order to make a given DNSBL's policy transparent and demonstrably adhered to is good. Mandating the policy is bad. Peter -- Peter Bowyer Email: peter@bowyer.org _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 18:46:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTnS-0008Hr-1D; Wed, 14 Feb 2007 18:44:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTnQ-0008H7-Ok for asrg@ietf.org; Wed, 14 Feb 2007 18:44:20 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHTnP-0007bP-Ar for asrg@ietf.org; Wed, 14 Feb 2007 18:44:20 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1ENiIxT029899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Feb 2007 15:44:18 -0800 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <013CAC2E-017D-4D99-B0F7-08291ABC7079@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Wed, 14 Feb 2007 15:44:13 -0800 To: Matt Sergeant X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 14, 2007, at 2:36 PM, Matt Sergeant wrote: > On 14-Feb-07, at 5:06 PM, Douglas Otis wrote: > >> This draft however recommends a delisting policy (interval) that >> _specifically_ ignores the behavior of the ISP. > > You are the only person who thinks that. Everyone else can see > that's not the case. ,--- | For more aggressive spammers (e.g., those operating their | own ISP) the temporary period MAY be as much as six (6) months. | However, longer periods SHOULD NOT be used since it is possible | that an IP address or domain can change hands, possibly being | allocated to a non-abusive user. '--- Restated: "Aggressive spammers operating their own ISP SHOULD NOT be blocked longer than 6 months following cessation of abuse, because the IP address might be subsequently allocated to a non-abusive user." When an ASN contains a high percentage of spammers, the likelihood that the next user (customer) is also a spammer is more likely than not. Policies and histories should not be limit to specific IP addresses, but measured by ASNs as well. The ASN measurement should be a factor in determining the duration before delisting, and not solely that of the IP address alone. >>> Note that all listings being temporary does not mean that some >>> listings will not remain after the initial timeout period. If the >>> DNSBL administrator determines that the conditions for listing >>> still exists, then the timer for determining timeouts MAY be >>> renewed. >>> >>> It seems to say "listing", not "IP address". I think you need >>> reading glasses :~) >> >> A DNSBL listing is by IP address. This uses references similar to >> a reverse IP address lookup for PTR records. Surely you know that. > > We use the term "listing" in the draft to indicate a particular > listing for a particular criteria. If the criteria causes the DNSBL > to list a particular ASN for bad behaviour then the listing would > consist of the range(s) belonging to that ASN. At times, a complete ASN might be listed. However, this does not change the erroneous statement made regarding a _policy_ of when to delist. >> I have not suggested that IP addresses be grouped by ASN, only >> that DNSBL delisting intervals be structured to induce the >> cooperation of network providers. > > That's a policy decision that the DNSBL can make. Nothing in this > draft prevents that. "However, longer periods [more than 6 months] SHOULD NOT be used since it is possible that an IP address or domain can change hands, possibly being allocated to a non-abusive user." Damn, if that is not stipulating a listing policy that ignores the behavior of the network provider. How about this for replacing the two offensive sentences: ,''' : Blocked IP addresses should be reassessed on some regular basis. : The rate and criteria used to reassess a blocked IP address : should consider the number of sources within the ASN, as well as : the abuse cessation interval from the specific IP address. In : some cases, no assessment over an interval may be used to reduce : an expenditure of resources. For ASNs where there is not a : prevalence of IP addresses issuing spam, an automatic delisting : interval should be adjusted to avoid unnecessary delisting requests. '... This would avoid a BCP paper that stipulates policy. >> Longer listings also reduce DNSBL resource expenditures, which is >> appropriate when the next network provider's customer, if there is >> one, is also likely to spam. > > Sure. So there are two scenarios here to look at: > > 1) The listing is for the spammer. As long as he's spamming the > listing remains. When he stops spamming we suggest that the maximum > remaining time his IPs be listed is 6 months. Anything else is > unfair to innocent parties who end up on a spammer's old IPs. Almost. Looking a the density of abuse within an ASN provides a good indication as to whether their next customer will also be a spammer. The idea is to make spam friendly ISPs look less attractive to spammers. This is not about treating all of their customers as if they are spammers, only that the delisting interval should carefully consider measurements of the ASN when determining their automatic delisting interval. > 2) The listing is for the ASN/ISP for providing service to > spammers. If the ISP stops signing up spammers then the listing > will time out 6 months after the ISP stops signing up spammers. If > they clean up their act we see no reason they should continue to be > blocked. Only in the most extreme cases would ASN listing be reasonable. BCP for DNSBLs should elucidate the role ASNs might play. ASNs are extremely important when the DNSBL is noting ISP policy, for example. > Whether the listing is for the spammer's individual IPs or for the > ASN as a whole is, and should be, ENTIRELY up to the owner of the > DNSBL. In no way do I advocate this BCP telling people what > criteria they SHOULD use for their DNSBL, that way lies madness. Please understand that saying when to delist is really the same as saying when to list. If you want to avoid saying when to list, then by all means avoid saying when to delist. That aside, there should also be a section that describes the role of the ASN. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 18:46:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTpo-0001Sq-Hz; Wed, 14 Feb 2007 18:46:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTpl-0001Sj-Vb for asrg@ietf.org; Wed, 14 Feb 2007 18:46:46 -0500 Received: from mail3.panix.com ([166.84.1.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHTpk-0007yE-Pd for asrg@ietf.org; Wed, 14 Feb 2007 18:46:45 -0500 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 70BD313A85A for ; Wed, 14 Feb 2007 18:46:44 -0500 (EST) Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id l1ENki817483; Wed, 14 Feb 2007 18:46:44 -0500 (EST) Date: Wed, 14 Feb 2007 18:46:44 -0500 (EST) Message-Id: <200702142346.l1ENki817483@panix5.panix.com> From: Seth Breidbart To: asrg@ietf.org In-reply-to: <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> (message from Matt Sergeant on Wed, 14 Feb 2007 17:32:50 -0500) Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Matt Sergeant wrote: > On 14-Feb-07, at 5:30 PM, Douglas Otis wrote: >> A delisting interval is strictly related to DNSBL policy. The >> draft is not describing how to delist, but specifically when. This >> is about policy. Nothing but policy. > > Lets be more specific then: Your posts are all about listing > criteria. This draft does not (and never will with me as an author) > mandate listing criteria. That way lies madness. Consider dsnbl.noprimes.org. How often do you think it's reasonable to require me to check whether a given number has turned composite while I wasn't looking? Seth _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 18:56:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTz6-000120-8e; Wed, 14 Feb 2007 18:56:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHTz4-00011k-Ks for asrg@ietf.org; Wed, 14 Feb 2007 18:56:22 -0500 Received: from mail48.messagelabs.com ([193.109.255.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHTz2-0001mm-8f for asrg@ietf.org; Wed, 14 Feb 2007 18:56:22 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-13.tower-48.messagelabs.com!1171497377!11972147!1 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 18313 invoked from network); 14 Feb 2007 23:56:17 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-13.tower-48.messagelabs.com with SMTP; 14 Feb 2007 23:56:17 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 23:56:17 +0000 Received: (qmail 20306 invoked from network); 14 Feb 2007 23:56:17 -0000 Received: from unknown (HELO ?10.100.0.139?) (10.100.0.139) by matt?dev.int.star.co.uk with SMTP; 14 Feb 2007 23:56:17 -0000 In-Reply-To: <200702142346.l1ENki817483@panix5.panix.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> <200702142346.l1ENki817483@panix5.panix.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0E589E56-044A-42BA-A6EA-ECC13C5D8B5F@messagelabs.com> Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Wed, 14 Feb 2007 18:55:50 -0500 To: Seth Breidbart X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 14 Feb 2007 23:56:17.0661 (UTC) FILETIME=[B7C082D0:01C75093] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 14-Feb-07, at 6:46 PM, Seth Breidbart wrote: > Consider dsnbl.noprimes.org. > > How often do you think it's reasonable to require me to check whether > a given number has turned composite while I wasn't looking? Quoting the BCP: With the exception of DNSBLs that that are based on data that does not change... ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 19:07:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHU9K-0005ll-No; Wed, 14 Feb 2007 19:06:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHU9J-0005lc-8s for asrg@ietf.org; Wed, 14 Feb 2007 19:06:57 -0500 Received: from mail3.panix.com ([166.84.1.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHU9A-0003yo-5A for asrg@ietf.org; Wed, 14 Feb 2007 19:06:57 -0500 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id CD49513A84C for ; Wed, 14 Feb 2007 19:06:47 -0500 (EST) Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id l1F06l111879; Wed, 14 Feb 2007 19:06:47 -0500 (EST) Date: Wed, 14 Feb 2007 19:06:47 -0500 (EST) Message-Id: <200702150006.l1F06l111879@panix5.panix.com> From: Seth Breidbart To: asrg@ietf.org In-reply-to: <0E589E56-044A-42BA-A6EA-ECC13C5D8B5F@messagelabs.com> (message from Matt Sergeant on Wed, 14 Feb 2007 18:55:50 -0500) Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> <200702142346.l1ENki817483@panix5.panix.com> <0E589E56-044A-42BA-A6EA-ECC13C5D8B5F@messagelabs.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Matt Sergeant wrote: > On 14-Feb-07, at 6:46 PM, Seth Breidbart wrote: >> Consider dsnbl.noprimes.org. >> >> How often do you think it's reasonable to require me to check whether >> a given number has turned composite while I wasn't looking? > > Quoting the BCP: > > With the exception of DNSBLs that that are based on data that does > not change... On the other hand, "I have received spam from " is data that does not change (once true). Seth _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 20:19:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHVF9-0001OC-Ar; Wed, 14 Feb 2007 20:17:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHVF8-0001NR-FL for asrg@ietf.org; Wed, 14 Feb 2007 20:17:02 -0500 Received: from mail48.messagelabs.com ([193.109.255.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHVF7-0007GY-4i for asrg@ietf.org; Wed, 14 Feb 2007 20:17:02 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-3.tower-48.messagelabs.com!1171502215!8124733!3 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 12473 invoked from network); 15 Feb 2007 01:16:56 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-3.tower-48.messagelabs.com with SMTP; 15 Feb 2007 01:16:56 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 01:16:55 +0000 Received: (qmail 20346 invoked from network); 15 Feb 2007 01:16:55 -0000 Received: from unknown (HELO ?10.100.0.139?) (10.100.0.139) by matt?dev.int.star.co.uk with SMTP; 15 Feb 2007 01:16:55 -0000 In-Reply-To: <200702150006.l1F06l111879@panix5.panix.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> <200702142346.l1ENki817483@panix5.panix.com> <0E589E56-044A-42BA-A6EA-ECC13C5D8B5F@messagelabs.com> <200702150006.l1F06l111879@panix5.panix.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Wed, 14 Feb 2007 20:16:29 -0500 To: Seth Breidbart X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Feb 2007 01:16:56.0022 (UTC) FILETIME=[FBA3CF60:01C7509E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 14-Feb-07, at 7:06 PM, Seth Breidbart wrote: > On the other hand, "I have received spam from " is data that does > not change (once true). I'm not sure whether you're just trying to be contrary of if you have a real point. If the latter please state it more clearly. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 20:34:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHVVm-0002Vh-Tm; Wed, 14 Feb 2007 20:34:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHVVl-0002Vc-Ou for asrg@ietf.org; Wed, 14 Feb 2007 20:34:13 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHVVk-0002Ug-3N for asrg@ietf.org; Wed, 14 Feb 2007 20:34:13 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l1F1Y9f25265 for ; Wed, 14 Feb 2007 20:34:09 -0500 (EST) Received: from [47.9.16.209] ([47.9.16.209] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 20:33:42 -0500 Message-ID: <45D3B870.1050403@nortel.com> Date: Wed, 14 Feb 2007 20:33:36 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: asrg@ietf.org Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> <200702142346.l1ENki817483@panix5.panix.com> In-Reply-To: <200702142346.l1ENki817483@panix5.panix.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Feb 2007 01:33:43.0134 (UTC) FILETIME=[53ECE7E0:01C750A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Seth Breidbart wrote: > Matt Sergeant wrote: >> On 14-Feb-07, at 5:30 PM, Douglas Otis wrote: > >>> A delisting interval is strictly related to DNSBL policy. The >>> draft is not describing how to delist, but specifically when. This >>> is about policy. Nothing but policy. >> Lets be more specific then: Your posts are all about listing >> criteria. This draft does not (and never will with me as an author) >> mandate listing criteria. That way lies madness. > > Consider dsnbl.noprimes.org. > > How often do you think it's reasonable to require me to check whether > a given number has turned composite while I wasn't looking? With today's processors, it should be easy to go thru 2^^32 numbers in six months. But I think you'd be forgiven in assuming that the prime/nonprimeship of a number won't change spontaneously. Or, are you expecting some to do so? ;-) DNSBLs aren't punishment methods. First and foremost they're methods on blocking abuse. If a bad actor isn't acting bad enough to be obvious that they're abusing for a period of six months, the loss of a listing means nothing in the scheme of things, and soon corrected if it turns out to be wrong/being gamed. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 20:36:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHVY2-0005Hz-SO; Wed, 14 Feb 2007 20:36:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHVY2-0005Hs-Du for asrg@ietf.org; Wed, 14 Feb 2007 20:36:34 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHVXy-0002pH-UO for asrg@ietf.org; Wed, 14 Feb 2007 20:36:34 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l1F1aSf25484 for ; Wed, 14 Feb 2007 20:36:28 -0500 (EST) Received: from [47.9.16.209] ([47.9.16.209] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 14 Feb 2007 20:36:13 -0500 Message-ID: <45D3B8EE.1050705@nortel.com> Date: Wed, 14 Feb 2007 20:35:42 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> <200702142346.l1ENki817483@panix5.panix.com> <0E589E56-044A-42BA-A6EA-ECC13C5D8B5F@messagelabs.com> <200702150006.l1F06l111879@panix5.panix.com> In-Reply-To: <200702150006.l1F06l111879@panix5.panix.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Feb 2007 01:36:14.0337 (UTC) FILETIME=[AE0CA710:01C750A1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Seth Breidbart wrote: > Matt Sergeant wrote: >> On 14-Feb-07, at 6:46 PM, Seth Breidbart wrote: > >>> Consider dsnbl.noprimes.org. >>> >>> How often do you think it's reasonable to require me to check whether >>> a given number has turned composite while I wasn't looking? >> Quoting the BCP: >> >> With the exception of DNSBLs that that are based on data that does >> not change... > > On the other hand, "I have received spam from " is data that does > not change (once true). Then a 6 month timeout wouldn't apply, would it? Entirely aside from the fact that a DNSBL listing on that basis would, in the fullness of time, list just about every IP in existance. Everybody leaks. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 20:43:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHVe0-0000f3-TM; Wed, 14 Feb 2007 20:42:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHVdx-0000aG-Bz for asrg@ietf.org; Wed, 14 Feb 2007 20:42:41 -0500 Received: from mail3.panix.com ([166.84.1.74]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHVdv-0003rV-V0 for asrg@ietf.org; Wed, 14 Feb 2007 20:42:41 -0500 Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mail3.panix.com (Postfix) with ESMTP id 6B09013A76A for ; Wed, 14 Feb 2007 20:42:35 -0500 (EST) Received: (from sethb@localhost) by panix5.panix.com (8.11.6p3/8.8.8/PanixN1.1) id l1F1gZ417199; Wed, 14 Feb 2007 20:42:35 -0500 (EST) Date: Wed, 14 Feb 2007 20:42:35 -0500 (EST) Message-Id: <200702150142.l1F1gZ417199@panix5.panix.com> From: Seth Breidbart To: asrg@ietf.org In-reply-to: (message from Matt Sergeant on Wed, 14 Feb 2007 20:16:29 -0500) Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> <200702142346.l1ENki817483@panix5.panix.com> <0E589E56-044A-42BA-A6EA-ECC13C5D8B5F@messagelabs.com> <200702150006.l1F06l111879@panix5.panix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Matt Sergeant wrote: > On 14-Feb-07, at 7:06 PM, Seth Breidbart wrote: >> On the other hand, "I have received spam from " is data that does >> not change (once true). > > I'm not sure whether you're just trying to be contrary of if you have > a real point. If the latter please state it more clearly. "Facts that don't change" isn't quite what I'd want to say; true facts can become irrelevant or outdated (that is, useless) while remaining true. Seth _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 14 21:15:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHW8L-0002u2-C4; Wed, 14 Feb 2007 21:14:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHW8K-0002tB-C6 for asrg@ietf.org; Wed, 14 Feb 2007 21:14:04 -0500 Received: from mail50.messagelabs.com ([195.245.230.67]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HHW8I-0002FL-Vj for asrg@ietf.org; Wed, 14 Feb 2007 21:14:04 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-5.tower-50.messagelabs.com!1171505638!4204091!1 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 25858 invoked from network); 15 Feb 2007 02:13:58 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-5.tower-50.messagelabs.com with SMTP; 15 Feb 2007 02:13:58 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 02:13:58 +0000 Received: (qmail 20381 invoked from network); 15 Feb 2007 02:13:58 -0000 Received: from unknown (HELO ?10.100.0.139?) (10.100.0.139) by matt?dev.int.star.co.uk with SMTP; 15 Feb 2007 02:13:58 -0000 In-Reply-To: <200702150142.l1F1gZ417199@panix5.panix.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> <200702142346.l1ENki817483@panix5.panix.com> <0E589E56-044A-42BA-A6EA-ECC13C5D8B5F@messagelabs.com> <200702150006.l1F06l111879@panix5.panix.com> <200702150142.l1F1gZ417199@panix5.panix.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Wed, 14 Feb 2007 21:13:32 -0500 To: Seth Breidbart X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Feb 2007 02:13:58.0578 (UTC) FILETIME=[F3A46920:01C750A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 14-Feb-07, at 8:42 PM, Seth Breidbart wrote: > Matt Sergeant wrote: >> On 14-Feb-07, at 7:06 PM, Seth Breidbart wrote: > >>> On the other hand, "I have received spam from " is data that >>> does >>> not change (once true). >> >> I'm not sure whether you're just trying to be contrary of if you have >> a real point. If the latter please state it more clearly. > > "Facts that don't change" isn't quite what I'd want to say; true facts > can become irrelevant or outdated (that is, useless) while remaining > true. True enough. That portion of the BCP is aimed at DNSBLs such as blackholes.us and Steve Champion's Enemies List, which are basically targeted at static data. Though to be honest after having the discussion here I'm not sure that even matters much - because the listing criteria just continues to exist for those DNSBLs. If you have better wording we'd appreciate assistance. Matt. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 15 02:28:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHazM-0006JB-0a; Thu, 15 Feb 2007 02:25:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHazK-0006BJ-QR for asrg@ietf.org; Thu, 15 Feb 2007 02:25:06 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHapw-0000aG-6H for asrg@ietf.org; Thu, 15 Feb 2007 02:15:25 -0500 Received: from [192.168.2.40] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1F7FNZm008754 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 14 Feb 2007 23:15:23 -0800 Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 From: Douglas Otis To: Chris Lewis In-Reply-To: <45D3B870.1050403@nortel.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> <3EA4678D-DA44-41C1-8983-B03E93F6A1CA@mail-abuse.org> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> <200702142346.l1ENki817483@panix5.panix.com> <45D3B870.1050403@nortel.com> Content-Type: text/plain Date: Wed, 14 Feb 2007 23:15:22 -0800 Message-Id: <1171523722.3230.171.camel@dcore.sonic.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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, 2007-02-14 at 20:33 -0500, Chris Lewis wrote: > > DNSBLs aren't punishment methods. First and foremost they're methods on > blocking abuse. If a bad actor isn't acting bad enough to be obvious > that they're abusing for a period of six months, the loss of a listing > means nothing in the scheme of things, and soon corrected if it turns > out to be wrong/being gamed. DNSBLs are to block messages, which in itself might be considered a form of punishment. There is a cost that is not being considered in the draft. Maintaining records of spam received, as recommended, represents a sizable expense. When a particular ASN does not enforce AUPs that prohibit spamming, then ignoring traffic from their listed IP addresses for some extended period offers significant savings in storage, servers, and network bandwidth. The difference is significant. When the ASN is large and offers bandwidth without enforcement, each delisting has the effect of making their service more attractive to spammers, even if only for a brief period. Changing accounts is the spammers' cost of doing business. When an ASN lacks self enforcement and hosts a high density of spammers, a best practice should be to pause the logging of abuse for some period, and delay the individual IP address' delisting. Concerns about the next user of ASNs that lack enforcement rightfully diminishes. There is a good chance the next user will also be a spammer anyway. A recommendation for maximal delisting interval of 6 months for ASNs that make an effort to enforce anti-spam AUPs is not a problem for DNSBL operations. However, the current draft wishes to ignore spam-friendly behavior of some ASNs, and that would constitute a bad practice from the perspective of economically running DNSBLs, as well as ensuring DNSBLs remain effective at abating spam. The network provider plays a critical role in abating spam. When the network provider is not a partner in abatement, it is unfair and costly to allow those without enforcement to consume additional resources in order to maintain a constant automatic delisting interval. ASNs that enforce anti-spam AUPs deserve these limited resources. A best practice MUST consider the behavior of the network provider as denoted by the ASN. This should be part of any DNSBL best practice. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 15 10:46:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHijY-0000E9-JZ; Thu, 15 Feb 2007 10:41:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHijX-0000Ai-1d for asrg@ietf.org; Thu, 15 Feb 2007 10:41:19 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHijI-0001bt-Uf for asrg@ietf.org; Thu, 15 Feb 2007 10:41:19 -0500 Received: from [192.168.2.40] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1FFf3Z5018043 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 15 Feb 2007 07:41:04 -0800 Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 From: Douglas Otis To: Matt Sergeant In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <45CBBFE3.E2@xyzzy.claranet.de> <61EAC50C-5E91-4523-B389-665F7B2E3F54@messagelabs.com> <39B28A7C-B82F-4CA9-96B5-5068E9EBD825@mail-abuse.org> <3320938C-4336-45B7-8F03-26ADE4069A9B@mail-abuse.org> <5A4166B7-B0BD-476D-A56B-74DFBB8CA6BB@messagelabs.com> <32D0F09C-3B56-484B-B5B3-41F056EDE0A2@mail-abuse.org> Content-Type: text/plain Date: Thu, 15 Feb 2007 07:41:03 -0800 Message-Id: <1171554063.3230.190.camel@dcore.sonic.net> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ASRG X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Mon, 2007-02-12 at 22:46 -0500, Matt Sergeant wrote: > On 12-Feb-07, at 5:28 PM, Douglas Otis wrote: > > > A year is likely to be a typical interval for bulk service agreements. > > I'm not sure why you keep persisting on this point. If the criteria > for the DNSBL is something like "a known spammer has service on this > IP/range" then after (or before) the timeout period the DNSBL must re- > check that the spammer still has service on that IP/range, and > confirm that indeed the spammer does. Thus the listing is extended > beyond the 6 month period. It could last forever for all we care, as > long as the listing criteria STILL EXISTS. The network provider owns the IP address. They own an entire range of IP addresses as determined by their ASN. The entity that is spamming is often NOT the network provider, but instead is one of their customers. Only in very rare cases would a listing be based upon the ASN. Listing criteria often requires monitoring for spam from a specific IP address. Monitoring for spam has a cost. > I'll repeat myself again: this BCP in NO WAY forces delisting after > the timeout period. It makes that clear - you just choose not to read > that part for some reason. The suggested text requires that these IP addresses be monitored in order to delist within the interval being recommended, unless of course the entire ASN is being listed, which is rare. > I'm done arguing this with you now. We'll discuss between the authors > if we think 6 months is the wrong time period but you haven't > presented any decent argument for it IMHO. The premise that 6 months is okay seems based upon Spamhaus suggesting that this their policy. There are a few differences with respect to what Spamhaus can do and what an enterprise working with United States can do. England, where Spamhaus resides makes spamming illegal. There is also a substantially different liability with respect legal fees when being sued in the United States versus England as well. Every listing by a company that has residence within the United States must be prepared with a full set of records tracking everything related to the ASN, the IP address, complaints, replies, etc. This tracking system is likely to be much larger and far more expensive as a result. I wish the spam laws for the United States were more like that found in England. They are not however. Please don't suggest that this draft is NOT dictating a listing policy and then recommend when an IP address should be delisted! -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 15 14:19:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHm61-0003OP-Fh; Thu, 15 Feb 2007 14:16:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHm5z-0003HU-VK for asrg@ietf.org; Thu, 15 Feb 2007 14:16:43 -0500 Received: from nz-out-0506.google.com ([64.233.162.235]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHm5v-0000hy-Mi for asrg@ietf.org; Thu, 15 Feb 2007 14:16:43 -0500 Received: by nz-out-0506.google.com with SMTP id z6so690358nzd for ; Thu, 15 Feb 2007 11:16:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZjChk2qlZFbimWf8Tz6CAwHr3z7tjHiOerdvsyYI/yxNL0Kx44evjZrvOoWsZspvK17ZwYKTPqA28feZYbzsyEZJxxNhwCUseK7a/RnZkKCyq0tMOcGs7Ul6f+jvqxJfga1GC51Yn51BwdxAmrL6szXP9+7FbbhnT3RidVMFrdE= Received: by 10.65.210.18 with SMTP id m18mr3465188qbq.1171566998450; Thu, 15 Feb 2007 11:16:38 -0800 (PST) Received: by 10.65.150.15 with HTTP; Thu, 15 Feb 2007 11:16:38 -0800 (PST) Message-ID: <54709c090702151116s6cc97dcagf47222b36a9b3177@mail.gmail.com> Date: Thu, 15 Feb 2007 13:16:38 -0600 From: "Al Iverson" To: asrg@ietf.org Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> <200702142346.l1ENki817483@panix5.panix.com> <0E589E56-044A-42BA-A6EA-ECC13C5D8B5F@messagelabs.com> <200702150006.l1F06l111879@panix5.panix.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Hello all, I'm new to the list. A lot of familiar names here. If you don't know me, I've created a few different DNSBLs, mostly back they were lovingly crafted out of shell scripts using stone knives and bearskins. Lately I've started cataloging dead DNSBLs and writing up DNSBL reviews on www.dnsbl.com, a site of mine. Forgive me if I'm rehashing something already talked about; didn't seem that way to me from my cursory research. One thing that strikes me as missing from the BCP is some guidance on usage and implementation in spam filtering and blocking applications. In particular, technical guidance regarding whether or not a DNSBL actually exists and can be queried. As I am learning from diving back in to the thick of DNSBL-related things lately, I see - Paul Vixie struggling with DNSBL traffic against rbl.maps.vix.com years after the RBL moved away from that FQDN. - Other lists randomly vanishing with no warning and continuing to get DNSBL traffic for years - Blars, for example, vanished in December and now lists the world. - LBL (lbl.lagengymnastik.dk) wound down in 2003 but still getting hits years later, resorting to listing the world. - The occasional ignorant sod who queries something like random.dnsbl.maps.com which causes unwanted traffic (and potential unwanted mail blocking) from various sites. (You'll note that maps.com has a wildcard, for example.) Maybe this is outside of the scope, and if so, I apologize. But if appropriate, it seems wise to have some guidance included about how to avoid these situations, preferably recommended that checks be implemented in software to confirm that a list an application is checking actually exists and really is a DNSBL. It not only protects ignorant DNSBL users from themselves (which I grant some folks probably don't care much about), but it helps reduce pain for anyone who gracefully shuts down a DNSBL (and their upstream, and the root zones, depending on how it's done). In the future, I'd love to be able to point to something RFC-like that says what best practice is in this area, and be able to point that out to companies who try to build a marketing strategy around selling fancy rackmount anti-spam devices that are actually just linux boxes with SpamAssassin and DNSBL support on them. Would love to hear your thoughts and feedback. Regards, Al Iverson -- Al Iverson on Spam and Deliverabilty, see http://www.spamresource.com Message copyright 2007 by Al Iverson. For posts to SPAM-L, permission is granted only to this lists's owners to redistribute to their sub- scribers and to archive this message on site(s) under their control. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 15 15:09:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHmu5-0006yT-Kw; Thu, 15 Feb 2007 15:08:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHmu4-0006yN-I8 for asrg@ietf.org; Thu, 15 Feb 2007 15:08:28 -0500 Received: from everest.sosdg.org ([66.93.203.161] helo=mail.sosdg.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHmu3-0004gq-5L for asrg@ietf.org; Thu, 15 Feb 2007 15:08:28 -0500 Received: from nc-76-0-171-233.dhcp.embarqhsd.net ([76.0.171.233] helo=[172.16.15.42] ident=6e57e5f1) by mail.sosdg.org with esmtpa (Exim 4.63-SOSDG) id 1HHmtq-0000IC-64 by authid ; Thu, 15 Feb 2007 15:08:14 -0500 Message-ID: <45D4BD92.6030200@ahbl.org> Date: Thu, 15 Feb 2007 15:07:46 -0500 From: Stephanie Erin Daugherty User-Agent: Icedove 1.5.0.9 (X11/20061220) MIME-Version: 1.0 To: asrg@ietf.org Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> <200702142346.l1ENki817483@panix5.panix.com> <0E589E56-044A-42BA-A6EA-ECC13C5D8B5F@messagelabs.com> <200702150006.l1F06l111879@panix5.panix.com> <54709c090702151116s6cc97dcagf47222b36a9b3177@mail.gmail.com> In-Reply-To: <54709c090702151116s6cc97dcagf47222b36a9b3177@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Warning: 76.0.171.233 is in a black list at dnsbl.sorbs.net X-Scan-Signature: ce21113bd12aaf7d53962de4c3292a8b X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org Al Iverson wrote: > Hello all, > > I'm new to the list. A lot of familiar names here. If you don't know > me, I've created a few different DNSBLs, mostly back they were > lovingly crafted out of shell scripts using stone knives and > bearskins. Lately I've started cataloging dead DNSBLs and writing up > DNSBL reviews on www.dnsbl.com, a site of mine. Good to see that you are still around. :) I think I remember at least a couple of those stone knife and bearskin lists. > One thing that strikes me as missing from the BCP is some guidance on > usage and implementation in spam filtering and blocking applications. > In particular, technical guidance regarding whether or not a DNSBL > actually exists and can be queried. As I am learning from diving back > in to the thick of DNSBL-related things lately, I see > - Paul Vixie struggling with DNSBL traffic against rbl.maps.vix.com > years after the RBL moved away from that FQDN. > - Other lists randomly vanishing with no warning and continuing to get > DNSBL traffic for years > - Blars, for example, vanished in December and now lists the world. > - LBL (lbl.lagengymnastik.dk) wound down in 2003 but still getting > hits years later, resorting to listing the world. > - The occasional ignorant sod who queries something like > random.dnsbl.maps.com which causes unwanted traffic (and potential > unwanted mail blocking) from various sites. (You'll note that maps.com > has a wildcard, for example.) > One of the best pieces of advice I can give for this is to put a DNSBL on a domain specifically registered for the purpose -- while it's possible to run one within a subdomain, I would recommend strongly against it, getting rid of the query traffic if you later shut down is truly next to impossible, and if you have a dedicated domain, it's easier to kill the nameservers for it that it would for a domain that has to remain active even after the DNSBL dies. In other words, a DNSBL on a domain pretty much poisons it for years to come with substantial volumes of traffic. Needless to say, this also places a special responsibility on DNSBL operators for making sure that their domain registrations stay active and secure - if allowed to expire prematurely, the impact to downstream users can be significant, and if allowed to be hijacked malicious entries could be placed which may result in a denial of service to legitimate users. > Maybe this is outside of the scope, and if so, I apologize. But if > appropriate, it seems wise to have some guidance included about how to > avoid these situations, preferably recommended that checks be > implemented in software to confirm that a list an application is > checking actually exists and really is a DNSBL. A standard "listed" test entry and standard "not listed" test entry are a good way to test that. Standard practice right now usually uses 2.0.0.127.dnsbl.example.com or some variant as the "always listed" address - adding a requirement for a "never listed" address would be a good way to implement an additional check to make sure the DNSBL is still active, and hopefully that it's not listing the world. I'm not sure that we have a standard convention for a "never listed" test address (one that should always return a whitelist record or NXDOMAIN depending on the type of list.) _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 15 15:42:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHnPH-0005GS-58; Thu, 15 Feb 2007 15:40:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHnPF-0005Fu-Ls for asrg@ietf.org; Thu, 15 Feb 2007 15:40:41 -0500 Received: from fruitbat.wordtothewise.com ([208.187.80.135] helo=m.wordtothewise.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHnPE-0007mi-Dx for asrg@ietf.org; Thu, 15 Feb 2007 15:40:41 -0500 Received: from [10.3.2.25] (184.word-to-the-wise.com [208.187.80.184]) by m.wordtothewise.com (Postfix) with ESMTP id 1AAFB4F8D71 for ; Thu, 15 Feb 2007 12:40:25 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <45D4BD92.6030200@ahbl.org> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> <200702142346.l1ENki817483@panix5.panix.com> <0E589E56-044A-42BA-A6EA-ECC13C5D8B5F@messagelabs.com> <200702150006.l1F06l111879@panix5.panix.com> <54709c090702151116s6cc97dcagf47222b36a9b3177@mail.gmail.com> <45D4BD92.6030200@ahbl.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Steve Atkins Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Thu, 15 Feb 2007 12:40:22 -0800 To: ASRG list X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 15, 2007, at 12:07 PM, Stephanie Erin Daugherty wrote: > > A standard "listed" test entry and standard "not listed" test entry > are a good way to test that. Standard practice right now usually > uses 2.0.0.127.dnsbl.example.com or some variant as the "always > listed" address - adding a requirement for a "never listed" address > would be a good way to implement an additional check to make sure > the DNSBL is still active, and hopefully that it's not listing the > world. I'm not sure that we have a standard convention for a "never > listed" test address (one that should always return a whitelist > record or NXDOMAIN depending on the type of list.) 1.0.0.127. There. We have an always listed and a never listed address that are already done by the vast majority of blacklists[1]. All we need is client side support for those two checks and we're done. Cheers, Steve [1] OK, I run two blacklists and neither of them supports both of those records, but they're kinda special cases... _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Thu Feb 15 17:30:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHp55-00039M-3y; Thu, 15 Feb 2007 17:27:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHp53-00036V-Pr for asrg@ietf.org; Thu, 15 Feb 2007 17:27:57 -0500 Received: from nz-out-0506.google.com ([64.233.162.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHp50-00055a-G2 for asrg@ietf.org; Thu, 15 Feb 2007 17:27:57 -0500 Received: by nz-out-0506.google.com with SMTP id z6so748368nzd for ; Thu, 15 Feb 2007 14:27:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=sP1w+MmD4PmXH9wisrjzB21W0TRahSFnqiaQg2LgnoUuzO8q7YRIZU0/CINfYoFhwe7gqrNixIcZPWrBO2itHUjm8DqwhquASkXdi1+fUXGc4NKzgGdlm3zsKrpTKkb1F/QLjPfYEbBGzZ+MvRFz4CpEfxN6HxRJMfsApS9npVo= Received: by 10.65.237.15 with SMTP id o15mr3767921qbr.1171578472987; Thu, 15 Feb 2007 14:27:52 -0800 (PST) Received: by 10.65.150.15 with HTTP; Thu, 15 Feb 2007 14:27:52 -0800 (PST) Message-ID: <54709c090702151427v3a025911i564e71da9b3483c4@mail.gmail.com> Date: Thu, 15 Feb 2007 16:27:52 -0600 From: "Al Iverson" To: asrg@ietf.org Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 In-Reply-To: <45D4BD92.6030200@ahbl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> <200702142346.l1ENki817483@panix5.panix.com> <0E589E56-044A-42BA-A6EA-ECC13C5D8B5F@messagelabs.com> <200702150006.l1F06l111879@panix5.panix.com> <54709c090702151116s6cc97dcagf47222b36a9b3177@mail.gmail.com> <45D4BD92.6030200@ahbl.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 2/15/07, Stephanie Erin Daugherty wrote: > > One thing that strikes me as missing from the BCP is some guidance on > > usage and implementation in spam filtering and blocking applications. > > In particular, technical guidance regarding whether or not a DNSBL > > actually exists and can be queried. As I am learning from diving back > > in to the thick of DNSBL-related things lately, I see > > - Paul Vixie struggling with DNSBL traffic against rbl.maps.vix.com > > years after the RBL moved away from that FQDN. > > - Other lists randomly vanishing with no warning and continuing to get > > DNSBL traffic for years > > - Blars, for example, vanished in December and now lists the world. > > - LBL (lbl.lagengymnastik.dk) wound down in 2003 but still getting > > hits years later, resorting to listing the world. > > - The occasional ignorant sod who queries something like > > random.dnsbl.maps.com which causes unwanted traffic (and potential > > unwanted mail blocking) from various sites. (You'll note that maps.com > > has a wildcard, for example.) > > > One of the best pieces of advice I can give for this is to put a DNSBL > on a domain specifically registered for the purpose -- while it's > possible to run one within a subdomain, I would recommend strongly > against it, getting rid of the query traffic if you later shut down is > truly next to impossible, and if you have a dedicated domain, it's > easier to kill the nameservers for it that it would for a domain that > has to remain active even after the DNSBL dies. I agree that it is probably unwise to use a DNSBL domain for anything else, or to expect to be able to reclaim it when done with the DNSBL. The recent shutdown of ORDB makes me suspect that abandoning the domain after you're done with the DNSBL might not be good enough. Here's why. If I'm recalling this correctly, what happened was that ORDB killed the DNSBL and left the domain configured with no nameservers in place. This left the queries to die at the .org root level, and it basically pounded the .org infrastructure flat. One of the folks in charge of .org reached out to an anti-spam community and was able to reach back to the blacklist maintainers and some other folks, to come up with a plan to solve it. But, things definitely sucked for a few days, and not every situation like this is so quickly resolved. And I assume the fix simply siphons the traffic off to somebody else's network, instead of actually stopping it. So, leaving the domain behind definitely helps the network that previously hosted the DNSBL, but it could potentially just push gobs of queries upstairs. (Some of this detail came from a discussion on a private mailing list; I got permission from the person behind that discussion to reference it here. I woudl also add that this isn't a shot at the ORDB folks; more than anything it just highlights that there isn't a BCP to handle these kind of things.) Regards, Al Iverson -- Al Iverson on Spam and Deliverabilty, see http://www.spamresource.com Message copyright 2007 by Al Iverson. For posts to SPAM-L, permission is granted only to this lists's owners to redistribute to their sub- scribers and to archive this message on site(s) under their control. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Fri Feb 16 10:25:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4us-0006U0-OJ; Fri, 16 Feb 2007 10:22:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI4uq-0006Tq-My for asrg@ietf.org; Fri, 16 Feb 2007 10:22:28 -0500 Received: from mail48.messagelabs.com ([193.109.255.3]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HI4up-0007tn-BX for asrg@ietf.org; Fri, 16 Feb 2007 10:22:28 -0500 X-VirusChecked: Checked X-Env-Sender: msergeant@messagelabs.com X-Msg-Ref: server-15.tower-48.messagelabs.com!1171639345!3199270!3 X-StarScan-Version: 5.5.10.7.1; banners=messagelabs.com,-,- X-Originating-IP: [62.231.131.6] Received: (qmail 14629 invoked from network); 16 Feb 2007 15:22:25 -0000 Received: from mlbrn2exc001.messagelabs.com (HELO mlbrn2exc001.messagelabs.com) (62.231.131.6) by server-15.tower-48.messagelabs.com with SMTP; 16 Feb 2007 15:22:25 -0000 Received: from matt-dev.int.star.co.uk ([10.191.110.53]) by mlbrn2exc001.messagelabs.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 16 Feb 2007 15:22:25 +0000 Received: (qmail 24675 invoked from network); 16 Feb 2007 15:22:24 -0000 Received: from unknown (HELO ?10.100.0.139?) (10.100.0.139) by matt?dev.int.star.co.uk with SMTP; 16 Feb 2007 15:22:24 -0000 In-Reply-To: References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <56152ae90702141213j35f7a4dagd24418d37b8ca700@mail.gmail.com> <34F9CE07-7C68-4CB9-B710-AADA62C3BC29@messagelabs.com> <200702142346.l1ENki817483@panix5.panix.com> <0E589E56-044A-42BA-A6EA-ECC13C5D8B5F@messagelabs.com> <200702150006.l1F06l111879@panix5.panix.com> <54709c090702151116s6cc97dcagf47222b36a9b3177@mail.gmail.com> <45D4BD92.6030200@ahbl.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8B76AF37-BE4E-4997-AB72-6DF34461172B@messagelabs.com> Content-Transfer-Encoding: 7bit From: Matt Sergeant Subject: Re: [Asrg] Re: DNSBL BCP v.2.0 Date: Fri, 16 Feb 2007 10:21:56 -0500 To: Steve Atkins X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Feb 2007 15:22:25.0304 (UTC) FILETIME=[430FB180:01C751DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ASRG list X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 15-Feb-07, at 3:40 PM, Steve Atkins wrote: >> A standard "listed" test entry and standard "not listed" test >> entry are a good way to test that. Standard practice right now >> usually uses 2.0.0.127.dnsbl.example.com or some variant as the >> "always listed" address - adding a requirement for a "never >> listed" address would be a good way to implement an additional >> check to make sure the DNSBL is still active, and hopefully that >> it's not listing the world. I'm not sure that we have a standard >> convention for a "never listed" test address (one that should >> always return a whitelist record or NXDOMAIN depending on the type >> of list.) > > 1.0.0.127. > > There. We have an always listed and a never listed address that are > already done by the vast majority of blacklists[1]. All we need is > client side support for those two checks and we're done. Yup, this was suggested earlier in this thread (before it diverged into the timeout thread) and I think it's a worthwhile addition to the DNSBL. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Feb 20 19:17:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJf65-0008US-Cm; Tue, 20 Feb 2007 19:12:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJf64-0008TU-9h for asrg@ietf.org; Tue, 20 Feb 2007 19:12:36 -0500 Received: from ns1.qubic.net ([208.185.248.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJf62-00059D-SY for asrg@ietf.org; Tue, 20 Feb 2007 19:12:36 -0500 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.0/8.14.0) with ESMTP id l1L0C8Vn001469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Feb 2007 16:12:19 -0800 (PST) DKIM-Signature: a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1172016741; bh=gnFER/HgBGlrn3C6q19BfOZ//cEjCsjbGBa97zp2Xuc=; h=DomainKey-Signature: Message-Id:X-Mailer:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type; b=Rpg+Dgr25NITWs7771+xh7WascUokNO+luVuCC NBIAA1w7+RLaoYYfbONt+Mzes5DUQZflF1SdDx/O6yivJxYbJFE7w74IohzC7Al4PUS 6LifTr2o8aSZKcuOdFQ1v14++D+f/S/1DSobrgybr9Am4fK1bGqyoA55UI6bizQJmM= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=IgpSGRazAtnZpASuKMFlgeiaaaR7j+PSf4rZjvxF4VvQcUvTfREtsOvMRArs/ZYAL uZH3HaOIqF2/FQY6VDRDJIhUmFsKRr4tWVNsbOsEBhzDv84dVeRRRr6czOF8Og7hKKy KeJ6jAuhaq969Z+uDn0aFBpt97Rva9FpbxAFQD4= Message-Id: <6.2.5.6.2.20070220151704.0259a9a0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 20 Feb 2007 16:11:36 -0800 To: asrg@ietf.org From: SM Subject: Re: [Asrg] DNSBL BCP v.2.0 In-Reply-To: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.i ntermedia.net> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org At 13:22 08-02-2007, Nick Nicholas wrote: >1.2. Guidance for DNSBL Users > > When choosing to adopt a DNSBL, an administrator should keep the > following questions in mind: > > 1. What is the intended use of the list? DNSBLs don't always specify SMTP blocking as the intended use. Maybe this should be "What is the listing policy?" > 7. What are the demographics and quantity of the list's user base? Such information is rarely published. Point 8 is a better guideline. >2.1. Transparency. > > A DNSBL SHOULD carefully describe the criteria which are the cause > for adding, and the criteria for removing an IP address or domain Shouldn't this be a MUST so that the user has better guidance in choosing a DNSBL? > Availability of documentation concerning a DNSBL SHOULD NOT be > dependent on the continued operation of DNS for the DNSBL zone file. > In other words, if the DNSBL documentation is located at > http://example.com/dnsbl/, the documentation web site SHOULD remain > available even if the DNSBL zone file is not available. See also > Section 3.2 If a DNSBL ceases operations, the domain registration may lapse or else the web server is unreachable. The above requirement is generally not followed. >3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion. > > When a DNSBL ceases operations and is taken out of circulation, > it MUST do so in a graceful manner so that it does not create > excessive DNS queries or list the entire Internet. > > The recommended approach is to put the DNSBL in its own second > level domain, and then point the DNS NS records for that second > level domain to 127.255.255.255. The TTL for that record should be > set at the maximum allowed period of one week. Using a broadcast address may have unintended consequences. I suggest using 192.0.2.2. Some DNSBL operators list the entire Internet because they keep receiving queries years after the DNSBL has ceased operation. It may be better to include a note for people implementing DNSBL features in their software to prevent such behavior. They could use a test point to determine whether the DNSBL is still active. This is the best way to avoid excessive DNS queries. Regards, -sm _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Feb 20 20:13:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJg2S-0005lK-Rp; Tue, 20 Feb 2007 20:12:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJg2S-0005l7-4c for asrg@ietf.org; Tue, 20 Feb 2007 20:12:56 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJg2Q-0000bj-PA for asrg@ietf.org; Tue, 20 Feb 2007 20:12:56 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id l1L14h609139 for ; Tue, 20 Feb 2007 20:04:43 -0500 (EST) Received: from [47.9.16.204] ([47.9.16.204] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 20:12:45 -0500 Message-ID: <45DB9C86.6070809@nortel.com> Date: Tue, 20 Feb 2007 20:12:38 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: asrg@ietf.org Subject: Re: [Asrg] DNSBL BCP v.2.0 References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <6.2.5.6.2.20070220151704.0259a9a0@resistor.net> In-Reply-To: <6.2.5.6.2.20070220151704.0259a9a0@resistor.net> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Feb 2007 01:12:45.0767 (UTC) FILETIME=[64F46D70:01C75555] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 SM wrote: > At 13:22 08-02-2007, Nick Nicholas wrote: >> 7. What are the demographics and quantity of the list's user base? > > Such information is rarely published. Point 8 is a better guideline. I think the intent here is not that the DNSBL publishes it (they often don't know), but the user should consider this - eg: do other site like me use it? >> 2.1. Transparency. >> >> A DNSBL SHOULD carefully describe the criteria which are the cause >> for adding, and the criteria for removing an IP address or domain > > Shouldn't this be a MUST so that the user has better guidance in > choosing a DNSBL? This is compromise wording. Some DNSBLs can't publish full criteria, because that would allow spammers to avoid it. Rather than get into quibbles over what constitutes "criteria", soften it a bit to SHOULD. >> 3.2. Cessation of List Operations MUST Be Done in a Graceful Fashion. >> >> When a DNSBL ceases operations and is taken out of circulation, >> it MUST do so in a graceful manner so that it does not create >> excessive DNS queries or list the entire Internet. >> >> The recommended approach is to put the DNSBL in its own second >> level domain, and then point the DNS NS records for that second >> level domain to 127.255.255.255. The TTL for that record should be >> set at the maximum allowed period of one week. > > Using a broadcast address may have unintended consequences. I suggest > using 192.0.2.2. Which would have lower risk? Somewhere in upper 127, or 192.0? > > Some DNSBL operators list the entire Internet because they keep > receiving queries years after the DNSBL has ceased operation. It may be > better to include a note for people implementing DNSBL features in their > software to prevent such behavior. They could use a test point to > determine whether the DNSBL is still active. This is the best way to > avoid excessive DNS queries. Part of the issue about this is John's DNSBL protocol BCP. We perhaps shouldn't get too far into detail of this, unless we subsume John's. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iQCVAwUBRduchp3FmCyJjHfhAQJ3uAQAuFz0JHNFxpIOCu7gPx+KbkVxRlpMMwE1 PmYHHosCe0Ms3+k41kXRJJ1dzHlG2GrO6oK9NF55Ow1QRVb6qor8kIz3eNlCB5Cy jQnQgaKjJ2btpS6hgU9q0efZpgzYPBefqXsPJRJuzod9YI9NKv8dJ09/Ahcem2tX 3EzE6yVDSnA= =PVIH -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Feb 20 20:32:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJgK8-0006Vd-Un; Tue, 20 Feb 2007 20:31:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJgK7-0006VR-7F for asrg@ietf.org; Tue, 20 Feb 2007 20:31:11 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJgK4-00086z-SQ for asrg@ietf.org; Tue, 20 Feb 2007 20:31:11 -0500 Received: from [10.2.164.130] (SJC-Office-NAT-217.Mail-Abuse.ORG [168.61.10.217]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id l1L1V7T4017405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 20 Feb 2007 17:31:08 -0800 In-Reply-To: <45DB9C86.6070809@nortel.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <6.2.5.6.2.20070220151704.0259a9a0@resistor.net> <45DB9C86.6070809@nortel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Asrg] DNSBL BCP v.2.0 Date: Tue, 20 Feb 2007 17:31:11 -0800 To: Chris Lewis X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: asrg@ietf.org X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On Feb 20, 2007, at 5:12 PM, Chris Lewis wrote: >> >> Using a broadcast address may have unintended consequences. I >> suggest >> using 192.0.2.2. > > Which would have lower risk? Somewhere in upper 127, or 192.0? The values used in the example given in nanog: http://www.merit.edu/mail.archives/nanog/msg04555.html Used the address space defined in rfc3330 192.0.2.0/24 Test-Net While it would be nice to establish a test method, the test should be both the return of an RR and that of an NXDOMAIN just incase the network provider decides to intercept NXDOMAINs. Depending upon test vectors being installed in the various MTAs at this point is likely too late. The example using several NS records should generate enough pain to induce removal of the defunct DNSBL. -Doug _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Tue Feb 20 22:48:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJiQb-0005dE-AW; Tue, 20 Feb 2007 22:46:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJiQZ-0005d9-3P for asrg@ietf.org; Tue, 20 Feb 2007 22:45:59 -0500 Received: from nz-out-0506.google.com ([64.233.162.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJiQU-0000qE-T9 for asrg@ietf.org; Tue, 20 Feb 2007 22:45:59 -0500 Received: by nz-out-0506.google.com with SMTP id z6so2228736nzd for ; Tue, 20 Feb 2007 19:45:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YeIrt7nFYtEyRWXb9+5AdSVztWEc5Tv0UkamU8FldtBfpd/9dcilMSsLKMO2IobBgvsMzELIujK2/33VhPV+Hr5wZFd7kSGlJPoIQhg92LRVFnUkDGnocF+NvsirZeNhFUH6cSslX7P7nkm3Ura3YK3C/1GIcK73rJPR2iNOpqw= Received: by 10.65.211.16 with SMTP id n16mr13081461qbq.1172029554120; Tue, 20 Feb 2007 19:45:54 -0800 (PST) Received: by 10.65.150.15 with HTTP; Tue, 20 Feb 2007 19:45:54 -0800 (PST) Message-ID: <54709c090702201945y7393db8bva7deda75f118d16f@mail.gmail.com> Date: Tue, 20 Feb 2007 21:45:54 -0600 From: "Al Iverson" To: asrg@ietf.org Subject: Re: [Asrg] DNSBL BCP v.2.0 In-Reply-To: <45DB9C86.6070809@nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <6.2.5.6.2.20070220151704.0259a9a0@resistor.net> <45DB9C86.6070809@nortel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org On 2/20/07, Chris Lewis wrote: > >> 7. What are the demographics and quantity of the list's user base? > > > > Such information is rarely published. Point 8 is a better guideline. > > I think the intent here is not that the DNSBL publishes it (they often > don't know), but the user should consider this - eg: do other site like > me use it? In your opinion, how is that easily determinable? Al -- Al Iverson on Spam and Deliverabilty, see http://www.spamresource.com Message copyright 2007 by Al Iverson. For posts to SPAM-L, permission is granted only to this lists's owners to redistribute to their sub- scribers and to archive this message on site(s) under their control. _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 21 13:55:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwaS-0004Af-8J; Wed, 21 Feb 2007 13:53:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwaQ-0004Aa-U3 for asrg@ietf.org; Wed, 21 Feb 2007 13:53:06 -0500 Received: from ns1.qubic.net ([208.185.248.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJwaP-0002t8-JF for asrg@ietf.org; Wed, 21 Feb 2007 13:53:06 -0500 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.0/8.14.0) with ESMTP id l1LIqbwb021074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Feb 2007 10:52:50 -0800 (PST) DKIM-Signature: a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1172083977; bh=Q4bGSSJtlgUSIri68WUDPsCZoPLkU5Ig7OB3O2pnp6g=; h=DomainKey-Signature: Message-Id:X-Mailer:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type; b=Ad9ZHlhCNrMICuAXofeirUNG/zu0Oo2aaWI1wK ImccIKrK8VKG/MAyqASzTF8E5Nnqx2ZICYgDsh6DDuqDzEl3D9xqk3cIc1b81RXVH9B hLxOsAANy6tOK6hzPsWOu7uXmV8q0CGd3i4xldpE27HGp7TabvGyh/bU/Cfva6x2oo= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=xkUJQVw1lBaWB+GR57q9KXBRE+QxTO+MDKJDsU01tnfGh+jMKrRQb21cmLFF11eDz 5AhoSrCDmu2FVhQOAUQBOVR9kgdSnxZEJfAph7cYnG4YMq8wu+esObcORUTJ9shUbQ/ 6UVDI3Yfb6ozDVSAv1ggvaqljLot6Z2wbm96TWM= Message-Id: <6.2.5.6.2.20070221095802.02d4e978@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 21 Feb 2007 10:51:56 -0800 To: asrg@ietf.org From: SM Subject: Re: [Asrg] DNSBL BCP v.2.0 In-Reply-To: <45DB9C86.6070809@nortel.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <6.2.5.6.2.20070220151704.0259a9a0@resistor.net> <45DB9C86.6070809@nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org At 17:12 20-02-2007, Chris Lewis wrote: >I think the intent here is not that the DNSBL publishes it (they often >don't know), but the user should consider this - eg: do other site like >me use it? Generally DNSBL operators don't publish such information. The information is also not published in comparative evaluations. Your question "Do other sites like me use it?" is more to the point. The Guidance for DNSBL users questions are straight-forward except for question 7. >Which would have lower risk? Somewhere in upper 127, or 192.0? The 192.0.2.0/24 block is assigned as "TEST-NET". It should not appear on the public Internet (RFC 3330). Pointing the DNS NS record to 192.0.2.2 will cause a query timeout. The DNSBL user may notice the slow down in mail delivery and take appropriate action. The purpose is not to cause any harm. In my opinion, 192.0.2 should have a lower risk than the upper 127 as it is not associated with the loopback address. I suggested 192.0.2.2/32 as it makes troubleshooting easier. Thank you for the clarifications. Regards, -sm _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 21 16:33:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJz44-0002fy-FX; Wed, 21 Feb 2007 16:31:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJz42-0002fo-K1 for asrg@ietf.org; Wed, 21 Feb 2007 16:31:50 -0500 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJz41-0007rK-C3 for asrg@ietf.org; Wed, 21 Feb 2007 16:31:50 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id l1LLVkm23567 for ; Wed, 21 Feb 2007 16:31:47 -0500 (EST) Received: from [47.9.16.204] ([47.9.16.204] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Feb 2007 16:31:45 -0500 Message-ID: <45DCBA3C.4050009@nortel.com> Date: Wed, 21 Feb 2007 16:31:40 -0500 From: "Chris Lewis" User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 CC: asrg@ietf.org Subject: Re: [Asrg] DNSBL BCP v.2.0 References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <6.2.5.6.2.20070220151704.0259a9a0@resistor.net> <45DB9C86.6070809@nortel.com> <6.2.5.6.2.20070221095802.02d4e978@resistor.net> In-Reply-To: <6.2.5.6.2.20070221095802.02d4e978@resistor.net> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Feb 2007 21:31:45.0836 (UTC) FILETIME=[AFD546C0:01C755FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list 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 SM wrote: > At 17:12 20-02-2007, Chris Lewis wrote: >> I think the intent here is not that the DNSBL publishes it (they often >> don't know), but the user should consider this - eg: do other site like >> me use it? > > Generally DNSBL operators don't publish such information. In addition to not really knowing, most DNSBLs will be reluctant to publish the info even if they knew it. While (the better) DNSBLs would probably like to, parading the security measures of other sites is, er, "poor form". > The > information is also not published in comparative evaluations. I've seen it, but not published. > Your > question "Do other sites like me use it?" is more to the point. The > Guidance for DNSBL users questions are straight-forward except for > question 7. Nick - I think i like this suggestion... For Al: how would the prospective user know? Google works ;-) >> Which would have lower risk? Somewhere in upper 127, or 192.0? > > The 192.0.2.0/24 block is assigned as "TEST-NET". It should not appear > on the public Internet (RFC 3330). But it may occur locally. Wouldn't want your DNSBL queries to go off to a test DNS server. Tho, perhaps it's unlikely to result in a listing... > Pointing the DNS NS record to > 192.0.2.2 will cause a query timeout. Most 127s would as well, would they not? > The DNSBL user may notice the > slow down in mail delivery and take appropriate action. The purpose is > not to cause any harm. In my opinion, 192.0.2 should have a lower risk > than the upper 127 as it is not associated with the loopback address. I > suggested 192.0.2.2/32 as it makes troubleshooting easier. Thanks for the discussion. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) iQCVAwUBRdy6PJ3FmCyJjHfhAQJlxgQAxL6Fg+JX+8o5pXymemTVl4IzxiD3tVPa ZgvlekEfJlnue/aw0qHy8pBHmC4OcteJn0WyCN7qoofpKRqMQaxuUkh2WpJkaa+L 66A5W6b9ZytKgdx0qeoNvW7M58KfWDl8J4waDlewYKvZLH6UBRKGRloFvmHWKYQQ MMRkQ6tu+l8= =fO5a -----END PGP SIGNATURE----- _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg From asrg-bounces@ietf.org Wed Feb 21 18:23:45 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK0mN-0007Xw-Ub; Wed, 21 Feb 2007 18:21:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK0mM-0007Xq-Vt for asrg@ietf.org; Wed, 21 Feb 2007 18:21:42 -0500 Received: from ns1.qubic.net ([208.185.248.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK0mL-0006Z9-LI for asrg@ietf.org; Wed, 21 Feb 2007 18:21:42 -0500 Received: from subman.resistor.net ([10.0.0.1]) (authenticated bits=0) by ns1.qubic.net (8.14.0/8.14.0) with ESMTP id l1LNLIDa015958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 21 Feb 2007 15:21:29 -0800 (PST) DKIM-Signature: a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1172100091; bh=G7FRV5LoXHXRQ6Y1yb7pYW98yCZGzHIJ+fDXulU/Pl8=; h=DomainKey-Signature: Message-Id:X-Mailer:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type; b=qPrzwtUocWQoOKEtMmvmesC84dtvQlmCr+uR9p 13fQyEwcAKi7iC3VrGVs+6WA7Fd0ovAK4j41J8uDtlVj0Utyw8o24ePg6C3JQLLmqwR PY3Qj2gVwxeOuTs3LBttoPl7rssnjDhrymSA7iK7Au76RNvvyqlLh8y+npViILGJCo= DomainKey-Signature: a=rsa-sha1; s=mail; d=resistor.net; c=simple; q=dns; b=4w43Q2GkyjT0vy5qaK1JyX4eOsCOkdgxYrnxFCv9yIYOzcIBFgdiBXciN4KNhAW7i mo04MO/fd1mHGr6NeGvCcIqRfloiMxHBNux1vz+yTdf8RIxHh6mvbo3yyDL1XvOYKie bh8koS6Zdtwf7unSX94sIcx8Bgvf2D5qrzVjkEY= Message-Id: <6.2.5.6.2.20070221142328.02ca07f0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 21 Feb 2007 14:54:12 -0800 To: asrg@ietf.org From: SM Subject: Re: [Asrg] DNSBL BCP v.2.0 In-Reply-To: <45DCBA3C.4050009@nortel.com> References: <88885AD16AAA9F4899BB9FB751D4F5A5024C31B3@phost016.habeas.intermedia.net> <6.2.5.6.2.20070220151704.0259a9a0@resistor.net> <45DB9C86.6070809@nortel.com> <6.2.5.6.2.20070221095802.02d4e978@resistor.net> <45DCBA3C.4050009@nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: asrg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: asrg-bounces@ietf.org At 13:31 21-02-2007, Chris Lewis wrote: > > The > > information is also not published in comparative evaluations. > >I've seen it, but not published. What's important is not what we see but what the DNSBL user can see so that they can make an informed decision. >But it may occur locally. Wouldn't want your DNSBL queries to go off to >a test DNS server. Tho, perhaps it's unlikely to result in a listing... Yes, it may occur locally. But it's not like the DNSBL operator is pointing the NS to the user's loopback (127/8). >Most 127s would as well, would they not? Yes it would. Regards, -sm _______________________________________________ Asrg mailing list Asrg@ietf.org https://www1.ietf.org/mailman/listinfo/asrg