From johnl@iecc.com Tue Oct 2 21:26:36 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135E621F8666 for ; Tue, 2 Oct 2012 21:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.893 X-Spam-Level: X-Spam-Status: No, score=-109.893 tagged_above=-999 required=5 tests=[AWL=-1.294, BAYES_50=0.001, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7cSPJdh2TeI for ; Tue, 2 Oct 2012 21:26:35 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id BC89221F8620 for ; Tue, 2 Oct 2012 21:26:34 -0700 (PDT) Received: (qmail 94488 invoked from network); 3 Oct 2012 04:26:31 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 3 Oct 2012 04:26:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=506bbe77.xn--yuvv84g.k1208; i=johnl@user.iecc.com; bh=F6hfT3TywPMXt0g3LfOnlNoE8LA/LgyJI31THnYR8qQ=; b=UAyjPEydktGr88C9+qv99Z4aIqaXB7Ceo5wJWyqC6bQ0/52xXuUsk8CZ6ORlVOGWmhnYgOsdZhOtUq8B82y7u1wGvHN02V0xvq3tVz/J3Rhb4VHI3CJ2pgDB5L5FkyF4eQ2RtjdUou/q2BlF+aoVWNRQrVneMb7z2cc7GKYKbGs= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:content-transfer-encoding:vbr-info; s=506bbe77.xn--yuvv84g.k1208; olt=johnl@user.iecc.com; bh=F6hfT3TywPMXt0g3LfOnlNoE8LA/LgyJI31THnYR8qQ=; b=w01FxzL6vAfxkbir6yBy0fkkElqlA2SO/ZpgGMLInrohOymjqrpVNK2lEaBznrr4+4nGul9vCl4TTcUS7F22j1flqbFn6cz9j1Z+sr6c7A3LBO189u9VOteeaCcKlR0mTNKeQKkYvlTqVNvw6rArUghw+eq1SNg/IMhWNTmvzQI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 3 Oct 2012 04:26:09 -0000 Message-ID: <20121003042609.97192.qmail@joyce.lan> From: "John Levine" To: asrg@irtf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: [Asrg] DNSBL cache modelling X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 04:26:36 -0000 In response to the question I sent out a few weeks ago, I've gotten offers from several people to provide mail server traces of [IP, timestamp] that should be enough to at least start on some cache models. I am planning to hack stuff up myself, but it would be nice to have another person or two to work with, both to compare notes, and because my statistics are a bit rusty, what with my most recent course on the topic having been in about 1974. I'd like to make some estimates like, how long a run do you need to have an N% confidence level that you've found the average cache hit rate. The MAAWG meeting later this month has invited a bunch of academic researchers, and I'll be pitching this to them, too, but you all get first dibs. If you want to do some of the simulation programming, that would be nice, too. R's, John From swmike@swm.pp.se Thu Oct 18 23:22:33 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0438021F848F for ; Thu, 18 Oct 2012 23:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqDx9tCZHyFq for ; Thu, 18 Oct 2012 23:22:32 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 5A8CF21F848D for ; Thu, 18 Oct 2012 23:22:31 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8C5A79C; Fri, 19 Oct 2012 08:22:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 82FA69A for ; Fri, 19 Oct 2012 08:22:27 +0200 (CEST) Date: Fri, 19 Oct 2012 08:22:27 +0200 (CEST) From: Mikael Abrahamsson To: asrg@irtf.org Message-ID: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 06:22:33 -0000 Hello. I just subscribed to this list and tried to read up. I'm very interested in IPv6 and SPAM, and I'd like to add some to the two last threads here regarding DNSBL and IPv6. Fundamentally in IPv6, a "customer" (or entity or whatever) will in a lot of cases not a single IP address, but a network. Households will get /64s, or get a /56 via DHCPv6-PD. Phones get a /64 or a network via DHCPv6-PD. Companies get /48 (or something else, but a bunch of networks). This is fundamentally how IPv6 was intended to be used, and hopefully that's how most ISPs will deliver it to customers. So for spam detection to happen, detection of what is a "customer" needs to happen, and this needs to be on a network level, not single IPv6 address level. The RIR databases (at least RIPE) contain information about what kind of per-customer subnet size is for a certain large block of addresses. Equivalent in IPv4 is "this customer has an IPv4 /26" and spam blocking would be done on a per-customer level, not per unique IPv4 address. I'm a routing guy, not MUA/MTA guy, so I have little insight in what things look like in the real world outside of my personal setup with postfix, some DNSBL and procmail/spamassassin. What I feel needs to happen is that policy needs to put in place to RIRs (via ISPs) can present "what is a customer" on a network level, and then this information can be put into DNS somehow, and used for DNSBL. Example: An ISP serves 10000 households with connectivity, each household gets a /56, this is done via an IPv6 /42 (because this is in a single town and it's aggregated like that). So this /42 would be in some kind of "residential access" classification, so people could block on that, and if one wants to block unique spammers, then this needs to be identified on a /56 level. In other places I've pitched that the RIRs would publish this information in some kind of format outside of whois, so perhaps we need to start there, to create a standard (I don't know who should create the standard, but agreeing that a standard is needed is one step) for how this information is published, is a first step. Thoughts? -- Mikael Abrahamsson email: swmike@swm.pp.se From matthias@leisi.net Thu Oct 18 23:52:35 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6968921F86F5 for ; Thu, 18 Oct 2012 23:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.377 X-Spam-Level: X-Spam-Status: No, score=-2.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lqeTlb426Ddv for ; Thu, 18 Oct 2012 23:52:35 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id C0EC321F868B for ; Thu, 18 Oct 2012 23:52:34 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wc20so178341obb.13 for ; Thu, 18 Oct 2012 23:52:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=1tIeoW/77XoVnLgF2xVrg6CC7XkCK0j1WKmWDLc+vdQ=; b=MVdSG0KZpYajZYjIxscKRAANK0Zq11AR3taX1uA6cebUTMgniIKE3w3udYSXoTO4wN w8Mu75UgTIG7Zn5bVTzdLaVt9ZXE0sauurfPMKpfmT0mILhz6X47RYWX/4p0T2ONIdoF t7Do7pBU0OqlusPGvgV7RiFWpuWdPdKkFIjj2IpPwLtbCzFopVKLGsxqV4lyaLOuAon0 +MDqV7bGLm48ob8VDIbW0rHzjqdXVtMW6gfg6kpUXp+0oFiqlpTJ4tjHOCHL0tD4+AN+ inutC7SHLnQhXAGt4UmRu9gu/zY/1p/LiDLJzFTqVqwAi8hc8bJiiRamZyDWaalt0AXz nICQ== Received: by 10.60.19.37 with SMTP id b5mr508391oee.16.1350629554033; Thu, 18 Oct 2012 23:52:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.76.103 with HTTP; Thu, 18 Oct 2012 23:52:12 -0700 (PDT) In-Reply-To: References: From: Matthias Leisi Date: Fri, 19 Oct 2012 08:52:12 +0200 Message-ID: To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmjSMcTM/dsQEh54a6dcaua5D9Z39jnQUF4HjfG7YRSFNpPCDfJVk9XF+bLe3FnAwXHfwfg Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 06:52:35 -0000 On Fri, Oct 19, 2012 at 8:22 AM, Mikael Abrahamsson wrote: > Fundamentally in IPv6, a "customer" (or entity or whatever) will in a lot of > cases not a single IP address, but a network. At the beginning of an SMTP transaction, all you have is a single IP. > Households will get /64s, or get a /56 via DHCPv6-PD. Phones get a /64 or a > network via DHCPv6-PD. Companies get /48 (or something else, but a bunch of As a spam filter (software developer), you may want to know more about the reputation of the IP address connecting to you. > So for spam detection to happen, detection of what is a "customer" needs to > happen, and this needs to be on a network level, not single IPv6 address > level. The RIR databases (at least RIPE) contain information about what kind > of per-customer subnet size is for a certain large block of addresses. You need an algorithm where you start from a single IP address and then potentially "move up" until you get a meaningful result. That's more or less what the B-tree algorithm suggested by John Levine some months ago would offer: variable "depth" and "density" of data controlled by the DNSxL operator optimized for the (on average) lowest number of lookups needed. At the same time, having a standardised and light-weight protocol to determine the allocation policy by the ISP would be hugely helpful (this will likely then be mirrored by the DNSxL operator). Absent such data,third parties have to fall back to some default /64 etc. > What I feel needs to happen is that policy needs to put in place to RIRs > (via ISPs) can present "what is a customer" on a network level, and then > this information can be put into DNS somehow, and used for DNSBL. I don't know whether RIRs can mandate the publication of this data through policy. -- Matthias From swmike@swm.pp.se Fri Oct 19 00:25:18 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E63721F86D1 for ; Fri, 19 Oct 2012 00:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xaIggzo77FoP for ; Fri, 19 Oct 2012 00:25:18 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 00B4121F8641 for ; Fri, 19 Oct 2012 00:25:16 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E832B9C; Fri, 19 Oct 2012 09:25:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id E0E689A for ; Fri, 19 Oct 2012 09:25:12 +0200 (CEST) Date: Fri, 19 Oct 2012 09:25:12 +0200 (CEST) From: Mikael Abrahamsson To: Anti-Spam Research Group - IRTF In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 07:25:18 -0000 On Fri, 19 Oct 2012, Matthias Leisi wrote: > On Fri, Oct 19, 2012 at 8:22 AM, Mikael Abrahamsson wrote: > >> Fundamentally in IPv6, a "customer" (or entity or whatever) will in a lot of >> cases not a single IP address, but a network. > > At the beginning of an SMTP transaction, all you have is a single IP. Yes. >> Households will get /64s, or get a /56 via DHCPv6-PD. Phones get a /64 or a >> network via DHCPv6-PD. Companies get /48 (or something else, but a bunch of > > As a spam filter (software developer), you may want to know more about > the reputation of the IP address connecting to you. Yes, and that reputation is derived from what subnet it's a subset of. > You need an algorithm where you start from a single IP address and then > potentially "move up" until you get a meaningful result. That's more or > less what the B-tree algorithm suggested by John Levine some months ago > would offer: variable "depth" and "density" of data controlled by the > DNSxL operator optimized for the (on average) lowest number of lookups > needed. Sounds good to me. > At the same time, having a standardised and light-weight protocol to > determine the allocation policy by the ISP would be hugely helpful > (this will likely then be mirrored by the DNSxL operator). Absent such > data,third parties have to fall back to some default /64 etc. Yes, which will be less than effective when customers are handed /48s and can send from anything within that /48. >> What I feel needs to happen is that policy needs to put in place to >> RIRs (via ISPs) can present "what is a customer" on a network level, >> and then this information can be put into DNS somehow, and used for >> DNSBL. > > I don't know whether RIRs can mandate the publication of this data > through policy. RIPE already does (basically), as in "this /42 contains customers where each customer has a /56". I don't know about other RIRs. -- Mikael Abrahamsson email: swmike@swm.pp.se From johnl@iecc.com Fri Oct 19 15:41:57 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A64221F87CD for ; Fri, 19 Oct 2012 15:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.402 X-Spam-Level: X-Spam-Status: No, score=-110.402 tagged_above=-999 required=5 tests=[AWL=-0.803, BAYES_50=0.001, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WPDQx-wWzLe for ; Fri, 19 Oct 2012 15:41:57 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id AC21521F878B for ; Fri, 19 Oct 2012 15:41:56 -0700 (PDT) Received: (qmail 96612 invoked from network); 19 Oct 2012 22:41:54 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Oct 2012 22:41:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5081d731.xn--yuvv84g.k1208; i=johnl@user.iecc.com; bh=xouR3P5tgbNYob+ub3mlxXz0WF3l6pI7rU4AZB8yOmg=; b=EQQ2oar6O7Y1g+py12b0KoOZDHpRVVMjvFgB92qUb6oWpF8px+zMrXWfwTPLgIzsR0dEv0C9Pn3z0mPFXX6c6yL/ebZkpO4zqk63XQZWFrxDwU6s0swUmbgc3eFGytu467rMs/K/+mFBuRk1PMZyBXvvzmq/KyN+fVEFjf8yLXk= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5081d731.xn--yuvv84g.k1208; olt=johnl@user.iecc.com; bh=xouR3P5tgbNYob+ub3mlxXz0WF3l6pI7rU4AZB8yOmg=; b=iQg0UAYdq6MZ4Q7EnJPWAgeh7V1Aj6BkI1EL0YZy2vjenbcEVz+y1r/6OZozPAguh5HNBWq+dbp01vFnlF+1FcSq+I374O0Xs14lYCP8VUfB6jKuC9ZOYeMEtVUjEw5m++jFa4GvPjmEN6C5faNsVcfjPB7aG168A4CXpFngH9A= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 19 Oct 2012 22:41:31 -0000 Message-ID: <20121019224131.28382.qmail@joyce.lan> From: "John Levine" To: asrg@irtf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Oct 2012 22:41:57 -0000 >> What I feel needs to happen is that policy needs to put in place to RIRs >> (via ISPs) can present "what is a customer" on a network level, and then >> this information can be put into DNS somehow, and used for DNSBL. Yeah, I've been talking to people on and off about this for over a year. Even though providers can lie about their allocation granularity, most won't, and the ones that lie would probably merit total blocking anyway. A customer allocation can be anywhere from a /56 to a /64, and I expect we'll see hosting companies with a /64 per rack or per VM host, so you'll have different customers within the same /64. So, uh, anyone interested in doing simulations of how this sort of stuff would work with various DNSBL designs? I have access to IPv4 mailstream connection data we can use to calibrate it. R's, John From prvs=16406941c5=lists@hireahit.com Fri Oct 19 17:25:29 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1A621F8853 for ; Fri, 19 Oct 2012 17:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0k0MEeDWuU-1 for ; Fri, 19 Oct 2012 17:25:28 -0700 (PDT) Received: from vinny.hireahit.com (vinny.hireahit.com [72.51.42.137]) by ietfa.amsl.com (Postfix) with ESMTP id 75CFD21F884D for ; Fri, 19 Oct 2012 17:25:28 -0700 (PDT) Received: from [172.24.0.107] by hireahit.com (vinny.hireahit.com) (SecurityGateway 2.0.7) with SMTP id SG002846525.MSG for ; Fri, 19 Oct 2012 17:25:22 -0700 Message-ID: <5081EF6F.9030808@hireahit.com> Date: Fri, 19 Oct 2012 17:25:19 -0700 From: Dave Warren User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: asrg@irtf.org References: <20121019224131.28382.qmail@joyce.lan> In-Reply-To: <20121019224131.28382.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SGOP-RefID: fgs=0 (_st=1 _vt=0 _iwf=0) Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 00:25:29 -0000 On 10/19/2012 15:41, John Levine wrote: >>> What I feel needs to happen is that policy needs to put in place to RIRs >>> (via ISPs) can present "what is a customer" on a network level, and then >>> this information can be put into DNS somehow, and used for DNSBL. > Yeah, I've been talking to people on and off about this for over a > year. Even though providers can lie about their allocation > granularity, most won't, and the ones that lie would probably merit > total blocking anyway. I'm less worried about those that lie outright than those that just don't care either by not bothering to specify a policy at all (unless it becomes mandatory somehow), or have more granularity than can be clearly specified in a single policy. For example, their policy might be to allocate at the /64 level, but unless they also prohibit customers from obtaining more than one /64... -- Dave Warren http://www.hireahit.com/ http://ca.linkedin.com/in/davejwarren From steve@blighty.com Fri Oct 19 17:38:19 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99F1B21F8BB4 for ; Fri, 19 Oct 2012 17:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCkv8u66jd3e for ; Fri, 19 Oct 2012 17:38:18 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id C297E21F8BB3 for ; Fri, 19 Oct 2012 17:38:18 -0700 (PDT) Received: from [192.168.80.56] (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id 0560F2EADE for ; Fri, 19 Oct 2012 17:38:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wordtothewise.com; s=1.wttw; t=1350693498; bh=f85MGHDjrl5iBqbnl70K+HHdEAc4YUZ8l5bUrh1Mj6s=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=lFQoh3D+IA+XNMge72N7pVcLlxfJIgqt33FmWXYBqfoe9zE9TX5kYwPZZ4mDO7Njh m9aWoOCQ4gNWzscyZvftUm2pnVUmvr3bbmg8NXek8diPYy1uKyO0sDMRga8ivb7Hw4 KmX/Ir3/4qz4YE3KfxWEazPs8yiS3QYxS/aB6wuk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Steve Atkins In-Reply-To: <5081EF6F.9030808@hireahit.com> Date: Fri, 19 Oct 2012 17:38:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <5C0A004C-1BAD-4103-85C2-B94B718F0367@blighty.com> References: <20121019224131.28382.qmail@joyce.lan> <5081EF6F.9030808@hireahit.com> To: Anti-Spam Research Group - IRTF X-Mailer: Apple Mail (2.1499) Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 00:38:19 -0000 On Oct 19, 2012, at 5:25 PM, Dave Warren wrote: > On 10/19/2012 15:41, John Levine wrote: >>>> What I feel needs to happen is that policy needs to put in place to = RIRs >>>> (via ISPs) can present "what is a customer" on a network level, and = then >>>> this information can be put into DNS somehow, and used for DNSBL. >> Yeah, I've been talking to people on and off about this for over a >> year. Even though providers can lie about their allocation >> granularity, most won't, and the ones that lie would probably merit >> total blocking anyway. >=20 > I'm less worried about those that lie outright than those that just = don't care either by not bothering to specify a policy at all (unless it = becomes mandatory somehow), or have more granularity than can be clearly = specified in a single policy. >=20 > For example, their policy might be to allocate at the /64 level, but = unless they also prohibit customers from obtaining more than one /64... The ability for customers to obtain more than one IPv4 /32 hasn't been = too complex an issue for blacklist operators to deal with. Any blacklist = operator who's successfully running an IPv4 blacklist can surely come up = with reasonable (or unreasonable, I won't judge=85) policies for IPv6. The only relevant difference between v4 and v6 DNS based blacklisting is = that the ability to easily hop around *within* your /64 makes it = possible (easy) to blow the cache of a traditional caching DNS resolver = if you do naive "look up a record based on the IPv6 address". That doesn't affect the viability of source address based blacklisting. = It doesn't affect the viability of distributing that data as DNS zone = files (they suck for both v4 and v6, but they're usable). And it doesn't = affect the viability of using DNS as the communication channel between = an MX and a local authoritative blacklist server. But it does mean that anyone wanting a recursive resolver in their = distribution path might have to refine the process a little - which is = what I assume John is looking at.=20 (I'm betting that "mask the bottom 64 bits before querying" would work = just fine, but I don't think we have enough v6 space in use yet to say = for sure.) Cheers, Steve From swmike@swm.pp.se Fri Oct 19 21:41:36 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D13921F8722 for ; Fri, 19 Oct 2012 21:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TC-7biVK5ed9 for ; Fri, 19 Oct 2012 21:41:36 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id E64FE21F865F for ; Fri, 19 Oct 2012 21:41:35 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id E03099C; Sat, 20 Oct 2012 06:41:33 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D73319A for ; Sat, 20 Oct 2012 06:41:33 +0200 (CEST) Date: Sat, 20 Oct 2012 06:41:33 +0200 (CEST) From: Mikael Abrahamsson To: Anti-Spam Research Group - IRTF In-Reply-To: <5C0A004C-1BAD-4103-85C2-B94B718F0367@blighty.com> Message-ID: References: <20121019224131.28382.qmail@joyce.lan> <5081EF6F.9030808@hireahit.com> <5C0A004C-1BAD-4103-85C2-B94B718F0367@blighty.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 04:41:36 -0000 On Fri, 19 Oct 2012, Steve Atkins wrote: > (I'm betting that "mask the bottom 64 bits before querying" would work > just fine, but I don't think we have enough v6 space in use yet to say > for sure.) I agree. Although I believe some ISPs will put multiple customers in a single /64, this is mostly going to be dynamic customers anyway (multiple laptops on a wifi for instance), and those I would imagine are treated with the same policy so it doesn't really matter. Per /64 handling is a reasonable tradeoff between granularity and practicality in my mind. -- Mikael Abrahamsson email: swmike@swm.pp.se From matthias@leisi.net Fri Oct 19 23:55:59 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F0E21F8722 for ; Fri, 19 Oct 2012 23:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IW4gIBFc7URk for ; Fri, 19 Oct 2012 23:55:59 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id 0A84E21F861D for ; Fri, 19 Oct 2012 23:55:58 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wc20so1461634obb.13 for ; Fri, 19 Oct 2012 23:55:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=OkGBrIkcsuF95nJrNXHgtQeBE5MlA1bph3zb9boU9Rc=; b=GPMu4yKfoXOW1pc6qZ7VHCZ+cOMEl0W9pv6gJnNgcPrv6rAjtxEMzkHn2xd0MlWtjw XZ9QQYQMsTbc2qldVoh7mR/P2kXSjUtul2JHOJnmwV04Sj1SxFVpX9u0xuQulT9TY7s7 2cKPiQsvZ0k87MEbt4osemCu9OhWOM5rMil5VbApu7VgMtNA7KyN4KBdV8RS5IQQEyr8 ZRKZDSyElK1lS5N2BuvE/a5qb3+gfjco4EkM1jkHceED0FVzvER8KHOxtGI0TKUbVvIe DXtmeGGeldSyXUpY2ahaxJF8i5/mLhltK8jBoVYG6uAb2LKdYFBTSH7QzA++tYzJyrQ7 7ZUQ== Received: by 10.60.27.71 with SMTP id r7mr3397907oeg.96.1350716158006; Fri, 19 Oct 2012 23:55:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.3.173 with HTTP; Fri, 19 Oct 2012 23:55:37 -0700 (PDT) In-Reply-To: References: <20121019224131.28382.qmail@joyce.lan> <5081EF6F.9030808@hireahit.com> <5C0A004C-1BAD-4103-85C2-B94B718F0367@blighty.com> From: Matthias Leisi Date: Sat, 20 Oct 2012 08:55:37 +0200 Message-ID: To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkyELUGwKOlwoXwoGFdM2cN/rjd9jxgZVbSufgzIpKA03EdcN2PpcwyInRVdRVtlvo681Kd Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 06:55:59 -0000 On Sat, Oct 20, 2012 at 6:41 AM, Mikael Abrahamsson wrote: > I agree. Although I believe some ISPs will put multiple customers in a > single /64, this is mostly going to be dynamic customers anyway (multiple > laptops on a wifi for instance), and those I would imagine are treated with > the same policy so it doesn't really matter. Per /64 handling is a > reasonable tradeoff between granularity and practicality in my mind. And cheap VPS, where the "upgrade" from /128 to /64 is used as a differentiator (just stumbled upon such a case, http://www.kimsufi.com/fr/vks/). -- Matthias From hjp-asrg@hjp.at Sat Oct 20 00:30:36 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C434E21F860F for ; Sat, 20 Oct 2012 00:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.43 X-Spam-Level: X-Spam-Status: No, score=-1.43 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-D5pG8dHQNz for ; Sat, 20 Oct 2012 00:30:35 -0700 (PDT) Received: from zeno.hjp.at (ns1.hjp.at [212.17.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5517921F85F5 for ; Sat, 20 Oct 2012 00:30:34 -0700 (PDT) Received: by zeno.hjp.at (Postfix, from userid 1000) id ECEBC400F; Sat, 20 Oct 2012 09:30:31 +0200 (CEST) Date: Sat, 20 Oct 2012 09:30:31 +0200 From: "Peter J. Holzer" To: asrg@irtf.org Message-ID: <20121020073031.GA3248@hjp.at> References: <20121019224131.28382.qmail@joyce.lan> <5081EF6F.9030808@hireahit.com> <5C0A004C-1BAD-4103-85C2-B94B718F0367@blighty.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: <5C0A004C-1BAD-4103-85C2-B94B718F0367@blighty.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 07:30:36 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-10-19 17:38:16 -0700, Steve Atkins wrote: > On Oct 19, 2012, at 5:25 PM, Dave Warren wrote: > > I'm less worried about those that lie outright than those that just > > don't care either by not bothering to specify a policy at all > > (unless it becomes mandatory somehow), or have more granularity than > > can be clearly specified in a single policy. > >=20 > > For example, their policy might be to allocate at the /64 level, but > > unless they also prohibit customers from obtaining more than one > > /64... >=20 > The ability for customers to obtain more than one IPv4 /32 hasn't been > too complex an issue for blacklist operators to deal with. Any > blacklist operator who's successfully running an IPv4 blacklist can > surely come up with reasonable (or unreasonable, I won't judge=E2=80=A6) > policies for IPv6. >=20 > The only relevant difference between v4 and v6 DNS based blacklisting > is that the ability to easily hop around *within* your /64 makes it > possible (easy) to blow the cache of a traditional caching DNS > resolver if you do naive "look up a record based on the IPv6 address". A simple (maybe naive) idea to reduce cache poisoning would be to do some kind of greylisting before doing the lookup: If you haven't seen the address before, simply return a temporary error. If you have seen it (within some time window), do the lookup.=20 Is there a reason why a legitimate MTA (talking to MXs, not submission servers) would want to hop around in its net? * IPv6 privacy extensions might be turned on by default and the admin might not bother to turn them off, but I think they are too slow to prevent delivery (although it will slow down most mails) * An admin of an MTA serving many customers might want to use a different IP address for each customer. But from the outside that=20 would just look like one MTA per customer, not a single MTA hopping around > That doesn't affect the viability of source address based > blacklisting. It doesn't affect the viability of distributing that > data as DNS zone files (they suck for both v4 and v6, but they're > usable). There are many more IPv6 addresses and even /64 nets than IPv4 addresses. It's theoretically possible to ship around a zone file with /all/ IPv4 addresses (that would be less than 100GB). This isn't remotely= =20 possible for IPv6 space. It might be possible for allocated /64 nets depending on how they are allocated (if every cell phone gets a /48 ...). If you go down to the /128 level, a spammer doing the hopping maneuvre could blow up your zone file beyond any reasonable limit. > And it doesn't affect the viability of using DNS as the > communication channel between an MX and a local authoritative > blacklist server. [...] Right. hp --=20 _ | Peter J. Holzer | Der eigene Verstand bleibt gef=C3=BChlt messer- |_|_) | Sysadmin WSR | scharf. Aber die restliche Welt blickt's | | | hjp@hjp.at | immer weniger. __/ | http://www.hjp.at/ | -- Matthias Kohrs in desd --mYCpIKhGyMATD0i+ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIVAwUBUIJTFvIOSFES/ihdAQK4lBAArGFB3DtlS+o056RfOQpGojIa5CcBtSFW /TNcdHRzfjI4xztREro2osch7IlP1KqPhtUuemwqDCZTkwbEgMJ0RWsi+vCWxQ6T 6l4msYwYLKaJ/6UUr/OeZY0ZWEJ2W5T2EX0bxtyl2dscAWp4b8daQreKuDceiv3A pD92X9sE0sXaanErX1XYQ1kkhU2AN944tJ3jhjJgFW7oNdv8iExr9J1IfzYYBk3f C+CLasXQ5vLiknhn8z8Znli+reX2B2pRmbf8UYoCwEJhOXQW4Qg8ys0qjnR435FO WZq/bcCWJ+uyhP7UQWicV1cZvc7Og2UiYRfsAGR63cWR3bjWLJkLpoVcTtAuQNWj gKIr86Kbex1w7NaqzbG1os3l+SEyFyqf8TlOL7+1NdySf66hHnNVwEAdc8BlSxkv Tc8K2o9LIieFAu6hLsHZBBXn1QGSiICUt+VQ4gyHRPTYSicll7rU+UYUCTcFQA36 plg7wnpkZ3MHCfH/07VePqKhArLyirGDfU27MHZW8t/hLCLcsGdkpTTpMO7ZmgHy d61y+md4uzQ9l18RHVYgjHdL5QpqNRStm1RtBUVJYXJLWqiCDTSZgcEdjLYwjQ5o ykuW5jb7LiC4zcpKASSI/DIyu3tIbk24tyGt3jkplICBIGJR0fVQy7hbKHob+kWT gSRw7PC1JWE= =boDC -----END PGP SIGNATURE----- --mYCpIKhGyMATD0i+-- From schaefer@closedmail.com Sat Oct 20 07:25:41 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA3E221F8470 for ; Sat, 20 Oct 2012 07:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hKMqoDDoodpi for ; Sat, 20 Oct 2012 07:25:41 -0700 (PDT) Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by ietfa.amsl.com (Postfix) with ESMTP id 379CA21F846B for ; Sat, 20 Oct 2012 07:25:41 -0700 (PDT) Received: from torch.brasslantern.com ([unknown] [98.234.255.59]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0MC700MGJ41T1U90@vms173003.mailsrvcs.net> for asrg@irtf.org; Sat, 20 Oct 2012 09:25:06 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id q9KEP45T005007 for ; Sat, 20 Oct 2012 07:25:05 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id q9KEP4tX005006 for asrg@irtf.org; Sat, 20 Oct 2012 07:25:04 -0700 From: Bart Schaefer Message-id: <121020072504.ZM5005@torch.brasslantern.com> Date: Sat, 20 Oct 2012 07:25:04 -0700 In-reply-to: <20121020073031.GA3248@hjp.at> Comments: In reply to "Peter J. Holzer" "Re: [Asrg] DNSBL and IPv6" (Oct 20, 9:30am) References: <20121019224131.28382.qmail@joyce.lan> <5081EF6F.9030808@hireahit.com> <5C0A004C-1BAD-4103-85C2-B94B718F0367@blighty.com> <20121020073031.GA3248@hjp.at> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Anti-Spam Research Group - IRTF MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 14:25:41 -0000 On Oct 20, 9:30am, Peter J. Holzer wrote: } } Is there a reason why a legitimate MTA (talking to MXs, not submission } servers) would want to hop around in its net? A legitimate MTA could still be running in a dynamically-assigned space. In this case it might hop all over the space but probably wouldn't hop very frequently. A single MTA host might have multiple NICs each with its own IP, and not always choose the same interface for the same MX on retry. Here it might hop quite a lot, but among a limited number of choices. From johnl@iecc.com Sat Oct 20 14:41:13 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB3521F8471 for ; Sat, 20 Oct 2012 14:41:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.714 X-Spam-Level: X-Spam-Status: No, score=-111.714 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Hy5V5NEdfA6 for ; Sat, 20 Oct 2012 14:41:12 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 70E9621F846F for ; Sat, 20 Oct 2012 14:41:12 -0700 (PDT) Received: (qmail 49447 invoked from network); 20 Oct 2012 21:41:10 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Oct 2012 21:41:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50831a76.xn--yuvv84g.k1208; i=johnl@user.iecc.com; bh=zPjfwscbmrmAA2N9SqbccHllpRHLI39eLTviOMG/uKg=; b=jM1J8yyxamvVljeD0nl0tL1ypD5pE1yPnSYTLsH0W3nTH+EKPk0W3XnK1PjCCntdXpGmJAyvZav20nYJIsdECcp1Tvgmqk4len6s4RFeEMpwUCj1ommMyrcYOWYgml2YSWQG1XM7kFaaVCjbXHPCkm/iK/G2ha/VPx7G9JMol14= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50831a76.xn--yuvv84g.k1208; olt=johnl@user.iecc.com; bh=zPjfwscbmrmAA2N9SqbccHllpRHLI39eLTviOMG/uKg=; b=IOsGpduCVrRdSi6b8ecy8Xk98vaF9YOypw8jSpM8YE+ZBuSUxr6GkULm2/B1EHFTIMVqt5qA6rqEbhvTrrBMVcwbaARpu+CqLm8dO1fchokMY+meA0ZKYdOAhDR6ebwxeQzfg3BpB68sWCWFB4OnLFLu9Pen0HqlLe58GBS2jqI= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 20 Oct 2012 21:40:48 -0000 Message-ID: <20121020214048.3105.qmail@joyce.lan> From: "John Levine" To: asrg@irtf.org In-Reply-To: <5C0A004C-1BAD-4103-85C2-B94B718F0367@blighty.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 21:41:13 -0000 >The only relevant difference between v4 and v6 DNS based blacklisting is >that the ability to easily hop around *within* your /64 makes it >possible (easy) to blow the cache of a traditional caching DNS resolver >if you do naive "look up a record based on the IPv6 address". That's always been our assumption, but there is at this point precious little evidence that MTAs that query DNSBL through caches (as opposed to those who have a local rsync mirror) have a cache hit rate much greater than zero. If in fact they don't, the same design, perhaps with a little TTL tuning to give clients a hint about which ones are worth caching, could work no worse than they do now for similar mail volumes. That's why I want to do the cache simulations, to figure out what's going on now. It shouldn't be terribly hard, and we have people offering data. Want to help? R's, John From johnl@iecc.com Sat Oct 20 14:43:26 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D34E121F873F for ; Sat, 20 Oct 2012 14:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.721 X-Spam-Level: X-Spam-Status: No, score=-111.721 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bt9Dpf6EPbZP for ; Sat, 20 Oct 2012 14:43:26 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 0878A21F846F for ; Sat, 20 Oct 2012 14:43:25 -0700 (PDT) Received: (qmail 49845 invoked from network); 20 Oct 2012 21:43:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Oct 2012 21:43:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50831af8.xn--i8sz2z.k1208; i=johnl@user.iecc.com; bh=IvWERYpOL051FpPVt43VsPdU+oSVqFn8TjeTQxt7xCg=; b=RyMI0qaXPS/rkcHwrWJXgq9MPQmEibNkgfkV7BCfRkac/jP8IcPzclR7IUKyZCkwmMGz6QBLdGBluKwQ3vdw3EhwfPnFT4qy/5ZJY2/S2SazT8DxRhdoBHLlJpiDqcgfyhMQPVCPZ7qPG+g4Q+UK6cbqVj6foVzsYTYr1hIrlc0= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50831af8.xn--i8sz2z.k1208; olt=johnl@user.iecc.com; bh=IvWERYpOL051FpPVt43VsPdU+oSVqFn8TjeTQxt7xCg=; b=d76H7B90ACEZR8E0dTs3h2Zrnn44SIo53KUqwxDFrEz3PI/DZ9njAle2Y/m4NeOIPucstwX2s2WIaMvhFpIsWo7WqPrbrbIYQCFJ3UiNNIjlNK0vFKEov8RgrmSlVpQspYEwMs6GJ4Bc1Nl4rVdlv5uWI06JoLY71KD4UThhSMc= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 20 Oct 2012 21:42:57 -0000 Message-ID: <20121020214257.3127.qmail@joyce.lan> From: "John Levine" To: asrg@irtf.org In-Reply-To: <121020072504.ZM5005@torch.brasslantern.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Oct 2012 21:43:27 -0000 >} Is there a reason why a legitimate MTA (talking to MXs, not submission >} servers) would want to hop around in its net? Probably not, although I'm waiting for ESPs to figure out that if they send every message from a different IP, it'll be much easier to process bounces and complaints since all they'll need is the IP to figure out what the list and address was. Bad guys could use it to listwash, of course, but it's not totally ridiculous. R's, John From hjp-asrg@hjp.at Sun Oct 21 14:20:44 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5928E21F8599 for ; Sun, 21 Oct 2012 14:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.223 X-Spam-Level: X-Spam-Status: No, score=-0.223 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xA31oJpHAk2H for ; Sun, 21 Oct 2012 14:20:43 -0700 (PDT) Received: from zeno.hjp.at (ns1.hjp.at [212.17.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 5767021F858C for ; Sun, 21 Oct 2012 14:20:42 -0700 (PDT) Received: by zeno.hjp.at (Postfix, from userid 1000) id A6634400E; Sun, 21 Oct 2012 23:20:40 +0200 (CEST) Date: Sun, 21 Oct 2012 23:20:40 +0200 From: "Peter J. Holzer" To: asrg@irtf.org Message-ID: <20121021212040.GE3248@hjp.at> References: <121020072504.ZM5005@torch.brasslantern.com> <20121020214257.3127.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T7mxYSe680VjQnyC" Content-Disposition: inline In-Reply-To: <20121020214257.3127.qmail@joyce.lan> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 21:20:44 -0000 --T7mxYSe680VjQnyC Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-10-20 21:42:57 -0000, John Levine wrote: > >} Is there a reason why a legitimate MTA (talking to MXs, not submission > >} servers) would want to hop around in its net? >=20 > Probably not, although I'm waiting for ESPs to figure out that if they > send every message from a different IP, I thought of that but I wouldn't be surprised to overflow the router's ARP table even with our moderately sized mailing-lists (a few thousand subscribers at most). That's why I only mentioned "one address per customer", not "one address per message" as a likely tactic. > it'll be much easier to process bounces and complaints since all > they'll need is the IP to figure out what the list and address was. Is it? For mailing-lists, I think VERP is simpler and more robust. The IP address is buried somewhere in the Received headers of the bounced message, so you have to parse those. For complaints to an ISP about a customer that might indeed be useful. Depends on what information is included in the complaint. If it contains the complete header of the message there is probably other identifying information. It it doesn't, chances are that the IP address isn't included, either. > Bad guys could use it to listwash, of course, but it's not totally > ridiculous. There are other ways to listwash. I'm more worried that the bad guys are using rapidly changing IP addresses to escape or overflow BLs. hp --=20 _ | Peter J. Holzer | Der eigene Verstand bleibt gef=FChlt messer- |_|_) | Sysadmin WSR | scharf. Aber die restliche Welt blickt's | | | hjp@hjp.at | immer weniger. __/ | http://www.hjp.at/ | -- Matthias Kohrs in desd --T7mxYSe680VjQnyC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIVAwUBUIRnJ/IOSFES/ihdAQIVOg/+Iy+JBx8FQaBAPsPJLQD4yWhwKTg5paov GwjWcZIGo/+lmRbny471H1NcBgkSRNaBEmv6yIUMUtgpE6MGhtgrj/4sZ1D+3BK9 h1Qmm8xAmoiX+s6+TCown0M6qbYf0parVJo4BmugNQiGcdeaBD8+C7mBYyZhFAwd 5km6Pq7waU2wk54OngQq+8xuB9gREyZ06JeLFWJ8KzTcCHLP5ea6sfLiizOuRLFj 7CpWAxIvAz+IHhEbdHjc654Y4vU79TiBWHHlGN7pJfCiJQV64L9kA2EYl5YJi8Z8 VEpTQY/NTygfEiZH91XezfXs99DZices1sDg6R5pnLxBeBJ2wrlnJCMcPcVB7yrk xeNcDMS4icBg+pKBVhDYb1GU8zw/NBnUW7aLrmRO6BF1Fa/qgDOFCDi2TagnhFQk 3/DXSb+/zE/w9X8Hs5MF0mntj9UejiyLW21sUjDR0LBVG1R15463Epb8RZZ0CK1G UkmG7hiFvcfrc+c6gBgCK7e57C/YPs4QYeL9Iw/ou5ADpG5RK+s34UDlmRlyhitE 2R4CgQWt0uY1JuGGuBjkkrnexapnYqre/EX9fC2Sys07sYL6a+KXS+gUE9HZftiY n7wn3nBL7ocoWbEe7hgOZSnEDvTdrTq4ZeQotvrDE/kHoCuRdIfeEWrq98d/Wh8g VZ39DUd36uA= =EwOt -----END PGP SIGNATURE----- --T7mxYSe680VjQnyC-- From hjp-asrg@hjp.at Sun Oct 21 14:37:10 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEBC21F887A for ; Sun, 21 Oct 2012 14:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.082 X-Spam-Level: X-Spam-Status: No, score=-0.082 tagged_above=-999 required=5 tests=[AWL=-0.141, BAYES_05=-1.11, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vgxV5kR7XEh for ; Sun, 21 Oct 2012 14:37:09 -0700 (PDT) Received: from zeno.hjp.at (ns1.hjp.at [212.17.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id B5C7221F8878 for ; Sun, 21 Oct 2012 14:37:09 -0700 (PDT) Received: by zeno.hjp.at (Postfix, from userid 1000) id 4D416400E; Sun, 21 Oct 2012 23:37:08 +0200 (CEST) Date: Sun, 21 Oct 2012 23:37:08 +0200 From: "Peter J. Holzer" To: asrg@irtf.org Message-ID: <20121021213708.GF3248@hjp.at> References: <20121019224131.28382.qmail@joyce.lan> <5081EF6F.9030808@hireahit.com> <5C0A004C-1BAD-4103-85C2-B94B718F0367@blighty.com> <20121020073031.GA3248@hjp.at> <121020072504.ZM5005@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CGDBiGfvSTbxKZlW" Content-Disposition: inline In-Reply-To: <121020072504.ZM5005@torch.brasslantern.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 21:37:10 -0000 --CGDBiGfvSTbxKZlW Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2012-10-20 07:25:04 -0700, Bart Schaefer wrote: > On Oct 20, 9:30am, Peter J. Holzer wrote: > } > } Is there a reason why a legitimate MTA (talking to MXs, not submission > } servers) would want to hop around in its net? >=20 > A legitimate MTA could still be running in a dynamically-assigned space. > In this case it might hop all over the space but probably wouldn't hop > very frequently. By "dynamically-assigned space" do you mean a dynamically assigned address within a /64 (either by DHCP or by privacy extensions)? If so, I already mentioned that and yes, I think it doesn't change fast enough to make greylisting infeasible (but frequently enough to make it annoying). If you mean that an ISP is assigning a different /64 to the same customer periodically (some privacy evangelists are demanding that this should be the default), then this would probably be done even less frequently, and this would most likely be treated the same as dynamically assigned space today (i.e. very likely to be a zombie, not a legitimate MTA). > A single MTA host might have multiple NICs each with its own IP, and not > always choose the same interface for the same MX on retry. Here it might > hop quite a lot, but among a limited number of choices. An IP stack might also choose IP addresses at random or in a round robin fashion if the interface has several. That could be a problem. hp --=20 _ | Peter J. Holzer | Der eigene Verstand bleibt gef=FChlt messer- |_|_) | Sysadmin WSR | scharf. Aber die restliche Welt blickt's | | | hjp@hjp.at | immer weniger. __/ | http://www.hjp.at/ | -- Matthias Kohrs in desd --CGDBiGfvSTbxKZlW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQIVAwUBUIRrAvIOSFES/ihdAQKwjBAAjdDwYJDK7Idz9QYT0FtqkCR9i7zWQu08 D2D86AkTWFZGg/s55y5GYxBcW5I82c2SbuLtpEffQgy7/zBd3KNp9PmuoU51vyVa AUQi0fE7Xo+KEbYPtwG8Oad7vv3TACgTO0z6WHtUlTl/G6U+ITtbzHmOyDfLUdgc EhDhocDCKj8Nl+A0zfdOy77qyonV0WrERIulGaNB30j9zNFLoRfbi1lzK9KemH3I V+IRyEQ1/TdWvsk7nnIrHNVHc5tJYe2Gy2OKa3/h7n97m/QRwHY7FwaMYrt6hkt9 L0q9WFKYeibHLbRzWmsJqJHE7WmpAJCR7ckEQVQY/7LQ6GFmijjYdExjawkidByF YevipD/Z7tcpMBcUUXda4ax7UVN+IyUzuXEt1Zs5r1WEnN4dvobmomkd0WBpQzyd Zg2mW08uhQFnUzigpiFkSZ6mj92DIWSdGo9mtzuLkz6oDfxODFFRoNu3BT8a1HUL 79H99XP9iNPwr5L/RCaf/7bi3VheLqBIjYlcfN4wv93S4EksnPDY8mxBvq7VeMmW HkaAC6fMa46Jg7Kq1O+lZgUuAoScWgdOe80myX78lttJ/Zwh41hBKj6aNoDbg/Ek oQzl7QkP/ewSZ7/Dga79S5vAyXXogtml8oaT2dVxeZ30lA1/SWo5v4zxOeAVJ/n/ ta3ddWa/3NI= =iEWw -----END PGP SIGNATURE----- --CGDBiGfvSTbxKZlW-- From johnl@iecc.com Sun Oct 21 15:44:33 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C23E21F8907 for ; Sun, 21 Oct 2012 15:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.744 X-Spam-Level: X-Spam-Status: No, score=-111.744 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qXmXdLJ8LMy for ; Sun, 21 Oct 2012 15:44:32 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id D0B6621F8868 for ; Sun, 21 Oct 2012 15:44:31 -0700 (PDT) Received: (qmail 23265 invoked from network); 21 Oct 2012 22:44:28 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 21 Oct 2012 22:44:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50847acc.xn--9vv.k1208; i=johnl@user.iecc.com; bh=5T19FhJ+KWo2XdTAmWo2I7k6p2MRcRxxBL0Rb770P3A=; b=uSiwkLPKH4miZfz9hUb+5RsXIGMG3sDbS2Ej3djIyd2jXMt3vui6wt/ivOyEN37ksJL/sYrdDKWvyAAX6rZmRZezySMvV/hWqU5EyhQJTXsHDxvlgrt1BT6840yw0tfQJASigaYP9a/+IlZv94vW1C3xS/j0mzAYfi1Jo3hjyIM= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=50847acc.xn--9vv.k1208; olt=johnl@user.iecc.com; bh=5T19FhJ+KWo2XdTAmWo2I7k6p2MRcRxxBL0Rb770P3A=; b=0TUVVKebQeeGqB0ZOQ0XxecVZuGUR1iYUGV2TfRWWvC3S5TOucOMvtuWoI/Zq3uCGIDznY7wVHz7F7pLcGkUDTItmZE97r+ZWrripd5QsMupLOzHILVd2sOlgdS1XoGW/bBTmv0F0l3fhEzMQv+Eb3BkJj4jk7JSj5sjqfiH1lY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 21 Oct 2012 22:44:06 -0000 Message-ID: <20121021224406.33236.qmail@joyce.lan> From: "John Levine" To: asrg@irtf.org In-Reply-To: <20121021212040.GE3248@hjp.at> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2012 22:44:33 -0000 >> Probably not, although I'm waiting for ESPs to figure out that if they >> send every message from a different IP, > >I thought of that but I wouldn't be surprised to overflow the router's >ARP table Well, yes, if you configure stuff in a naive way. I'd route an entire /64 to the mail server, and configure the server as its own router with all of those IP addresses internally forwarded to a single IP that talks to the outside world. If you wanted to do IP hopping, it wouldn't be hard to do. >> it'll be much easier to process bounces and complaints since all >> they'll need is the IP to figure out what the list and address was. > >Is it? For mailing-lists, I think VERP is simpler and more robust. Depends what your intentions are. If you're trying to do listwashing, you may wall see DNSBL listings rather than bounces. I like VERP just fine and my lists use it, but I do get back FBL reports that are munged to the point where I can't tell who complained. But they rarely munge the IP. R's, John From tjc@ecs.soton.ac.uk Mon Oct 22 03:26:56 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DEDB21F8518 for ; Mon, 22 Oct 2012 03:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1l3FgK+QFhzn for ; Mon, 22 Oct 2012 03:26:55 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id 3378D21F861A for ; Mon, 22 Oct 2012 03:26:53 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MAQo4U032182 for ; Mon, 22 Oct 2012 11:26:50 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk q9MAQo4U032182 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=200903; t=1350901611; bh=EyGHMI2zWhjrTD6St5Nyc/4DhP8=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=Nzu7VbSlv3aIbXnjqth0A6jTIp8bRYUUBABuIfb5ZBXuZIG50lYTlPpLj4sFllLh9 o3w52QDyKSMbipE8hM/zHy0CRNNudoEf5qF1k1mu/cFr2s8biFbyK4Fo6i0XZUr28I Mm6aiIfuOCPnmg2CS3KpQTGCYPhSD5gocRxyRKh0= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id o9LBQo0430609746jy ret-id none; Mon, 22 Oct 2012 11:26:50 +0100 Received: from ip-205-178.eduroam.soton.ac.uk (ip-205-178.eduroam.soton.ac.uk [152.78.205.178]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id q9MAQkT8001388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 22 Oct 2012 11:26:47 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Tim Chown In-Reply-To: Date: Mon, 22 Oct 2012 11:26:46 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20121019224131.28382.qmail@joyce.lan> <5081EF6F.9030808@hireahit.com> <5C0A004C-1BAD-4103-85C2-B94B718F0367@blighty.com> <2F1F49FD-300A-4DB3-B8D6-F3E9440C359A@ecs.soton.ac.uk> To: Anti-Spam Research Group - IRTF X-Mailer: Apple Mail (2.1499) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=o9LBQo043060974600; tid=o9LBQo0430609746jy; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: q9MAQo4U032182 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 10:26:56 -0000 On 20 Oct 2012, at 05:41, Mikael Abrahamsson wrote: > On Fri, 19 Oct 2012, Steve Atkins wrote: >=20 >> (I'm betting that "mask the bottom 64 bits before querying" would = work just fine, but I don't think we have enough v6 space in use yet to = say for sure.) >=20 > I agree. Although I believe some ISPs will put multiple customers in a = single /64, this is mostly going to be dynamic customers anyway = (multiple laptops on a wifi for instance), and those I would imagine are = treated with the same policy so it doesn't really matter. Per /64 = handling is a reasonable tradeoff between granularity and practicality = in my mind. A /64 basis seems to be the most sensible starting point, from which one = could 'suck it and see'. In client scenarios where multiple users share a /64, e.g. in a wifi = hotspot, then they are probably sharing one public IPv4 address with = IPv4 NAT now. =20 In data centre scenarios, what do we expect there? It's not clear from = draft-lopez-v6ops-dc-ipv6-03. It may depend on whether the hosting is = physical or virtual? The allocated prefix is likely to be quite stable. In home networks, the current trend in Europe seems to be /60 to /56, = though some offer /64 or /48. In some cases the equipment can only = handle /64 now, but expect that to shift to /56 or /60 later. The work = on draft-ietf-homenet-arch-05 expects the ISP to offer multiple /64's. = It seems many ISPs will vary the prefix offered over time much as with = dynamic IPv4 addresses today. In some countries, that's apparently a = legal requirement. In enterprises, /48, and more likely to be stable. Our evidence from incoming spam is that most of it comes via dual-stack = list servers. There's very little evidence of spam coming from = autoconfigured addresses that would indicate client senders. Tim= From hmurray@megapathdsl.net Wed Oct 24 19:00:17 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F1121F8F6D for ; Wed, 24 Oct 2012 19:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.288 X-Spam-Level: **** X-Spam-Status: No, score=4.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2sPq5s-jGG+S for ; Wed, 24 Oct 2012 19:00:17 -0700 (PDT) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id 864C621F8F6B for ; Wed, 24 Oct 2012 19:00:17 -0700 (PDT) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 30189800037; Wed, 24 Oct 2012 19:00:17 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: asrg@irtf.org From: Hal Murray Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Oct 2012 19:00:17 -0700 Message-Id: <20121025020017.30189800037@ip-64-139-1-69.sjc.megapath.net> Cc: hmurray@megapathdsl.net Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 02:00:18 -0000 John Levine said: > Depends what your intentions are. If you're trying to do listwashing, you > may wall see DNSBL listings rather than bounces. I like VERP just fine and > my lists use it, but I do get back FBL reports that are munged to the point > where I can't tell who complained. But they rarely munge the IP. People trying to avoid listwashing will learn to munge the bottom bits of any IPv6 address. Similarly, DNSBLs could mask off the bottom bits of any IPv6 address that they expose. -- These are my opinions. I hate spam. From johnl@iecc.com Wed Oct 24 19:49:24 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8A021F8F26 for ; Wed, 24 Oct 2012 19:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.764 X-Spam-Level: X-Spam-Status: No, score=-111.764 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxPUfXKiRbbY for ; Wed, 24 Oct 2012 19:49:23 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id 7A31821F8546 for ; Wed, 24 Oct 2012 19:49:22 -0700 (PDT) Received: (qmail 24018 invoked from network); 25 Oct 2012 02:49:21 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Oct 2012 02:49:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5088a8b1.xn--i8sz2z.k1210; i=johnl@user.iecc.com; bh=ZKoJ2oWZOQ25Qbaq1eM7ifcX9fGtNpjFB2XmPdltb3k=; b=iKbWnSMS8rGkJdgk8w2SvSisl7JPYvUjn40bF7oSHwfxSXzxsbWs6FK9YPW90qjnn3MAFr6b7MOyKpUdCsTzztI5x/Yu95Sc+y63/wM4uZEXoStQcH1Tnl7Ejocg2G3kfgbrrnyzlMZNPabWYRvszCKdhNxQDLVG/+edWNpTH1I= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=5088a8b1.xn--i8sz2z.k1210; olt=johnl@user.iecc.com; bh=ZKoJ2oWZOQ25Qbaq1eM7ifcX9fGtNpjFB2XmPdltb3k=; b=L/OZTBqRc/cihbWTKq9D5HY/LHSph5BXYzCpebth2t0f6y5tgvfHxjFceyWq+8fX6tyxs8nD7s+XFqpQr9UYfzh0ARHoXSrER7J7NpmRGUGtBbEraob5fPi2Td/o9M0aYX31PwyEB547yLPOB+/bWssLLA2dO3uBKi7iFRIja7Y= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Oct 2012 02:48:59 -0000 Message-ID: <20121025024859.3176.qmail@joyce.lan> From: "John Levine" To: asrg@irtf.org In-Reply-To: <20121025020017.30189800037@ip-64-139-1-69.sjc.megapath.net> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 02:49:24 -0000 >> Depends what your intentions are. If you're trying to do listwashing, you >> may wall see DNSBL listings rather than bounces. I like VERP just fine and >> my lists use it, but I do get back FBL reports that are munged to the point >> where I can't tell who complained. But they rarely munge the IP. > >People trying to avoid listwashing will learn to munge the bottom bits of any >IPv6 address. Well, maybe. Personally, I think the threat of listwashing is overstated. The really slimy senders have lists so dirty that no amount of washing will clean them. But anyway, I'm seeing a lot of assertions about how IPv6 mail will work, and precious little running core or simulations. As always, anyone want to do some, you know, research? R's, John From steve@blighty.com Wed Oct 24 19:59:56 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4726421F8852 for ; Wed, 24 Oct 2012 19:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-HraVct3y73 for ; Wed, 24 Oct 2012 19:59:55 -0700 (PDT) Received: from m.wordtothewise.com (misc.wordtothewise.com [184.105.179.154]) by ietfa.amsl.com (Postfix) with ESMTP id 747D521F8840 for ; Wed, 24 Oct 2012 19:59:55 -0700 (PDT) Received: from satsuke.wordtothewise.com (204.11.227.194.static.etheric.net [204.11.227.194]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: steve) by m.wordtothewise.com (Postfix) with ESMTPSA id CFE172DD88 for ; Wed, 24 Oct 2012 19:59:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wordtothewise.com; s=1.wttw; t=1351133994; bh=0fH2b0sNuUXrleFGxS5efnpKXL/zRZIZOKwA6dbqG6k=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=J2cu6314QoqcYY4olD2J8nLJbh4vKduGC7p1CtZPSpJ/9akp7drEp8N5CbQEcE5P+ 72x7+Jw56OacGS/xWI6iS/1+tnstqdC6LeaM18P0tJ67nD2T/k2aCONxnP9bfuTdug 5jRt9/xK0WDTWIh+lwpLPh7Al1/SbrVOy7D0Ddz8= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Steve Atkins In-Reply-To: <20121025024859.3176.qmail@joyce.lan> Date: Wed, 24 Oct 2012 20:00:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20121025024859.3176.qmail@joyce.lan> To: Anti-Spam Research Group - IRTF X-Mailer: Apple Mail (2.1499) Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 02:59:56 -0000 On Oct 24, 2012, at 7:48 PM, "John Levine" wrote: >>> Depends what your intentions are. If you're trying to do = listwashing, you >>> may wall see DNSBL listings rather than bounces. I like VERP just = fine and >>> my lists use it, but I do get back FBL reports that are munged to = the point >>> where I can't tell who complained. But they rarely munge the IP.=20 >>=20 >> People trying to avoid listwashing will learn to munge the bottom = bits of any=20 >> IPv6 address. >=20 > Well, maybe. Personally, I think the threat of listwashing is = overstated. > The really slimy senders have lists so dirty that no amount of washing = will=20 > clean them. >=20 > But anyway, I'm seeing a lot of assertions about how IPv6 mail will = work, > and precious little running core or simulations. As always, anyone = want > to do some, you know, research? It's mostly dependent on how IPv6 addresses for mailservers (legitimate = and otherwise) will be allocated, and how much IPv6 will be used for = inter-domain email delivery. Do we have any data, or researched speculation, about = that to work from? Cheers, Steve From prvs=0645E458C4=paul@pscs.co.uk Thu Oct 25 04:12:17 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABAE21F8998 for ; Thu, 25 Oct 2012 04:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NDUuHW420nr for ; Thu, 25 Oct 2012 04:12:16 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE1B21F8997 for ; Thu, 25 Oct 2012 04:12:14 -0700 (PDT) Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP; Thu, 25 Oct 2012 12:12:21 +0100 Received: from [192.168.66.100] ([192.168.66.100]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Thu, 25 Oct 2012 11:50:50 +0100 Message-ID: <50891887.50103@pscs.co.uk> Date: Thu, 25 Oct 2012 11:46:31 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20121025024859.3176.qmail@joyce.lan> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V6.0 - Registered X-Organisation: Paul Smith Computer Services Cc: Steve Atkins Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 11:12:17 -0000 On 25/10/2012 04:00, Steve Atkins wrote: > On Oct 24, 2012, at 7:48 PM, "John Levine" wrote: > >>>> Depends what your intentions are. If you're trying to do listwashing, you >>>> may wall see DNSBL listings rather than bounces. I like VERP just fine and >>>> my lists use it, but I do get back FBL reports that are munged to the point >>>> where I can't tell who complained. But they rarely munge the IP. >>> People trying to avoid listwashing will learn to munge the bottom bits of any >>> IPv6 address. >> Well, maybe. Personally, I think the threat of listwashing is overstated. >> The really slimy senders have lists so dirty that no amount of washing will >> clean them. >> >> But anyway, I'm seeing a lot of assertions about how IPv6 mail will work, >> and precious little running core or simulations. As always, anyone want >> to do some, you know, research? > It's mostly dependent on how IPv6 addresses for mailservers (legitimate and > otherwise) will be allocated, and how much IPv6 will be used for inter-domain > email delivery. Do we have any data, or researched speculation, about that > to work from? > I actually think getting any *useful* data about this would be very tricky at the moment, if not impossible. I know that we can't use IPv6 anywhere. We have 4 broadband connections with different suppliers, and none support IPv6 yet, and the data centre we use for our servers also doesn't support IPv6 yet. I guess lots of people are in the same situation, especially smaller companies. This probably means that spammers in general won't be using IPv6 yet - would it be worth their hassle, given that most of their 'customers' won't have it. So, anyone who does have IPv6 MX servers will probably just be getting IPv6 mail from people like Google, and no one else. So, it might be interesting to get data to see how widely IPv6 is used for email currently, but it's unlikely to be useful data to give us realistic ideas how spam will affect the IPv6 infrastructure in the future. eg, there may be virtually no IPv6 spam now, but it won't stay that way. (My personal view is that IPv6 for widespread email use is well in the future. There is no huge advantage over IPv4 given that the number of MTAs is vastly smaller than the number of other Internet connected devices. For interoperability, everyone with an MTA will NEED an IPv4 address for now. There are complexity issues especially to do with security, hacking protection, spam filtering etc. So, I think most mail admins will be leaving IPv6 turned off until they need to turn it on - which may take a while, since it'll be a catch-22 situation. What may trigger it is if someone like Google decides to turn OFF all IPv4 support in their mail infrastructure, but I think that's unlikely for the foreseeable future... MSAs may support IPv6 a lot sooner to support their IPv6 MUAs, but those won't have the spam issues. I know this isn't an 'IETF approved' viewpoint, but it's mine, based on our customers) - Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 From martijn.grooten@virusbtn.com Thu Oct 25 05:14:16 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2E321F892C for ; Thu, 25 Oct 2012 05:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hCldNH3GrFj for ; Thu, 25 Oct 2012 05:14:15 -0700 (PDT) Received: from mx3.sophos.com (mx3.sophos.com [216.47.234.212]) by ietfa.amsl.com (Postfix) with ESMTP id AFD0621F8928 for ; Thu, 25 Oct 2012 05:14:14 -0700 (PDT) Received: from mx3.sophos.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9654C1884C8 for ; Thu, 25 Oct 2012 13:14:13 +0100 (BST) Received: from ABN-EXCH1A.green.sophos (unknown [10.100.70.61]) by mx3.sophos.com (Postfix) with ESMTPS id 101E4188357 for ; Thu, 25 Oct 2012 13:14:13 +0100 (BST) Received: from abn-exch1b.green.sophos ([fe80::dc96:facf:3d2c:c352]) by ABN-EXCH1A.green.sophos ([fe80::67:3150:dacd:910d%16]) with mapi id 14.02.0247.003; Thu, 25 Oct 2012 13:14:01 +0100 From: Martijn Grooten To: Anti-Spam Research Group - IRTF Thread-Topic: [Asrg] DNSBL and IPv6 Thread-Index: AQHNslR6xC5czKb9GUqL86cjG76NGpfJQSSAgAADF4CAAIJVgIAAIJXg Date: Thu, 25 Oct 2012 12:14:00 +0000 Message-ID: <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> References: <20121025024859.3176.qmail@joyce.lan> <50891887.50103@pscs.co.uk> In-Reply-To: <50891887.50103@pscs.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.110.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 12:14:16 -0000 > My personal view is that IPv6 for widespread email use is well in the fut= ure. I think you'll find few experts who think that there's an urgent need for I= Pv6 for email. But IPv6 is currently being used for email (Google and Comca= st are among those currently accepting email over IPv6 - and these are big = players) and its use could (and probably will) increase. I think it would b= e a rather bad idea if spammers got an easy ride if they were to send mail = over IPv6. And personally, I think it would also be bad if we told people to start usi= ng IPv6 as soon as possible, except for email because we don't really know = how to do spam filtering there. Anyway, back on topic: I'm still not convinced we'd be talking about IPv6-b= ased blacklists if we didn't have a long and successful history of IPv4-bas= ed blacklists. IP-blacklists work well on IPv4 because the IP-space is small enough to kee= p the lists small and large enough so that different IPs really mean differ= ent senders. I haven't really seen a suggestion on how to run IPv6-based blacklists that= convinced me. (That's a rather unscientific claim, I know. I'd love for pe= ople to help John with his simulation so that we get a better idea; note th= at he doesn't need IPv6 data. I'm afraid I don't have the required data mys= elf.) Can't we do something entirely different for IPv6? Like, use domain-based f= iltering by making it mandatory to DKIM-sign a message you send over IPv6 o= utside of your network? As long as IPv4 and IPv6 are running in parallel it= should be possible for IPv6 MTA to refuse messages that aren't DKIM-signed= - and tell the sender to retry over IPv4. I know this isn't an ideal solution either (one weakness is that it allows = you to DDoS an MTA by sending large numbers of messages with an invalid sig= nature), but perhaps it's better than trying to make IP-blacklists work ove= r IPv6? Or perhaps someone can come with a better X now that MTAs can still= afford to tell IPv6-senders "do X or retry over IPv4". Martijn. ________________________________ Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33. From matthias@leisi.net Thu Oct 25 05:35:52 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A8C21F8A0A for ; Thu, 25 Oct 2012 05:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZnZHmVCoILM for ; Thu, 25 Oct 2012 05:35:51 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5A821F8A01 for ; Thu, 25 Oct 2012 05:35:51 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n9so1971485oag.13 for ; Thu, 25 Oct 2012 05:35:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=zHGnC09Nca9RjWsCSV2h83iCm8Sr6TlRLU6hmVCKRl0=; b=Kf60toTx5GJp55lK3miQl+MtN/subX3aY/nIOct6FRYRZWtRzPuyDuvn8vNxaxcUWU GE6IDw543DLitxYWZOyeqHWZ1fDcA9Ez55j2S1a6Uv+sYZsgofVhm5/seYFuzdla/NkN HqizEyH6e8l/Sru9gaumEWPwzQ4SElqTxWR/QSoNggTHg0Up/PVyqnfmqo4fkuDWITas HabX/LcCtgsTSBL9gkuy1zDFIv7LdJK/FSeDBbXmjbjj75c6Gv1V2m8f1MslJ79vO/c+ 4kcv3XkSgGWu7segXfoS7ghXUZKlwjlJOnL/dalhooqNudyygU5ZGOt9udl/i8bwoBRV VWUA== Received: by 10.182.194.70 with SMTP id hu6mr15601139obc.4.1351168550672; Thu, 25 Oct 2012 05:35:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.3.173 with HTTP; Thu, 25 Oct 2012 05:35:30 -0700 (PDT) In-Reply-To: <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> References: <20121025024859.3176.qmail@joyce.lan> <50891887.50103@pscs.co.uk> <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> From: Matthias Leisi Date: Thu, 25 Oct 2012 14:35:30 +0200 Message-ID: To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmnvAmVKid7pXZps6f6SY211cOyP5iPNiXTmjMMo+1IUVQf2KxVyhvx2LKg4tgu2UFvxnEj Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 12:35:52 -0000 On Thu, Oct 25, 2012 at 2:14 PM, Martijn Grooten wrote: > I haven't really seen a suggestion on how to run IPv6-based blacklists th= at convinced me. (That's a rather unscientific claim, I know. I'd love for = people to help John with his simulation so that we get a better idea; note = that he doesn't need IPv6 data. I'm afraid I don't have the required data m= yself.) I'm obviously biased since I run dnswl.org, but an IPv6-based whitelist may work better than an IPv6-based blacklist. Enumerating the goodness is generally easier than enumerating the badness. (Of course, all IPv6-DNSxLs have the same risk of caches blowing up if not done right, and the "done right" thing has not been defined yet). -- Matthias From johnl@iecc.com Thu Oct 25 07:12:26 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B0E21F896C for ; Thu, 25 Oct 2012 07:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.777 X-Spam-Level: X-Spam-Status: No, score=-111.777 tagged_above=-999 required=5 tests=[AWL=0.422, BAYES_00=-2.599, HABEAS_ACCREDITED_SOI=-4.3, RCVD_IN_BSP_TRUSTED=-4.3, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6IVGqEay28q for ; Thu, 25 Oct 2012 07:12:25 -0700 (PDT) Received: from leila.iecc.com (leila6.iecc.com [IPv6:2001:470:1f07:1126:0:4c:6569:6c61]) by ietfa.amsl.com (Postfix) with ESMTP id EA0F821F8966 for ; Thu, 25 Oct 2012 07:12:24 -0700 (PDT) Received: (qmail 44863 invoked from network); 25 Oct 2012 14:12:20 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 25 Oct 2012 14:12:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=508948c4.xn--yuvv84g.k1210; i=johnl@user.iecc.com; bh=tZlxwWrIEISh2OQUSjlp9bSbuuoynebHggYI7Apa61A=; b=kKN00sxDYZr6dyM/HrhlK9oWVqVjzDUG7pzR5XCgBfwtEajaaCpRZOXvZQExGf2sarrQ0ZtVYlJyl91fXfm0LYb1XgzXLWOPhrZD3YMCxBc/cxIs8H8m8wTWkvxf9jhS3b25kkhAn9sLx9OdBp8rCJTCrgmvbDDxQdtMIzB30vw= DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:vbr-info; s=508948c4.xn--yuvv84g.k1210; olt=johnl@user.iecc.com; bh=tZlxwWrIEISh2OQUSjlp9bSbuuoynebHggYI7Apa61A=; b=apSgvzDERUHxn+gBNVOya0tXIVZsveHPjV8hOXMY1soK85kw1DgyoCwCkCk9k3IX9eQ9hwVYW4kLnApTiv2rpS+vBGBebwvzO9gYrVA3UuPVzE3TONLMmUikOVF1B/6tXtxtkjY6QPG0vX4XafQORSjlbvCkPQCsgCBBH9v/cZQ= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 25 Oct 2012 14:11:58 -0000 Message-ID: <20121025141158.11869.qmail@joyce.lan> From: "John Levine" To: asrg@irtf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:12:26 -0000 >It's mostly dependent on how IPv6 addresses for mailservers (legitimate and >otherwise) will be allocated, and how much IPv6 will be used for inter-domain >email delivery. Do we have any data, or researched speculation, about that >to work from? Well, I'm at a meeting where I can ask around. I did a little greppage this morning and found that in the year that I've had incoming v6 mail, I've gotten connections from a total of 2300 addresses. The vast majority of mail is from a handful of known senders such as the IETF, and NANOG. The real answer is that nobody knows what the IP address patterns will be, but I think we can come up with some plausible scenarios. The number of legitimate mail servers doesn't seem to be growing very fast, so I expect the real mail will continue to come from a relatively small set of IPs. Bot spam might just use whatever address the host already has or might hop around. At breakfast this morning, someone pointed out that Windows uses IPv6 anonymous addresses, and they'd seen their users hop around somewhat. http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true R's, John Here's the IPs that have connected more than 1000 times in the past year: 34084 2001:1890:123a::1:1e 12971 2001:1838::cc5d:d48a 12113 2001:4f8:fff6::35 7611 2001:1890:1112:1::1e 5810 2001:1890:126c::1:1e 4810 2a02:2658:1011:1::2:2013 3747 2001:500:13::107 3298 2604:8d00:0:1::3 3259 2604:8d00:0:1::4 2309 2001:1890:123a::1:2f 2239 2604:8d00:0:1::9 2074 2001:48a8:6880:68::116:162 1635 2620:0:2d0:1::100 1281 2001:1868:4:1::25 1251 2a01:4f8:120:9382::145 1058 2001:1838:2001:8::4 From rob@invaluement.com Thu Oct 25 07:24:38 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C8D21F85CF for ; Thu, 25 Oct 2012 07:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id METaxKhA1Y6E for ; Thu, 25 Oct 2012 07:24:37 -0700 (PDT) Received: from mail.powerviewmail.com (mail.powerviewmail.com [204.9.77.40]) by ietfa.amsl.com (Postfix) with ESMTP id DF79621F8630 for ; Thu, 25 Oct 2012 07:24:35 -0700 (PDT) Received: from ([204.9.77.40]) by mail.powerviewmail.com (IceWarp 10.4.3) with ASMTP id JYX69733 for ; Thu, 25 Oct 2012 10:24:33 -0400 Message-ID: <50894BA1.7020100@invaluement.com> Date: Thu, 25 Oct 2012 10:24:33 -0400 From: Rob McEwen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: asrg@irtf.org References: <20121025141158.11869.qmail@joyce.lan> In-Reply-To: <20121025141158.11869.qmail@joyce.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:24:38 -0000 On 10/25/2012 10:11 AM, John Levine wrote: > but I think we can come up with some plausible scenarios. One thing that is harmless and which should be promoted now is the exclusive use of IPv6 addresses for authenticated e-mail headed to the mail server. That way, IPv6 can be dynamically assigned IPs for things like residential customers where that end user's IPv6 would never sent mail directly to the recipient. Then, such a mail server could, for now, ONLY accept mail for THOSE smtp-authenticated/IPv6 sessions, and actually refuse non-authenticated IPv6 traffic. Such a server would then relay out such mail via IPv4. 99.9% of the argument about hurrying up IPv6 implementation for mail servers due to running out of IPv4 IPs are solved by this scenario since there are thousands of dynamically assigned IPs delegated to end users for every one legitimate mail server IP. Not saying this is the answer for 100 years from now, but this scenario scales well, too. When EVERYTHING is assigned an IPv6 IP (your car, your refrigerator, etc)... those IPv6 IPs won't be prevented from sending e-mail in the scenario I described above, even if mail servers haven't yet moved into the IPv6 world. -- Rob McEwen http://dnsbl.invaluement.com/ rob@invaluement.com +1 (478) 475-9032 From skull@bofhland.org Thu Oct 25 07:37:54 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99BEF21F8A28 for ; Thu, 25 Oct 2012 07:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eNMSniAmQEJ for ; Thu, 25 Oct 2012 07:37:53 -0700 (PDT) Received: from mithrandir.bofhland.org (mithrandir.bofhland.org [IPv6:2a02:9a8:94::b]) by ietfa.amsl.com (Postfix) with ESMTP id A5D5F21F8A18 for ; Thu, 25 Oct 2012 07:37:51 -0700 (PDT) Received: from zarathustra.local (zarathustra.spin.it [147.123.15.60]) by mithrandir.bofhland.org (Postfix) with ESMTPSA id F0D4F6C0A1 for ; Thu, 25 Oct 2012 16:37:48 +0200 (CEST) Message-ID: <50894EBB.5090907@bofhland.org> Date: Thu, 25 Oct 2012 16:37:47 +0200 From: "Emanuele Balla (aka Skull)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20121025024859.3176.qmail@joyce.lan> <50891887.50103@pscs.co.uk> <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> In-Reply-To: <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:37:54 -0000 On 10/25/12 2:14 PM, Martijn Grooten wrote: > Anyway, back on topic: I'm still not convinced we'd be talking about > IPv6-based blacklists if we didn't have a long and successful history > of IPv4-based blacklists. > > IP-blacklists work well on IPv4 because the IP-space is small enough > to keep the lists small and large enough so that different IPs really > mean different senders. > > I haven't really seen a suggestion on how to run IPv6-based > blacklists that convinced me. (That's a rather unscientific claim, I > know. I'd love for people to help John with his simulation so that we > get a better idea; note that he doesn't need IPv6 data. I'm afraid I > don't have the required data myself.) The point, IMHO, is that *nobody* has those data yet... The number of available IPs will explode with IPv6. The number of "legit" distinct emitters is (probably) not. At the end, everything will be about how fast abusive/infected machines will move around the address space: 1) from one IP to another inside their own /64 2) from one /64 to another 3) from one ISP to another, particularly where showshoe-like schemes are in place For point 1, there will be a limit to this change rate, at least when we speak about bots, and it's even been cited here already: a single machine can't use too many addresses without saturating its router neighbor table. Which is a valid esteem for the number of different IPs the IPv6-address-change-mechanism will be able to use effectively, then? Truth is we don't know for sure... For point 2, then. The ability of a bot to move from a /64 to another will depend on its ISP policies and implementation (like the ability of a bot to change its IP in IPv4 depends mostly on how the ISP implemented its dynamic allocation). Which is a valid esteem for that? Again, we don't know for sure: too few examples for having consistent statistics. For number 3, the number of different allocations will only depend on the number of different machines owned by the spammer, while there may be no "neighbor limit" here, if the ISP did it right, so he/she could make full use of the entire allocation. But again, we lack a lot of statistics here as well... So, at the moment, the only thing you can simulate is what we already have in IPv4. But the real IPv6 scenario will depend mostly on policies and implementations that are not in place yet... :-\ > Can't we do something entirely different for IPv6? Like, use > domain-based filtering by making it mandatory to DKIM-sign a message > you send over IPv6 outside of your network? As long as IPv4 and IPv6 > are running in parallel it should be possible for IPv6 MTA to refuse > messages that aren't DKIM-signed - and tell the sender to retry over > IPv4. Theoretically this could be an option, but DKIM requiring the receiving end to receive the message DATA before choosing a policy may prove to be a limit. > I know this isn't an ideal solution either (one weakness is that it > allows you to DDoS an MTA by sending large numbers of messages with > an invalid signature), but perhaps it's better than trying to make > IP-blacklists work over IPv6? Or perhaps someone can come with a > better X now that MTAs can still afford to tell IPv6-senders "do X or > retry over IPv4". Could be. We just need to find out a good X then ;-) My personal opinion, FWIW, is that the DNSxL mechanism will still be useful in the future if we can limit the lookup to the first 64 bits instead of the full address. This reduces the problem to something comparable to the current state of IPv4: it's true that default user allocations are larger than IPv4 ones (say a /56, AKA 256 "listing units", instead of a single one like in IPv4), but it's something we can still work with, probably... It it true that there are (and there will be) entities out there assigning stuff like a /112 per-user instead of a /64. But maybe it's not too late to come out with "an X" trying to disallow this setup for wannabe-mailservers... -- Paranoia is a disease unto itself. And may I add: the person standing next to you may not be who they appear to be, so take precaution. ----------------------------------------------------------------------------- http://bofhskull.wordpress.com/ From skull@bofhland.org Thu Oct 25 07:48:10 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D7EA21F8963 for ; Thu, 25 Oct 2012 07:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YR356tHa5s6g for ; Thu, 25 Oct 2012 07:48:09 -0700 (PDT) Received: from mithrandir.bofhland.org (mithrandir.bofhland.org [IPv6:2a02:9a8:94::b]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8F421F8962 for ; Thu, 25 Oct 2012 07:48:08 -0700 (PDT) Received: from zarathustra.local (zarathustra.spin.it [147.123.15.60]) by mithrandir.bofhland.org (Postfix) with ESMTPSA id 7BD276C0A1 for ; Thu, 25 Oct 2012 16:48:07 +0200 (CEST) Message-ID: <50895125.4050606@bofhland.org> Date: Thu, 25 Oct 2012 16:48:05 +0200 From: "Emanuele Balla (aka Skull)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20121025141158.11869.qmail@joyce.lan> <50894BA1.7020100@invaluement.com> In-Reply-To: <50894BA1.7020100@invaluement.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:48:10 -0000 On 10/25/12 4:24 PM, Rob McEwen wrote: Hi Rob! > One thing that is harmless and which should be promoted now is the > exclusive use of IPv6 addresses for authenticated e-mail headed to the > mail server. That way, IPv6 can be dynamically assigned IPs for things > like residential customers where that end user's IPv6 would never sent > mail directly to the recipient. Then, such a mail server could, for now, > ONLY accept mail for THOSE smtp-authenticated/IPv6 sessions, and > actually refuse non-authenticated IPv6 traffic. Such a server would then > relay out such mail via IPv4. 99.9% of the argument about hurrying up > IPv6 implementation for mail servers due to running out of IPv4 IPs are > solved by this scenario since there are thousands of dynamically > assigned IPs delegated to end users for every one legitimate mail server IP. > > Not saying this is the answer for 100 years from now, but this scenario > scales well, too. When EVERYTHING is assigned an IPv6 IP (your car, your > refrigerator, etc)... those IPv6 IPs won't be prevented from sending > e-mail in the scenario I described above, even if mail servers haven't > yet moved into the IPv6 world. So you're basically suggesting that MXs should not allow any IPv6 SMTP connection unless it's coming from a trusted entity, and only MSAs should speak IPv6. This will allow to work in the upcoming IPv4 shortage scenario, as you say. But I think you underestimate how hard could be switching from this scenario to the "all IPv6" one in the future... In other words, you're basically suggesting something like "do not publish any AAAA record for your MXs and just rely on IPv4, unless you found a solution to the IPv6 spam problem". But this is not suggesting a solution anyway... ;-) -- Paranoia is a disease unto itself. And may I add: the person standing next to you may not be who they appear to be, so take precaution. ----------------------------------------------------------------------------- http://bofhskull.wordpress.com/ From prvs=0645E458C4=paul@pscs.co.uk Thu Oct 25 07:50:14 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B231221F8982 for ; Thu, 25 Oct 2012 07:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6utV31yyl+b for ; Thu, 25 Oct 2012 07:50:14 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) by ietfa.amsl.com (Postfix) with ESMTP id 9451421F8963 for ; Thu, 25 Oct 2012 07:50:12 -0700 (PDT) Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP; Thu, 25 Oct 2012 15:52:13 +0100 Received: from [192.168.66.100] ([192.168.66.100]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Thu, 25 Oct 2012 15:37:51 +0100 Message-ID: <50894EBF.2050004@pscs.co.uk> Date: Thu, 25 Oct 2012 15:37:51 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20121025024859.3176.qmail@joyce.lan> <50891887.50103@pscs.co.uk> <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> In-Reply-To: <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V6.0 - Registered X-Organisation: Paul Smith Computer Services Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:50:14 -0000 On 25/10/2012 13:14, Martijn Grooten wrote: > Can't we do something entirely different for IPv6? Like, use domain-based filtering by making it mandatory to DKIM-sign a message you send over IPv6 outside of your network? As long as IPv4 and IPv6 are running in parallel it should be possible for IPv6 MTA to refuse messages that aren't DKIM-signed - and tell the sender to retry over IPv4 Is it even possible to tell an IPv6 sender to retry over IPv4? I know I've seen discussion about whether it should be possible, but I'm fairly sure it wasn't at that time (I think it should be possible) Having a 'retry over IPv4' option would help a lot, especially if we had a mechanism to link an IPv6 and an IPv4 attempt - could be a good way of bootstrapping an IPv6 reputation system (or whitelist). But, I'm not sure the IETF would approve, and it may be too late anyway... I do think that (with hindsight) IPv6 support for MTAs could have done with more thought before it was standardised. Things like requiring DKIM (or SPF or some new equivalent) and mechanisms to fallback to IPv4 may have been good things to enforce in an IPv6 world so being a mandatory part of 'SMTPv6' rather than options as we'd have to do now. MTA SMTP is a totally different world from pretty much everything else IP because although deployment is very widespread the actual number of legitimate MTAs is tiny compared to the rest of the Internet connected stuff, and SMTP is also quite vulnerable to 'legitimate attacks' unlike other protocols (eg most spam is sent by doing everything according to the standards, not by trying to find loopholes in it). IPv6 could have been the place to build a 'safe new SMTP world', but that opportunity is pretty much gone now :-( - Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 From rob@invaluement.com Thu Oct 25 08:19:15 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC1221F90A4 for ; Thu, 25 Oct 2012 08:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=1.049, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tO8of3wUiIwf for ; Thu, 25 Oct 2012 08:19:14 -0700 (PDT) Received: from mail.powerviewmail.com (mail.powerviewmail.com [204.9.77.40]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2D221F902D for ; Thu, 25 Oct 2012 08:19:08 -0700 (PDT) Received: from ([204.9.77.40]) by mail.powerviewmail.com (IceWarp 10.4.3) with ASMTP id JZS68404 for ; Thu, 25 Oct 2012 11:19:04 -0400 Message-ID: <50895868.50100@invaluement.com> Date: Thu, 25 Oct 2012 11:19:04 -0400 From: Rob McEwen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20121025141158.11869.qmail@joyce.lan> <50894BA1.7020100@invaluement.com> <50895125.4050606@bofhland.org> In-Reply-To: <50895125.4050606@bofhland.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:19:15 -0000 On 10/25/2012 10:48 AM, Emanuele Balla (aka Skull) wrote: > So you're basically suggesting that MXs should not allow any IPv6 SMTP > connection unless it's coming from a trusted entity, and only MSAs > should speak IPv6. No. I'm talking about AUTHENTICATED e-mail that is, by design, NOT considered the "sending IP" for that message. Maybe the "originate IP"... but not the "sending IP". I'm not sure what you mean by "only MSAs", this wouldn't prevent the use of IPv6 for OTHER uses. My answers below should clear this up... > In other words, you're basically suggesting something like "do not > publish any AAAA record for your MXs and just rely on IPv4, unless you > found a solution to the IPv6 spam problem". I think you must be greatly misunderstanding me. When millions of end user customers for a large set up their outlook programs (or thunderbird, or whatever)... their connection to their ISP's mail server does NOT use MX records!!!! Instead, that connection goes DIRECTLY to the "a" record of the server host name that the end user puts in the "smtp server" box in their mail client. Furthermore, since this is all happening within an ISP's IP space and to their own customers.. the ISP has MUCH granularity of control... so, if needed, directing of traffic can be manipulated somewhat by the ISP (again, if needed). > But this is not suggesting a solution anyway... yes, this is a solution. Obviously NOT the final solution long term solution... but this solves MANY problems in the meantime. -- Rob McEwen http://dnsbl.invaluement.com/ rob@invaluement.com +1 (478) 475-9032 From skull@bofhland.org Thu Oct 25 08:38:36 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E22B21F88AE for ; Thu, 25 Oct 2012 08:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Azbl5--hRpIH for ; Thu, 25 Oct 2012 08:38:30 -0700 (PDT) Received: from mithrandir.bofhland.org (mithrandir.bofhland.org [IPv6:2a02:9a8:94::b]) by ietfa.amsl.com (Postfix) with ESMTP id 1A16221F8901 for ; Thu, 25 Oct 2012 08:38:30 -0700 (PDT) Received: from zarathustra.local (zarathustra.spin.it [147.123.15.60]) by mithrandir.bofhland.org (Postfix) with ESMTPSA id 711026C0A1 for ; Thu, 25 Oct 2012 17:38:28 +0200 (CEST) Message-ID: <50895CF2.7050807@bofhland.org> Date: Thu, 25 Oct 2012 17:38:26 +0200 From: "Emanuele Balla (aka Skull)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20121025141158.11869.qmail@joyce.lan> <50894BA1.7020100@invaluement.com> <50895125.4050606@bofhland.org> <50895868.50100@invaluement.com> In-Reply-To: <50895868.50100@invaluement.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:38:36 -0000 On 10/25/12 5:19 PM, Rob McEwen wrote: > On 10/25/2012 10:48 AM, Emanuele Balla (aka Skull) wrote: >> So you're basically suggesting that MXs should not allow any IPv6 SMTP >> connection unless it's coming from a trusted entity, and only MSAs >> should speak IPv6. > > No. I'm talking about AUTHENTICATED e-mail that is, by design, NOT > considered the "sending IP" for that message. Maybe the "originate > IP"... but not the "sending IP". I'm not sure what you mean by "only > MSAs", this wouldn't prevent the use of IPv6 for OTHER uses. My answers > below should clear this up... > >> In other words, you're basically suggesting something like "do not >> publish any AAAA record for your MXs and just rely on IPv4, unless you >> found a solution to the IPv6 spam problem". > > I think you must be greatly misunderstanding me. When millions of end > user customers for a large set up their outlook programs (or > thunderbird, or whatever)... their connection to their ISP's mail server > does NOT use MX records!!!! I think we're speaking of the same thing here... :-) MSA == Mail Submission Agent, the SMTP server your MUA (Outlook, Thunderbird, pine) will connect to in order to send email. MX in my notation was intended as "the MTA on the receiving end" or, in other words, a mailserver that expects to be contacted by others MTAs only, not by MUAs. So, to rephrase the whole thing as I understood it: - allow end customers to use IPv6 to *send* email through their ISP's (not necessarily the connection one) IPv6-enabled authenticated mailserver - do not allow the receiving mailserver (aka "the one published as MX record for the domain") to receive email from strangers through IPv6 Did I get it right? -- Paranoia is a disease unto itself. And may I add: the person standing next to you may not be who they appear to be, so take precaution. ----------------------------------------------------------------------------- http://bofhskull.wordpress.com/ From rob@invaluement.com Thu Oct 25 08:48:17 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84FBD21F8914 for ; Thu, 25 Oct 2012 08:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.917 X-Spam-Level: X-Spam-Status: No, score=-1.917 tagged_above=-999 required=5 tests=[AWL=0.682, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+qSlSS3UAp3 for ; Thu, 25 Oct 2012 08:48:16 -0700 (PDT) Received: from mail.powerviewmail.com (mail.powerviewmail.com [204.9.77.40]) by ietfa.amsl.com (Postfix) with ESMTP id A413321F890D for ; Thu, 25 Oct 2012 08:48:03 -0700 (PDT) Received: from ([204.9.77.40]) by mail.powerviewmail.com (IceWarp 10.4.3) with ASMTP id JZU36559 for ; Thu, 25 Oct 2012 11:47:59 -0400 Message-ID: <50895F2F.2080102@invaluement.com> Date: Thu, 25 Oct 2012 11:47:59 -0400 From: Rob McEwen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20121025141158.11869.qmail@joyce.lan> <50894BA1.7020100@invaluement.com> <50895125.4050606@bofhland.org> <50895868.50100@invaluement.com> <50895CF2.7050807@bofhland.org> In-Reply-To: <50895CF2.7050807@bofhland.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:48:17 -0000 On 10/25/2012 11:38 AM, Emanuele Balla (aka Skull) wrote: > So, to rephrase the whole thing as I understood it: > > - allow end customers to use IPv6 to *send* email through their ISP's > (not necessarily the connection one) IPv6-enabled authenticated mailserver > > - do not allow the receiving mailserver (aka "the one published as MX > record for the domain") to receive email from strangers through IPv6 > > > Did I get it right? yes. Except that, again, the authenticated mail being sent by end users to be relayed out by their ISPs mail server doesn't require that any domains having "two-faced" MX records. -- Rob McEwen http://dnsbl.invaluement.com/ rob@invaluement.com +1 (478) 475-9032 From prvs=0645E458C4=paul@pscs.co.uk Thu Oct 25 08:50:15 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0A5921F894C for ; Thu, 25 Oct 2012 08:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kleAL1Ta5TMG for ; Thu, 25 Oct 2012 08:50:14 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) by ietfa.amsl.com (Postfix) with ESMTP id CA19A21F8934 for ; Thu, 25 Oct 2012 08:50:13 -0700 (PDT) Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP; Thu, 25 Oct 2012 16:52:14 +0100 Received: from [192.168.66.100] ([192.168.66.100]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Thu, 25 Oct 2012 16:37:25 +0100 Message-ID: <50895CB6.8030802@pscs.co.uk> Date: Thu, 25 Oct 2012 16:37:26 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20121025024859.3176.qmail@joyce.lan> <50891887.50103@pscs.co.uk> <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> <50894EBB.5090907@bofhland.org> In-Reply-To: <50894EBB.5090907@bofhland.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V6.0 - Registered X-Organisation: Paul Smith Computer Services Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 15:50:16 -0000 On 25/10/2012 15:37, Emanuele Balla (aka Skull) wrote: > For point 1, there will be a limit to this change rate, at least when we > speak about bots, and it's even been cited here already: a single > machine can't use too many addresses without saturating its router > neighbor table. > Which is a valid esteem for the number of different IPs the > IPv6-address-change-mechanism will be able to use effectively, then? > Truth is we don't know for sure... Hmm - I've heard talk about this problem of saturating the router neighbour table. To be honest, I'm not entirely sure what a 'neighbour table' is... But, why would people have a /64 block if the router can't cope with it? >> I know this isn't an ideal solution either (one weakness is that it >> >allows you to DDoS an MTA by sending large numbers of messages with >> >an invalid signature), but perhaps it's better than trying to make >> >IP-blacklists work over IPv6? Or perhaps someone can come with a >> >better X now that MTAs can still afford to tell IPv6-senders "do X or >> >retry over IPv4". > Could be. We just need to find out a good X then Rather than using DKIM, why not use client certificates keyed off the sender domain. That way you don't need to get the message content. It would require TLS for all IPv6 MTA-MTA connections, but given that 'old' servers won't support IPv6, and new ones 'should' support TLS, that shouldn't be an insurmountable problem. It would also mean that a sending MTA couldn't send to the same target MTA using the same connection for different sender domains. This wouldn't be a problem for small->moderate sized MTAs. I suppose it's only the big MTAs (google et al) who would suffer a bit because of something like this, but then, if it cut down on the spam, they'd probably gain more than they lost. The problem is that certificates on their own (like DKIM) won't necessarily reduce spam, just spoofing. So, there'd need to be some way of linking reputation to domain, but that would be the same with DKIM. - Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 From skull@bofhland.org Thu Oct 25 09:10:56 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAF6921F8956 for ; Thu, 25 Oct 2012 09:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaxLoYNSqVek for ; Thu, 25 Oct 2012 09:10:56 -0700 (PDT) Received: from mithrandir.bofhland.org (mithrandir.bofhland.org [IPv6:2a02:9a8:94::b]) by ietfa.amsl.com (Postfix) with ESMTP id D4DA021F8789 for ; Thu, 25 Oct 2012 09:10:55 -0700 (PDT) Received: from zarathustra.local (zarathustra.spin.it [147.123.15.60]) by mithrandir.bofhland.org (Postfix) with ESMTPSA id D45046C0A1 for ; Thu, 25 Oct 2012 18:10:53 +0200 (CEST) Message-ID: <5089648C.4010907@bofhland.org> Date: Thu, 25 Oct 2012 18:10:52 +0200 From: "Emanuele Balla (aka Skull)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20121025024859.3176.qmail@joyce.lan> <50891887.50103@pscs.co.uk> <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> <50894EBB.5090907@bofhland.org> <50895CB6.8030802@pscs.co.uk> In-Reply-To: <50895CB6.8030802@pscs.co.uk> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:10:56 -0000 On 10/25/12 5:37 PM, Paul Smith wrote: > On 25/10/2012 15:37, Emanuele Balla (aka Skull) wrote: > >> For point 1, there will be a limit to this change rate, at least when we >> speak about bots, and it's even been cited here already: a single >> machine can't use too many addresses without saturating its router >> neighbor table. >> Which is a valid esteem for the number of different IPs the >> IPv6-address-change-mechanism will be able to use effectively, then? >> Truth is we don't know for sure... > Hmm - I've heard talk about this problem of saturating the router > neighbour table. To be honest, I'm not entirely sure what a 'neighbour > table' is... Basically, the ARP table, except for IPv6 not using ARP at all... > But, why would people have a /64 block if the router can't > cope with it? The point is a /64 allows basically an infinite number of devices in one single network (2^64 being big enough to be considered infinite for our purpose). This doesn't mean a router should be able to manage an infinite amount of devices: no router could accomplish this requirement... :-) The router basically needs to cope with a given number of devices inside the /64. Maybe 10, maybe 100, maybe 1000, but a limited amount, compared to 2^64. The neighbor table must be able to keep track of IPv6-MAC associations for each device. But if one of these devices starts changing address quickly enough, it's going to saturate the router memory (or only the neighbor table) at some point... What happens next depends on how the router will manage the issue... -- Paranoia is a disease unto itself. And may I add: the person standing next to you may not be who they appear to be, so take precaution. ----------------------------------------------------------------------------- http://bofhskull.wordpress.com/ From prvs=0645E458C4=paul@pscs.co.uk Thu Oct 25 09:40:55 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89B3921F88CD for ; Thu, 25 Oct 2012 09:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wHd-JXDeD24 for ; Thu, 25 Oct 2012 09:40:55 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2E621F899B for ; Thu, 25 Oct 2012 09:40:53 -0700 (PDT) Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP for ; Thu, 25 Oct 2012 17:42:07 +0100 Received: from [192.168.66.100] ([192.168.66.100]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP for ; Thu, 25 Oct 2012 17:28:49 +0100 Message-ID: <508968C1.5000903@pscs.co.uk> Date: Thu, 25 Oct 2012 17:28:49 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20121025024859.3176.qmail@joyce.lan> <50891887.50103@pscs.co.uk> <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> <50894EBB.5090907@bofhland.org> <50895CB6.8030802@pscs.co.uk> <5089648C.4010907@bofhland.org> In-Reply-To: <5089648C.4010907@bofhland.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V6.0 - Registered X-Organisation: Paul Smith Computer Services Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:40:55 -0000 On 25/10/2012 17:10, Emanuele Balla (aka Skull) wrote: >> Hmm - I've heard talk about this problem of saturating the router >> neighbour table. To be honest, I'm not entirely sure what a 'neighbour >> table' is... > Basically, the ARP table, except for IPv6 not using ARP at all... OK. I know what an ARP table is :-) The name 'neighbour table' made me think it was trying to track which other routers were around (ie 'neighbours' of this router), which was strange if that got upset by the number of internal addresses being used. My mental visualisation sees the router as a 'gatekeeper', so the internal devices would be 'occupants' or something, not 'neighbours'. So, I visualised that 'neighbours' would be things on the same 'level' as the router - ie other routers. I've done a bit more reading around on the subject, and am getting there - I think :-) It's tricky since we have no access to any IPv6 stuff unless I use a tunnel or an internal test network, which has always been an "artificial" environment AFAIAC (no local router involved), so doing full scale real-world tests isn't possible yet. > The router basically needs to cope with a given number of devices inside > the /64. Maybe 10, maybe 100, maybe 1000, but a limited amount, compared > to 2^64. The neighbor table must be able to keep track of IPv6-MAC > associations for each device. OK - Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 From scott@doc.net.au Thu Oct 25 09:50:32 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24DC421F867E for ; Thu, 25 Oct 2012 09:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1mFF63YNdf0e for ; Thu, 25 Oct 2012 09:50:28 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED3221F8695 for ; Thu, 25 Oct 2012 09:50:28 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id c50so867882eek.13 for ; Thu, 25 Oct 2012 09:50:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=YzS0mE/OZznRvtWzPF2fSC3saKv9xFre3X67Bq7GOmY=; b=CpYOw5h3vFPVNKzPZU6ae8Hv7cuHE4FAJBThzO6sFZccjTFLzoFklZyiLkuBFx6yHq oUdmDKxuPZQYh3qWwspSRX5ge4Nl3RZFpK0UHhMP37zCiu+ZYnGg3ghAg+VixkQP3l5D vvghPAfKu6OwdaDu5PkvbSNQsq2xjWywS6MiXoSf4uVIHkOxtJoVX2i6tt0C741m1kfI WWxpaDPLSveGPjGlIZ+GXV/5J0S5Oyp2zbvfnzvPU/NL5KuSSHtzX6AaUR2da33sOyZj JaAwIjZOaEQBdY6cXrUr8e/HtvMxJ1jO8iM6wQOFF+0OlQaD20aXL6C5i1uJ/pmwVYV3 dt7g== MIME-Version: 1.0 Received: by 10.14.193.134 with SMTP id k6mr27574268een.15.1351183827445; Thu, 25 Oct 2012 09:50:27 -0700 (PDT) Received: by 10.14.67.200 with HTTP; Thu, 25 Oct 2012 09:50:27 -0700 (PDT) In-Reply-To: <508968C1.5000903@pscs.co.uk> References: <20121025024859.3176.qmail@joyce.lan> <50891887.50103@pscs.co.uk> <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> <50894EBB.5090907@bofhland.org> <50895CB6.8030802@pscs.co.uk> <5089648C.4010907@bofhland.org> <508968C1.5000903@pscs.co.uk> Date: Thu, 25 Oct 2012 09:50:27 -0700 Message-ID: From: Scott Howard To: Anti-Spam Research Group - IRTF Content-Type: multipart/alternative; boundary=047d7b343e2a0fa65504cce50077 X-Gm-Message-State: ALoCoQmH1TtSO0WUNACprAyQX8RKplZzsw7GN6sCpnSEvyA1OQwJ8Ui7vZRZfS4KrhyV7nrHnNzS Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 16:50:32 -0000 --047d7b343e2a0fa65504cce50077 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 25, 2012 at 9:28 AM, Paul Smith wrote: > It's tricky since we have no access to any IPv6 stuff unless I use a > tunnel or an internal test network, which has always been an "artificial" > environment AFAIAC (no local router involved), so doing full scale > real-world tests isn't possible yet. > A tunnel doesn't need to be "artifical". Hurricane Electric will give you a free IPv6 tunnel, including a routable range (/56 from memory). Setup the tunnel on one machine, and then configure it to be a router for your local network (using one of the networks from the /56). All of the hosts on that network will now have "native" IPv6. Sure, to get out of your network it has to go via a tunnel, but that's completely transparent to the end hosts. Keep in mind the security implications though - if you don't setup a firewall on your IPv6 tunnel endpoint/router, then you're basically putting any of the systems it routing traffic for directly onto the Internet, with a public IP address. Scott --047d7b343e2a0fa65504cce50077 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 25, 2012 at 9:28 AM, Paul Smith <paul@pscs.co.uk> wrote:
It's tricky since we have no access to any IPv6 stuff unless I use a tu= nnel or an internal test network, which has always been an "artificial= " environment AFAIAC (no local router involved), so doing full scale r= eal-world tests isn't possible yet.

A tunnel doesn't need to be "artifical"= . Hurricane Electric will give you a free IPv6 tunnel, including a routable= range (/56 from memory).=A0 Setup the tunnel on one machine, and then conf= igure it to be a router for your local network (using one of the networks f= rom the /56).=A0 All of the hosts on that network will now have "nativ= e" IPv6.=A0 Sure, to get out of your network it has to go via a tunnel= , but that's completely transparent to the end hosts.

Keep in mind the security implications though - if you don't setup = a firewall on your IPv6 tunnel endpoint/router, then you're basically p= utting any of the systems it routing traffic for directly onto the Internet= , with a public IP address.

=A0 Scott

--047d7b343e2a0fa65504cce50077-- From hmurray@megapathdsl.net Thu Oct 25 17:35:01 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427DD21F856D for ; Thu, 25 Oct 2012 17:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.288 X-Spam-Level: **** X-Spam-Status: No, score=4.288 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40vDgRHvKpQN for ; Thu, 25 Oct 2012 17:35:00 -0700 (PDT) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id A10C321F848F for ; Thu, 25 Oct 2012 17:35:00 -0700 (PDT) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 5415A800037; Thu, 25 Oct 2012 17:34:59 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Anti-Spam Research Group - IRTF From: Hal Murray Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 25 Oct 2012 17:34:59 -0700 Message-Id: <20121026003459.5415A800037@ip-64-139-1-69.sjc.megapath.net> Cc: Hal Murray Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 00:35:01 -0000 > Anyway, back on topic: I'm still not convinced we'd be talking about > IPv6-based blacklists if we didn't have a long and successful history of > IPv4-based blacklists. How about enumerating goodness rather than badness? Does anybody have a list of techniques to consider? We don't have to list IP Addresses. We could list domains and only accept mail if the IP Address reverses to a listed domain (and forward confirms). Would ISPs be willing to run a (white)list of their customers? (Either by domain or IP Address.) How about web hosters? > Can't we do something entirely different for IPv6? Like, use domain-based > filtering by making it mandatory to DKIM-sign a message you send over IPv6 > outside of your network? Does DKIM tell me anything about the sending site being good or bad? If I get a DKIM signed message, I could lookup the domain rather than the sender's IP address. Does that avoid the too-many-IPv6 addresses problem? > I'm obviously biased since I run dnswl.org, but an IPv6-based whitelist may > work better than an IPv6-based blacklist. Enumerating the goodness is > generally easier than enumerating the badness. What fraction of email comes from hosts you have listed? How hard would it be to scale your list up to cover the whole world? Assuming that you don't want to put all your eggs in one basket, how many white lists would you need and/or how would you decide the order to check them? Do we need a list of ISPs that maintain a list of their their clients? -- These are my opinions. I hate spam. From skull@bofhland.org Fri Oct 26 01:12:32 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D24E621F8578 for ; Fri, 26 Oct 2012 01:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q4zyHo-yxF-Z for ; Fri, 26 Oct 2012 01:12:27 -0700 (PDT) Received: from mithrandir.bofhland.org (mithrandir.bofhland.org [IPv6:2a02:9a8:94::b]) by ietfa.amsl.com (Postfix) with ESMTP id 184D921F842D for ; Fri, 26 Oct 2012 01:12:25 -0700 (PDT) Received: from zarathustra.local (zarathustra.spin.it [147.123.15.60]) by mithrandir.bofhland.org (Postfix) with ESMTPSA id 117C96C0A1 for ; Fri, 26 Oct 2012 10:12:23 +0200 (CEST) Message-ID: <508A45E4.8000309@bofhland.org> Date: Fri, 26 Oct 2012 10:12:20 +0200 From: "Emanuele Balla (aka Skull)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20121026003459.5415A800037@ip-64-139-1-69.sjc.megapath.net> In-Reply-To: <20121026003459.5415A800037@ip-64-139-1-69.sjc.megapath.net> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 08:12:33 -0000 On 10/26/12 2:34 AM, Hal Murray wrote: > >> Anyway, back on topic: I'm still not convinced we'd be talking about >> IPv6-based blacklists if we didn't have a long and successful history of >> IPv4-based blacklists. > > How about enumerating goodness rather than badness? > > Does anybody have a list of techniques to consider? > > We don't have to list IP Addresses. We could list domains and only accept > mail if the IP Address reverses to a listed domain (and forward confirms). It's even worse, probably. Reverse DNS lookups have the same problem DNSxL lookups have about caching. And usually also a much higher latency because they need to hop through several delegations before getting an answer. >> Can't we do something entirely different for IPv6? Like, use domain-based >> filtering by making it mandatory to DKIM-sign a message you send over IPv6 >> outside of your network? > > Does DKIM tell me anything about the sending site being good or bad? No, but gives you an hook (the signing entity) you can bind to a reputation score. > If I get a DKIM signed message, I could lookup the domain rather than the > sender's IP address. Does that avoid the too-many-IPv6 addresses problem? Not necessarily. See subdomaining... -- Paranoia is a disease unto itself. And may I add: the person standing next to you may not be who they appear to be, so take precaution. ----------------------------------------------------------------------------- http://bofhskull.wordpress.com/ From swmike@swm.pp.se Fri Oct 26 06:27:39 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F7121F85F9 for ; Fri, 26 Oct 2012 06:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.535 X-Spam-Level: X-Spam-Status: No, score=-2.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7H1pHOqN0t0N for ; Fri, 26 Oct 2012 06:27:39 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id CB7C721F85E8 for ; Fri, 26 Oct 2012 06:27:38 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 73BA79E; Fri, 26 Oct 2012 15:27:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6F7629A for ; Fri, 26 Oct 2012 15:27:35 +0200 (CEST) Date: Fri, 26 Oct 2012 15:27:35 +0200 (CEST) From: Mikael Abrahamsson To: Anti-Spam Research Group - IRTF In-Reply-To: <50894EBB.5090907@bofhland.org> Message-ID: References: <20121025024859.3176.qmail@joyce.lan> <50891887.50103@pscs.co.uk> <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> <50894EBB.5090907@bofhland.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 13:27:39 -0000 On Thu, 25 Oct 2012, Emanuele Balla (aka Skull) wrote: > At the end, everything will be about how fast abusive/infected machines > will move around the address space: > > 1) from one IP to another inside their own /64 > 2) from one /64 to another > 3) from one ISP to another, particularly where showshoe-like schemes are > in place I believe it's going to be common enough that legitimate MTAs will move around within their /64 quite frequently (privacy extensions that are default on in Windows for instance), means outgoing IPv6 address will move to a new outgoing address every N hours (where N is somewhere between 1-48, I don't know exactly). -- Mikael Abrahamsson email: swmike@swm.pp.se From matthias@leisi.net Fri Oct 26 06:28:56 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A822521F85F9 for ; Fri, 26 Oct 2012 06:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DBZW5bmoPmB for ; Fri, 26 Oct 2012 06:28:56 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id D7A4921F85E8 for ; Fri, 26 Oct 2012 06:28:55 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wc20so3361705obb.13 for ; Fri, 26 Oct 2012 06:28:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=jvDt9h7k6Fth+dFRBZjowAFpA1NLVxJRbLR7p2jOfh0=; b=ARnrczI6IFcQRpKd6WmFffTtiliFXmNhquTv6bOXOxL8zc5ufQEpHktWyk21v6eE9x aUDKEJjjZp78aWyStLKcHXSyWjyDSf5LozGTLe8MsKQz2JXu5cexVugJH1FbHU0KF3h4 yD6TOXg5D6ymyKjhNDIFYj3qI92KUxySZw+RUoEA5Uoq7WDKUx1/1kkwhEJX203EhFwu /hn996du1FXw6wsjGIYn5peiEeL0HQ9nh7tlrf3O+tymLi6k/UCbNBBhNnYUp5rbPb5L PdeUnnjzXju38Tn9NlDKscvLpfDlArajrPZ3dtnaMthYvzWUMtH5PSe7L1VkLlhmJhtM W5BA== Received: by 10.182.76.194 with SMTP id m2mr18157674obw.39.1351258135392; Fri, 26 Oct 2012 06:28:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.3.173 with HTTP; Fri, 26 Oct 2012 06:28:35 -0700 (PDT) In-Reply-To: <20121026003459.5415A800037@ip-64-139-1-69.sjc.megapath.net> References: <20121026003459.5415A800037@ip-64-139-1-69.sjc.megapath.net> From: Matthias Leisi Date: Fri, 26 Oct 2012 15:28:35 +0200 Message-ID: To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQnY+9UzLKTQ9L+/V0DAkD0mtmea2cQ/cmVrQYskGjDlefPOn6SAWHh3/jIu+NY63cvDlpyS Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 13:28:56 -0000 On Fri, Oct 26, 2012 at 2:34 AM, Hal Murray wrote: >> I'm obviously biased since I run dnswl.org, but an IPv6-based whitelist may >> work better than an IPv6-based blacklist. Enumerating the goodness is >> generally easier than enumerating the badness. > > What fraction of email comes from hosts you have listed? How hard would it > be to scale your list up to cover the whole world? We do store IPv6 addresses, but we don't publish them yet (since there is no standard yet - the result of the discussion here may lead to the emergence of a de-facto standard, or at least a first trial). So I can not really tell what fraction we have listed in IPv6 world. I can tell about our estimate on what we cover in terms of IPv4 based on the dnswl.org stats. These stats are based not on SMTP trafffic, but on the DNS traffic which we log (sample) on some of the public mirrors. Larger senders with better cache utilization are likely to be somewhat underrepresented in our data. We then do not use the absolute numbers, but logarithmic magnitudes: Magnitude Percent 10.0 100% 9.0 10% 8.0 1% 7.0 0.1% 6.0 0.01% 5.0 0.001% 4.0 0.0001% 3.0 0.00001% 2.0 0.000001% 1.0 0.0000001% Extract from our magnitudes report (I'll happily share more data on request): 1 9.63 IPs where we have no record 2 9.24 IPs which are in our DB*, not published - contains a lot of "bad apples" ("DNSWL Id 0") 3 8.86 IPs which are in our DB*, not published - with fewer "bad apples" ("DNSWL Id 1") 4 8.44 Yahoo 5 8.38 Google 6 8.36 Internally blacklisted (snowshoe ranges etc) 7 8.12 Hotmail 8 8.03 Facebook 9 7.91 Exacttarget 10 7.89 cheetahmail.com * Through imports from third parties or "learned" through the DNS logs It's clear that key is the mag 9.63 of where we have no record. This category contains all the residential/dynamic/botnet IPs; we do not count the number of different IPs. DNSWL Id 0 contains about 300k IPs, DNSWL Id 1 contains about 100k IPs, all the other (published) DNSWL records contain about 200k IPs. Records in 0 and 1 have quite some fluctuation (eg removed since they are not present in the import source any more; promoted from "0" to "1" based on some criteria; demoted from "1" to "0" based on the lack of the same criteria). Entries are manually promoted from "0" and "1" to one of the published DNSWL Ids. Possibly 80k in each of the two "special" records may be considered "good" (as in: not operated by spammer/bot herders), which would lead to ~ 360k mostly legitimate SMTP-sending IPs. > Assuming that you don't want to put all your eggs in one basket, how many > white lists would you need and/or how would you decide the order to check > them? One? Definitely too risky. Two? Not sufficient, in my view. Three? That may work. Four? Could improve diversity. Five? There is a point where returns of additional lists become diminishing (eg higher latency, larger overlaps). -- Matthias From matthias@leisi.net Fri Oct 26 06:32:35 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF4A21F84AD for ; Fri, 26 Oct 2012 06:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.627 X-Spam-Level: X-Spam-Status: No, score=-2.627 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnkK57Og94LQ for ; Fri, 26 Oct 2012 06:32:34 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by ietfa.amsl.com (Postfix) with ESMTP id AAFE221F85C1 for ; Fri, 26 Oct 2012 06:32:34 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wc20so3367030obb.13 for ; Fri, 26 Oct 2012 06:32:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=ETkraHwMJDyXKvEO+Y/igYVNDjGXdZ4vs8900m6VAic=; b=DvVg1fshbSZAEre4e35EE9M7Tyhr4TTSUoBbB8OMeDSYCPZa3P5LHuqDkRf/flrSoB 3ZsNRJhYI3PznJoVVytQEOxhdHOqgFjMRrWaHLlvhBA/wrZGNJNm0YWxUjMLqTthC7E/ 19Od1QDA8vZRiOaXU+fK1lpzgH4O7rRuGUt7M/kXLaJIriEXgl5uOOxijThcalQ0pCN2 Ezm4eHrl9HC4A/btGwrvyPUS3uHY7RaAM0Frw76H0emTm8dTNHK+C2xBiwHf28ie7wYL I0kDqPAlz4FRLiUaW06aNe/4XiVKs59OtpmV+boBblpeIoEBkV6LUZhWfs8L7JnG65F4 poEQ== Received: by 10.182.5.168 with SMTP id t8mr18461598obt.32.1351258354261; Fri, 26 Oct 2012 06:32:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.3.173 with HTTP; Fri, 26 Oct 2012 06:32:14 -0700 (PDT) In-Reply-To: References: <20121025024859.3176.qmail@joyce.lan> <50891887.50103@pscs.co.uk> <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> <50894EBB.5090907@bofhland.org> From: Matthias Leisi Date: Fri, 26 Oct 2012 15:32:14 +0200 Message-ID: To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlZHR0oRcuETBJeiDRp1sVhJ4A2XuQZHl/SfHwxSHnC371fLvFcMo5iMr71FnDNTphZhicT Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 13:32:35 -0000 On Fri, Oct 26, 2012 at 3:27 PM, Mikael Abrahamsson wrote: >> 1) from one IP to another inside their own /64 >> 2) from one /64 to another >> 3) from one ISP to another, particularly where showshoe-like schemes are >> in place > > I believe it's going to be common enough that legitimate MTAs will move > around within their /64 quite frequently (privacy extensions that are Using a /64 as a default seems reasonable, but a new standard for DNSxL lookups should provide some flexibility, either for a full list ("default prefix length = /56") or on a more granular level (using John L.'s original proposal, or some other useful method). -- Matthias From prvs=064688B184=paul@pscs.co.uk Fri Oct 26 07:20:17 2012 Return-Path: X-Original-To: asrg@ietfa.amsl.com Delivered-To: asrg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB06021F85AF for ; Fri, 26 Oct 2012 07:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0TfyqRi65cp for ; Fri, 26 Oct 2012 07:20:17 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) by ietfa.amsl.com (Postfix) with ESMTP id C8E4121F85A7 for ; Fri, 26 Oct 2012 07:20:16 -0700 (PDT) Received: from lmail.pscs.co.uk ([82.68.5.206]) by mail.pscs.co.uk ([188.65.177.237] running VPOP3) with ESMTP; Fri, 26 Oct 2012 15:22:13 +0100 Received: from [192.168.66.100] ([192.168.66.100]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP; Fri, 26 Oct 2012 15:08:58 +0100 Message-ID: <508A997A.3040900@pscs.co.uk> Date: Fri, 26 Oct 2012 15:08:58 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20121025024859.3176.qmail@joyce.lan> <50891887.50103@pscs.co.uk> <0D79787962F6AE4B84B2CC41FC957D0B0D22655F@abn-exch1b.green.sophos> <50894EBB.5090907@bofhland.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Sender: paul X-Server: VPOP3 Enterprise V6.0 - Registered X-Organisation: Paul Smith Computer Services Cc: Matthias Leisi Subject: Re: [Asrg] DNSBL and IPv6 X-BeenThere: asrg@irtf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Anti-Spam Research Group - IRTF List-Id: Anti-Spam Research Group - IRTF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 14:20:17 -0000 On 26/10/2012 14:32, Matthias Leisi wrote: > On Fri, Oct 26, 2012 at 3:27 PM, Mikael Abrahamsson wrote: > >> I believe it's going to be common enough that legitimate MTAs will move >> around within their /64 quite frequently (privacy extensions that are > Using a /64 as a default seems reasonable, but a new standard for > DNSxL lookups should provide some flexibility, either for a full list > ("default prefix length = /56") or on a more granular level (using > John L.'s original proposal, or some other useful method). > The problem with a /64 for black/white listing is that it's not quite the same as an IPv4 /32. So, at the moment we may have a /25 or /26 block, but we'd still have a single IPv6 /64 We may run 50 customer dedicated mail servers on our /64 block, and ideally we'd want each to have their own reputation. So, we couldn't do this if DNSBL/WL filtering is on a /64 block. With our current IPv4 /26 each customer's server would have it's own reputation on an IPv4 DNSBL/WL. Obviously we couldn't say what level of granularity we'd want, or spammers would just say 'we want /128 granularity', to overload everything. We could (theoretically) get a /48 block, but that would be a waste (I know there are LOTS of /48's out there, but still), since we wouldn't need it for routing, just for making it work with /64 based black/whitelisting. I can't think of a good answer to this, but our case is a use case which isn't going to be that unusual. - Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53