From johnl@iecc.com Fri Aug 17 13:22: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 16F2C11E80E0 for ; Fri, 17 Aug 2012 13:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.379 X-Spam-Level: X-Spam-Status: No, score=-102.379 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 Z3wnnXqTeE6Q for ; Fri, 17 Aug 2012 13:22:58 -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 1F1D511E80D1 for ; Fri, 17 Aug 2012 13:22:57 -0700 (PDT) Received: (qmail 5091 invoked from network); 17 Aug 2012 20:22:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:vbr-info:user-agent:cleverness; s=13e2.502ea81f.k1208; bh=iuUG9H6DhrE89jyvlvEto7totboHjMa+M2yUtDtpNN8=; b=RjBadzZ93eKErZPZMDR5dh+V19PDhKxgkXOlxY++QsDT4ben9m7/nAoSf1/bstKen/R/9RP6EFeMGexUagIiYp7tOUp0HExt2EmV2Llv+EatQINYN86a9z84AcfJlrn01H+v7KOUVhKvFSKYRKx/LxQKJvCGTD8vcGYbcfwq+MA= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Received: (ofmipd 127.0.0.1); 17 Aug 2012 20:22:33 -0000 Date: 17 Aug 2012 16:22:55 -0400 Message-ID: From: "John R. Levine" To: "Anti Spam Research Group" User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) Cleverness: None detected MIME-Version: 1.0 Content-Type: MULTIPART/signed; protocol="application/pkcs7-signature"; micalg=sha1; BOUNDARY="3825401791-1349324714-1345234975=:31068" Subject: [Asrg] How will we manage IPv6 spam? 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, 17 Aug 2012 20:22:59 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --3825401791-1349324714-1345234975=:31068 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Hi. Remember the ASRG? I was hoping it might do a little research. In talking to people about IPv6 mail, I'm still coming to the conclusion that anyone who thinks they know how they're going to handle it, beyond the current toy scale, doesn't understand the problem. Things we might address include: * Will DNSBLs that work like v4 BLs, with a query per IP, blow out DNS caches? If so, can this be solved by hacks like partitioned caches that treat BL traffic separately? Would something like my B-tree hack work better? * Is there some reasonable way for networks to publish allocation granularity, e.g., this range is a /64 per user, that range is individual hosts? If they can, how useful would it be to running BLs or otherwise making filtering decisions? * Is there a practical way to do hard or soft whitelisting of V6 mail hosts? (Hard: no body filtering, soft: with body filtering) * Should large and small systems use the same filtering techniques? Large systems have larger mail volume and so can build better models of incoming traffic, small systems can afford cruder filters like no mail from Korea * Can we build models to predict this stuff now, since under the most optimistic scenario it'll still be years before the v6 mail volume approaches v4 mail volume. R's, John --3825401791-1349324714-1345234975=:31068 Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: BASE64 Content-Description: S/MIME Cryptographic Signature Content-Disposition: attachment; filename=smime.p7s MIIIBAYJKoZIhvcNAQcCoIIH9TCCB/ECAQExCzAJBgUrDgMCGgUAMAsGCSqG SIb3DQEHAaCCBSEwggUdMIIEBaADAgECAhA6FNbJAwKAhJZfX7nJAmyNMA0G CSqGSIb3DQEBBQUAMIGTMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRl ciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P RE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVudCBBdXRoZW50 aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTExMDgyNzAwMDAwMFoX DTEyMDgyNjIzNTk1OVowHzEdMBsGCSqGSIb3DQEJARYOam9obmxAaWVjYy5j b20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDA6Dyrmw/qos6y ph5EuKy+/sruC3xCbd9rG9KLMiWu3VorEHRy4PVa09tJFHh8KoHorPRKTzjN 5o05fvxPBGoKysLZs1Whp81PDPWWZXo86Ft94VnpjwzUjKCmM3VcXv8Yw9Lv +4GzZpR8oWeG6hCttcZBE6oZJGgAIrf3avJNqth6JmjL87FrlaK+xB7AARmV s86WhzIpXrCo/nXml3ZB7gqbkAr4QO8EoqcSe5h0V8ZjLdww+R1Zw0m3TZeP u5wrz2646FozcIRxetkcVMi82zykm0fwUdyXPnXKPbYrTUEhcxK+fIfsz+g5 l8L6AodwaAqCzXNKETKojxQzqLn1AgMBAAGjggHeMIIB2jAfBgNVHSMEGDAW gBR6E04AdFvGeGNkJ8Ev4qBbvHnFezAdBgNVHQ4EFgQUtfl1JgM4E8mY80kK F4i5k88rmywwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0l BBkwFwYIKwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIF IDBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBI hkZodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50 aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHow UgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0NPTU9ET0Ns aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAZBgNVHREEEjAQgQ5q b2hubEBpZWNjLmNvbTANBgkqhkiG9w0BAQUFAAOCAQEAHspD+qV1moo6KgyJ RHPCTMObHh5Gr1HcP6pTkivyCofyziYMHasjZbReynNHmhVLjepe5U25dY+a P9u9/WwhJQKYLwITI4LWlAMyKMEmOH4fdwYsOPDVfUyHue/iJhY8v6g3svrX dwyFbJfKZisMU4FswPR+Lm3YHJdQwnPxR9FSCyjbXs40Aq77J4eiXLtFWSsD 9nxISabgon/cmS2wyoWeV8dCrGMhkWM+KuE+hLfjJKCU9KoKy6LrouhWlqXW ZNgQXFT+OH931U1ry22bzzvoNt/pwAYJ5QNJTVGOaqCRMaZW4rq7xnpPH6Ml AgfO1+bEN3OWcQB7RqxlT1iL4zGCAqswggKnAgEBMIGoMIGTMQswCQYDVQQG EwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdT YWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMw Q09NT0RPIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBAhA6FNbJAwKAhJZfX7nJAmyNMAkGBSsOAwIaBQCggdgwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwODE3MjAyMjU1 WjAjBgkqhkiG9w0BCQQxFgQUdPX8pE5Rrnv8hl6XsVVnLQyp56UweQYJKoZI hvcNAQkPMWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFl AwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwIC AUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEggEA hihxG2PA8LmxgioZMTua96MKBk04B+ek/VhYN3hF3bZNt76qJrLblZ/okFDQ meJhg18Jd40GHTzT+Yrs/sS2KraW/iTg08AO4xTHBaNk/wTKpx51mD5PGGBw MZwUT2gFjz92t1epl5xTBR+u2DbO9uEmOYargaX4skXq1KwA2Nasvl4ZtJuC 2nGiPC/+flE+rcU358vU2l7seKwhF1GaC9/w2uftTsfWwiXU6QN893UI+FCK 8RtXYnET9TZzQRA4jKOGXgaqH6g35X7fpD2CJBY79pf+JkLnddEXqj+fYQ9T NzNlo/PP6hEA0uptlvUhDA8WxaiLJ4mlSQx/sTW99A== --3825401791-1349324714-1345234975=:31068-- From feenberg@nber.org Fri Aug 17 13:59: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 CE97E11E80DC for ; Fri, 17 Aug 2012 13:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 rDXuAjIRTUF1 for ; Fri, 17 Aug 2012 13:59:35 -0700 (PDT) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by ietfa.amsl.com (Postfix) with ESMTP id F23EA11E80D1 for ; Fri, 17 Aug 2012 13:59:34 -0700 (PDT) Received: from nber6 (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.4/8.14.4) with ESMTP id q7HKxT9J090565; Fri, 17 Aug 2012 16:59:30 -0400 (EDT) (envelope-from feenberg@nber.org) Date: Fri, 17 Aug 2012 16:51:14 -0400 (EDT) From: Daniel Feenberg X-X-Sender: feenberg@nber6 To: Anti-Spam Research Group - IRTF In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20120817 #7899949, check: 20120817 clean Subject: Re: [Asrg] How will we manage IPv6 spam? 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, 17 Aug 2012 20:59:35 -0000 On Fri, 17 Aug 2012, John R. Levine wrote: > Hi. Remember the ASRG? I was hoping it might do a little research. > > In talking to people about IPv6 mail, I'm still coming to the conclusion that > anyone who thinks they know how they're going to handle it, beyond the > current toy scale, doesn't understand the problem. Things we might address > include: > I would not expect to accept any IPv6 mail until users come forward to show me that they wish to correspond with MTAs that have no IPv4 connection ability. While this may happen in the fullness of time, I don't expect it soon. Now and for the foreseeable future such a system would have very little connectivity, far less than a blacklisted spam source. I understand that a non-trivial number of MTAs are currently able to use IPv6, but I also understand that all of the ones we wish to correspond with are also capable of using IPv4. Since our anti-spam technology (Spamhaus) is very dependent on IPv4 blacklists, it would be very undesirable to add a general IPv6 port. I would add a handful of IPv6 only sites to a whitelist or subscribe to a responsible whitelist long before attempting to accept messages from unknown IPv6 mtas. We are all familiar with the concept that you "can't enumerate badness". The IPv4 address space is small enough that you actually can, and it has worked very well for us. In IPv6, I don't think it would work at all. dan feenberg NBER > > R's, > John From mike@mtcc.com Fri Aug 17 14:04:34 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 E013C11E80E1 for ; Fri, 17 Aug 2012 14:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.674 X-Spam-Level: X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.075, 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 A1nTHzGEKJMc for ; Fri, 17 Aug 2012 14:04:34 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 583E411E80D1 for ; Fri, 17 Aug 2012 14:04:34 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q7HL4X4a026139 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 17 Aug 2012 14:04:33 -0700 Message-ID: <502EB1E1.6050807@mtcc.com> Date: Fri, 17 Aug 2012 14:04:33 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1193; t=1345237473; x=1346101473; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Asrg]=20How=20will=20we=20manage=20IPv 6=20spam? |Sender:=20 |To:=20Anti-Spam=20Research=20Group=20-=20IRTF=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=VM4i6ZQ74ZcQ6RrOauF3hkhKpx3HaissedKwe3+RhqE=; b=qdtrmnWR2EuGDqGEEbCCY3A+xWwNlbXdWeFYByY6XMxhbDsNekZwa0fWdC NuLquq5lQCG6Z3OsUFcfCwSzvWVCH4P5mq+ef6IT0Kb//+vF2KCi1Ktw9LuQ KPW3tNKDBkL+iZ69tLEZOLX1S1y9/CQjBUZ0tfziiwTO4rU+imM1E=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Cc: Daniel Feenberg Subject: Re: [Asrg] How will we manage IPv6 spam? 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, 17 Aug 2012 21:04:35 -0000 On 08/17/2012 01:51 PM, Daniel Feenberg wrote: > > > On Fri, 17 Aug 2012, John R. Levine wrote: > >> Hi. Remember the ASRG? I was hoping it might do a little research. >> >> In talking to people about IPv6 mail, I'm still coming to the conclusion that anyone who thinks they know how they're going to handle it, beyond the current toy scale, doesn't understand the problem. Things we might address include: >> > > I would not expect to accept any IPv6 mail until users come forward to show me that they wish to correspond with MTAs that have no IPv4 connection ability. While this may happen in the fullness of time, I don't expect it soon. Now and for the foreseeable future such a system would have very little connectivity, far less than a blacklisted spam source. Host operating systems -- all of them to my knowledge -- prefer v6 over v4 if you have a public v6 address. So the mere existence of a AAAA associated with the MX will cause the sender to pick the v6 destination. I have a v6 mail system and got bitten because I had forgot to put up the v6 reverse map. It will happen just as a natural consequence of people enabling v6 on their infrastructure. Mike From feenberg@nber.org Fri Aug 17 14:16:23 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 EF83411E80EF for ; Fri, 17 Aug 2012 14:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hv6UUvI9IJrQ for ; Fri, 17 Aug 2012 14:16:23 -0700 (PDT) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2F67C11E80F0 for ; Fri, 17 Aug 2012 14:16:21 -0700 (PDT) Received: from nber6 (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.4/8.14.4) with ESMTP id q7HLGHbU094936; Fri, 17 Aug 2012 17:16:17 -0400 (EDT) (envelope-from feenberg@nber.org) Date: Fri, 17 Aug 2012 17:08:02 -0400 (EDT) From: Daniel Feenberg X-X-Sender: feenberg@nber6 To: Michael Thomas In-Reply-To: <502EB1E1.6050807@mtcc.com> Message-ID: References: <502EB1E1.6050807@mtcc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20120817 #7899949, check: 20120817 clean Cc: Anti-Spam Research Group - IRTF Subject: Re: [Asrg] How will we manage IPv6 spam? 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, 17 Aug 2012 21:16:24 -0000 On Fri, 17 Aug 2012, Michael Thomas wrote: > On 08/17/2012 01:51 PM, Daniel Feenberg wrote: >> >> >> On Fri, 17 Aug 2012, John R. Levine wrote: >> >>> Hi. Remember the ASRG? I was hoping it might do a little research. >>> >>> In talking to people about IPv6 mail, I'm still coming to the conclusion >>> that anyone who thinks they know how they're going to handle it, beyond >>> the current toy scale, doesn't understand the problem. Things we might >>> address include: >>> >> >> I would not expect to accept any IPv6 mail until users come forward to show >> me that they wish to correspond with MTAs that have no IPv4 connection >> ability. While this may happen in the fullness of time, I don't expect it >> soon. Now and for the foreseeable future such a system would have very >> little connectivity, far less than a blacklisted spam source. > > Host operating systems -- all of them to my knowledge -- prefer v6 over > v4 if you have a public v6 address. So the mere existence of a AAAA > associated with the MX will cause the sender to pick the v6 destination. > I have a v6 mail system and got bitten because I had forgot to put up > the v6 reverse map. It will happen just as a natural consequence of > people enabling v6 on their infrastructure. This sounds inconvenient. If I want to accept mail from one IPv6 host, then all the IPv6 hosts will want to use IPv6, and unless I accept mail from unknown IPv6 hosts, mail from hosts that would have been accepted over IPv4 will be rejected? That is a problem, but I can't imagine IPv6 acceptance being so universal that there would be more desirable mail from IPv6 only hosts than from IPv4 only hosts, at least not for some decades. This is especially true since more important hosts are more likely to have access to IPv4 addresses. I actually wonder if the transition could ever occur as long as IPv4 is supported at all by ISPs. daniel feenberg NBER > > Mike > From prvs=05771215A9=paul@pscs.co.uk Fri Aug 17 17:14: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 30BE621E80A0 for ; Fri, 17 Aug 2012 17:14:10 -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 I21I84s3tC6C for ; Fri, 17 Aug 2012 17:14:09 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) by ietfa.amsl.com (Postfix) with ESMTP id 358AB21E809B for ; Fri, 17 Aug 2012 17:14:07 -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 ; Sat, 18 Aug 2012 01:10:19 +0100 Received: from [192.168.57.46] ([217.155.61.157]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP for ; Sat, 18 Aug 2012 01:02:16 +0100 Message-ID: <502EDB7F.1030506@pscs.co.uk> Date: Sat, 18 Aug 2012 01:02:07 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: asrg@irtf.org References: <502EB1E1.6050807@mtcc.com> 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 V5.0d - Registered X-Organisation: Paul Smith Computer Services Subject: Re: [Asrg] How will we manage IPv6 spam? 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, 18 Aug 2012 00:14:10 -0000 On 17/08/2012 22:08, Daniel Feenberg wrote: > > > On Fri, 17 Aug 2012, Michael Thomas wrote: > >> On 08/17/2012 01:51 PM, Daniel Feenberg wrote: >> >> Host operating systems -- all of them to my knowledge -- prefer v6 >> over v4 if you have a public v6 address. So the mere existence of a >> AAAA associated with the MX will cause the sender to pick the v6 >> destination. I have a v6 mail system and got bitten because I had >> forgot to put up the v6 reverse map. It will happen just as a natural >> consequence of people enabling v6 on their infrastructure. > > This sounds inconvenient. If I want to accept mail from one IPv6 host, > then all the IPv6 hosts will want to use IPv6, and unless I accept > mail from unknown IPv6 hosts, mail from hosts that would have been > accepted over IPv4 will be rejected? This is a fair point. Given that IPv6 is rare at the moment and is really an 'extension' to SMTP anyway, maybe we should be looking at a further extension which allows an SMTP receiver to say 'retry on my IPv4 address' However, it is up to the sending MTA whether it uses an IPv4 or IPv6 address. The 'OS may prefer IPv6', but the MTA could get all the available IP addresses for the MX name, then chooses which to use. If the OS has a 'connect to name' function then it may just connect to the IPv6 address, but if you have to use 'gethostbyname' then 'connect to IP address' functions then you can choose which results of the 'gethostbyname' function to use, and which to ignore, and which order to try them in. That's what ours does, and it can be configured to ignore the IPv6 addresses and just try to connect to the IPv4 ones, or to try IPv4 before IPv6. > This is especially true since more important hosts are more likely to > have access to IPv4 addresses. I actually wonder if the transition > could ever occur as long as IPv4 is supported at all by ISPs. This is a fair point as well, and I do wonder that as well. We added IPv6 support to our MTA as a 'selling point', but I'd generally recommend users not to enable it. I suspect that if IPv6 did become widely used for mail, then we'd have to start moving towards a system of 'trusted MTAs' to try to limit the spam issue. If we're going to do that, then there would be a limited number of those, so why not have those 'trusted hosts' use IPv4? Then any IPv6 SMTP would just be between mutually agreed upon MTAs, with the 'edge' MTA using IPv4 to talk to other 'unknown' MTAs. (hope that makes sense) - Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 From mike@mtcc.com Fri Aug 17 17:21: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 4F99321F846A for ; Fri, 17 Aug 2012 17:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=-0.073, 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 na5tBx99pdWx for ; Fri, 17 Aug 2012 17:21:32 -0700 (PDT) Received: from mtcc.com (mtcc.com [IPv6:2001:5a8:4:9fe0:224:8cff:feaa:6d9b]) by ietfa.amsl.com (Postfix) with ESMTP id 5D77821F8468 for ; Fri, 17 Aug 2012 17:21:32 -0700 (PDT) Received: from takifugu.mtcc.com (takifugu.mtcc.com [50.0.18.224]) (authenticated bits=0) by mtcc.com (8.14.3/8.14.3) with ESMTP id q7I0LUJC027941 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 17 Aug 2012 17:21:30 -0700 Message-ID: <502EE00A.6050501@mtcc.com> Date: Fri, 17 Aug 2012 17:21:30 -0700 From: Michael Thomas User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.8.1.22) Gecko/20090605 Thunderbird/2.0.0.22 Mnenhy/0.7.5.0 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <502EB1E1.6050807@mtcc.com> <502EDB7F.1030506@pscs.co.uk> In-Reply-To: <502EDB7F.1030506@pscs.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1420; t=1345249291; x=1346113291; c=relaxed/simple; s=thundersaddle.kirkwood; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=mtcc.com; i=mike@mtcc.com; z=From:=20Michael=20Thomas=20 |Subject:=20Re=3A=20[Asrg]=20How=20will=20we=20manage=20IPv 6=20spam? |Sender:=20 |To:=20Anti-Spam=20Research=20Group=20-=20IRTF=20 |Content-Type:=20text/plain=3B=20charset=3DISO-8859-1=3B=20 format=3Dflowed |Content-Transfer-Encoding:=207bit |MIME-Version:=201.0; bh=IGCI+O6+B6TU1DqMgmLk6bOm9XYaOGUVsw3GP/JE+ok=; b=D2j9j4yU7CKXI2Ks0BHwVLjQ9tKcQRU1nD6KW1bE80hGFMgwxeNFQFJfX6 v8yx40LyxT7pp7Hyw2r6Tk3zStuWk1EioSP8lw1MncL9BYLHOVOCJ4JWJrrU tfpLDwGbwkb54rZqrSf0Hq+nNSTz13RBIPawVBb0f5vM3PJQUVTVk=; Authentication-Results: ; v=0.1; dkim=pass header.i=mike@mtcc.com ( sig from mtcc.com/thundersaddle.kirkwood verified; ); dkim-asp=pass header.From=mike@mtcc.com Subject: Re: [Asrg] How will we manage IPv6 spam? 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, 18 Aug 2012 00:21:33 -0000 On 08/17/2012 05:02 PM, Paul Smith wrote: > On 17/08/2012 22:08, Daniel Feenberg wrote: >> >> >> On Fri, 17 Aug 2012, Michael Thomas wrote: >> >>> On 08/17/2012 01:51 PM, Daniel Feenberg wrote: >>> >>> Host operating systems -- all of them to my knowledge -- prefer v6 over v4 if you have a public v6 address. So the mere existence of a AAAA associated with the MX will cause the sender to pick the v6 destination. I have a v6 mail system and got bitten because I had forgot to put up the v6 reverse map. It will happen just as a natural consequence of people enabling v6 on their infrastructure. >> >> This sounds inconvenient. If I want to accept mail from one IPv6 host, then all the IPv6 hosts will want to use IPv6, and unless I accept mail from unknown IPv6 hosts, mail from hosts that would have been accepted over IPv4 will be rejected? > This is a fair point. Given that IPv6 is rare at the moment and is really an 'extension' to SMTP anyway, maybe we should be looking at a further extension which allows an SMTP receiver to say 'retry on my IPv4 address' Seriously, let's not go here. Any such extension would be DOA in the IETF anyway. If DNSBL's are the reason you would want to stay in v4 land, I'd suggest the problem is with the way DNSBL's are engineered, not v6. Thislist being an IETF research group should just accept that v6 will arrive and not try to roll back time. Mike From johnl@iecc.com Fri Aug 17 18: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 21CE911E8097 for ; Fri, 17 Aug 2012 18:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.145 X-Spam-Level: X-Spam-Status: No, score=-111.145 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, 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 nolmY8lbKYXd for ; Fri, 17 Aug 2012 18:40:54 -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 F398D11E808E for ; Fri, 17 Aug 2012 18:40:50 -0700 (PDT) Received: (qmail 45715 invoked from network); 18 Aug 2012 01:40:47 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 18 Aug 2012 01:40:47 -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=502ef29f.xn--9vv.k1208; i=johnl@user.iecc.com; bh=dXfJAg/juEnDc2mdHnLZlvvowUmTVGUDbxhHGY47QEs=; b=UYn1ck3IkQ08WkVUvAoHl95YyRUbqj72WgDRwG22/aZVicZpM8eJw+XMdyV4mD4kHB2I7bHnWPSNl9JCJXU6L8yu15ERGV1OIkV7MJsUexCUT9A8FwFD2hml/29+bTK4HkMJkjZPTvi9bdHm6rzyRr7xUVKynnzrXL6rFR6hF4k= 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=502ef29f.xn--9vv.k1208; olt=johnl@user.iecc.com; bh=dXfJAg/juEnDc2mdHnLZlvvowUmTVGUDbxhHGY47QEs=; b=IhTE1lm67L5h+eQpoXRN8d4kp5cJ5ygH5F+mi0X+Dt/1n1IrhCyBh/RsCN9hAhPVvyGGxIcIdC57T+moavO85y3LV9wnecr87kCQdf4o9PRBUU0NIZgDVJRbTM52VFza29L9YR9ZNjW/FDdZ3mee4Zo8vMshcmZs6kXsjm66uxY= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 18 Aug 2012 01:40:25 -0000 Message-ID: <20120818014025.41244.qmail@joyce.lan> From: "John Levine" To: asrg@irtf.org In-Reply-To: <502EB1E1.6050807@mtcc.com> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [Asrg] How will we manage IPv6 spam? 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, 18 Aug 2012 01:40:55 -0000 >> I would not expect to accept any IPv6 mail until users come forward to show me that >they wish to correspond with MTAs that have no IPv4 connection ability. While this may >happen in the fullness of time, I don't expect it soon. Now and for the foreseeable >future such a system would have very little connectivity, far less than a blacklisted >spam source. I agree that it will be a while before there is any worthwhile mail that can't be delivered over IPv4. But Comcast and Gmail already do mail over IPv6, and other big providers are likely to add it this year. If you have any v6 mail connectivity at all, you will start to get real mail over it. So it would be nice, what with the ASRG's charter to do, you know, research, if we started thinking now about how to manage spam over V6 rather than sticking our fingers in our ears. R's, John From feenberg@nber.org Sat Aug 18 03:58:25 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 E3ECB21F84D7 for ; Sat, 18 Aug 2012 03:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 8FxzEwckS+Tj for ; Sat, 18 Aug 2012 03:58:25 -0700 (PDT) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2023C21F84C9 for ; Sat, 18 Aug 2012 03:58:24 -0700 (PDT) Received: from nber6 (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.4/8.14.4) with ESMTP id q7IAwIsT008824; Sat, 18 Aug 2012 06:58:19 -0400 (EDT) (envelope-from feenberg@nber.org) Date: Sat, 18 Aug 2012 06:50:02 -0400 (EDT) From: Daniel Feenberg X-X-Sender: feenberg@nber6 To: Anti-Spam Research Group - IRTF In-Reply-To: <502EE00A.6050501@mtcc.com> Message-ID: References: <502EB1E1.6050807@mtcc.com> <502EDB7F.1030506@pscs.co.uk> <502EE00A.6050501@mtcc.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20120818 #7863439, check: 20120818 clean Subject: Re: [Asrg] How will we manage IPv6 spam? 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, 18 Aug 2012 10:58:26 -0000 On Fri, 17 Aug 2012, Michael Thomas wrote: > On 08/17/2012 05:02 PM, Paul Smith wrote: >> On 17/08/2012 22:08, Daniel Feenberg wrote: >>> >>> >>> On Fri, 17 Aug 2012, Michael Thomas wrote: >>> >>>> On 08/17/2012 01:51 PM, Daniel Feenberg wrote: >>>> >>>> Host operating systems -- all of them to my knowledge -- prefer v6 over >>>> v4 if you have a public v6 address. So the mere existence of a AAAA >>>> associated with the MX will cause the sender to pick the v6 destination. >>>> I have a v6 mail system and got bitten because I had forgot to put up the >>>> v6 reverse map. It will happen just as a natural consequence of people >>>> enabling v6 on their infrastructure. >>> >>> This sounds inconvenient. If I want to accept mail from one IPv6 host, >>> then all the IPv6 hosts will want to use IPv6, and unless I accept mail >>> from unknown IPv6 hosts, mail from hosts that would have been accepted >>> over IPv4 will be rejected? >> This is a fair point. Given that IPv6 is rare at the moment and is really >> an 'extension' to SMTP anyway, maybe we should be looking at a further >> extension which allows an SMTP receiver to say 'retry on my IPv4 address' > > Seriously, let's not go here. Any such extension would be DOA in the IETF > anyway. > > If DNSBL's are the reason you would want to stay in v4 land, I'd suggest > the problem is with the way DNSBL's are engineered, not v6. Thislist being How would you engineer a DNSBL for IPv6? > an IETF research group should just accept that v6 will arrive and not try > to roll back time. The question isn't so much when IPv6 will arrive, there are lots of uses for IPv6, but when IPv4 will depart. And I don't see any incentive for our correspondents to establish IPv6 mtas when IPv4 mtas have much greater acceptability to receivers. That is independent of the DNSBL situation but the lack of an effective DNSBL further encourages mtas not to accept IPv6 messages, a factor which strongly militates against a gradual transition. You could argue that new institutions will not be able to obtain IPv4 addresses, and therefore will be forced to adopt IPv6 for their mta. I expect any significant email source will find an IPv4 address for their mta, even if the rest of their servers are IPv6 only. The transition for other services is much easier, since in other cases offering a dual stack has no downside. It is only in the case of the mta that a dual stack results in a significant lose of service. Therefore, no transition without a flag day, and flag days are very difficult to arrange. Another possibility is that an IPv6 DNSBL could be established, but listing very broad address ranges, such as /32s. I don't know how that would work out, but I would expect a lot of colateral damage from such a broad listing. daniel feenberg > > Mike > _______________________________________________ > Asrg mailing list > Asrg@irtf.org > http://www.irtf.org/mailman/listinfo/asrg > From feenberg@nber.org Sat Aug 18 04:07: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 79CB821F849D for ; Sat, 18 Aug 2012 04:07:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 idvOWfc8yMAE for ; Sat, 18 Aug 2012 04:07:41 -0700 (PDT) Received: from mail2.nber.org (mail2.nber.org [66.251.72.79]) by ietfa.amsl.com (Postfix) with ESMTP id 9E78A21F8498 for ; Sat, 18 Aug 2012 04:07:40 -0700 (PDT) Received: from nber6 (nber6.nber.org [66.251.72.76]) by mail2.nber.org (8.14.4/8.14.4) with ESMTP id q7IB7ai3011304; Sat, 18 Aug 2012 07:07:37 -0400 (EDT) (envelope-from feenberg@nber.org) Date: Sat, 18 Aug 2012 06:59:20 -0400 (EDT) From: Daniel Feenberg X-X-Sender: feenberg@nber6 To: Anti-Spam Research Group - IRTF In-Reply-To: <20120818014025.41244.qmail@joyce.lan> Message-ID: References: <20120818014025.41244.qmail@joyce.lan> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.39/RELEASE, bases: 20120818 #7863439, check: 20120818 clean Subject: Re: [Asrg] How will we manage IPv6 spam? 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, 18 Aug 2012 11:07:41 -0000 On Fri, 18 Aug 2012, John Levine wrote: >>> I would not expect to accept any IPv6 mail until users come forward to show me that >> they wish to correspond with MTAs that have no IPv4 connection ability. While this may >> happen in the fullness of time, I don't expect it soon. Now and for the foreseeable >> future such a system would have very little connectivity, far less than a blacklisted >> spam source. > > I agree that it will be a while before there is any worthwhile mail > that can't be delivered over IPv4. But Comcast and Gmail already do > mail over IPv6, and other big providers are likely to add it this > year. If you have any v6 mail connectivity at all, you will start > to get real mail over it. Yes, but I only have an incentive to have IPv6 mail connectivity if I would otherwise lose email. And I have heard of no sender that doesn't fall back to IPv4. > So it would be nice, what with the ASRG's charter to do, you know, > research, if we started thinking now about how to manage spam over > V6 rather than sticking our fingers in our ears. > It is one thing to say that support for IPv6 is the morally correct action, and another to point out a benefit to the receiver of accepting IPv6 mail, when all of the same mail is available over IPv4. Will it be possible for the IETF to convince major legitimate senders to drop support for IPv4 mail? Would anyone here drop support of IPv4 email for their employer or customer as a matter of principle? daniel feenberg From prvs=057821E733=paul@pscs.co.uk Sun Aug 19 06:00:28 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 1F80B21F8514 for ; Sun, 19 Aug 2012 06:00:28 -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 wBS5llkFDY7b for ; Sun, 19 Aug 2012 06:00:27 -0700 (PDT) Received: from mail.pscs.co.uk (mail.pscs.co.uk [188.65.177.237]) by ietfa.amsl.com (Postfix) with ESMTP id 239B921F850D for ; Sun, 19 Aug 2012 06:00:25 -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 ; Sun, 19 Aug 2012 14:00:22 +0100 Received: from [192.168.57.46] ([217.155.61.157]) by lmail.pscs.co.uk ([192.168.66.70] running VPOP3) with ESMTP for ; Sun, 19 Aug 2012 13:53:53 +0100 Message-ID: <5030E1E0.7050309@pscs.co.uk> Date: Sun, 19 Aug 2012 13:53:52 +0100 From: Paul Smith User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: asrg@irtf.org References: <20120818014025.41244.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 V5.0d - Registered X-Organisation: Paul Smith Computer Services Subject: Re: [Asrg] How will we manage IPv6 spam? 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, 19 Aug 2012 13:00:28 -0000 On 18/08/2012 11:59, Daniel Feenberg wrote: > > > It is one thing to say that support for IPv6 is the morally correct > action, and another to point out a benefit to the receiver of > accepting IPv6 mail, when all of the same mail is available over > IPv4. Will it be possible for the IETF to convince major legitimate > senders to drop support for IPv4 mail? Would anyone here drop support > of IPv4 email for their employer or customer as a matter of > principle? +1 I can't see IPv4 SMTP stopping until IPv4 is obsolete. Even if a business can only get IPv6 addresses for themselves, there will be people offering IPv4 SMTP gateways that they can use, and they'll use those gateways or they'll be cut off from most of the world who will still be using IPv4. So, IPv4 mail is pretty much here to stay for the foreseeable future. So, given that, why would people start accepting IPv6 mail? It may not be the politically correct thing to say, but that's the way it is... However, discussing 'is there a better way of handling spam than RBLs?' is worthwhile with IPv4 regardless of whether IPv6 is in use or not. Personally, I think SMTP as we know it is more likely to be killed off by spam than it is to become reliant on IPv6. My view is that we need to move towards having 'authorised senders', possibly by buying a a certificate (or similar) with a 'CA' checking you're 'suitable' to be sending mail (eg a legitimate company or person), and able to revoke the certificate if you abuse it. Yes, there would be a cost to this (if you want to be able to send mail from your domain - I'm thinking similar costs to, say, a code-signing certificate which has more stringent checks than a website SSL cert), so it wouldn't be popular, but I'm beginning to think that would be one of the only ways which would work and wouldn't be a kludge as RBLs or greylisting etc are. I'd have thought this could be added without that much difficulty by requiring TLS for all public MTA-MTA transactions and starting to do client certificate based authentication (any non TLS or non-certified transactions could be accepted, but treated as suspect and scanned more thoroughly) While SPF and DKIM etc should in theory help, they seem to be unpopular to some people, and while they can be useful in the fight against spam, they aren't actually anti-spam systems themselves. - Paul Smith Computer Services Tel: 01484 855800 Vat No: GB 685 6987 53 From skull@bofhland.org Sun Aug 19 07:13: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 1C08821F851C for ; Sun, 19 Aug 2012 07:13:38 -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 UDoAQeps7x0T for ; Sun, 19 Aug 2012 07:13:37 -0700 (PDT) Received: from mithrandir.bofhland.org (mithrandir.bofhland.org [IPv6:2a02:9a8:94::b]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD7F21F851B for ; Sun, 19 Aug 2012 07:13:36 -0700 (PDT) Received: from enlil.local (baggins.skullkrusher.net [147.123.72.2]) by mithrandir.bofhland.org (Postfix) with ESMTPSA id 9A1186C76E for ; Sun, 19 Aug 2012 16:13:34 +0200 (CEST) Message-ID: <5030F48B.4000601@bofhland.org> Date: Sun, 19 Aug 2012 16:13:31 +0200 From: "Emanuele Balla (aka Skull)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: In-Reply-To: X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] How will we manage IPv6 spam? 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, 19 Aug 2012 14:13:38 -0000 On 8/17/12 10:22 PM, John R. Levine wrote: > Hi. Remember the ASRG? I was hoping it might do a little research. > > In talking to people about IPv6 mail, I'm still coming to the conclusion > that anyone who thinks they know how they're going to handle it, beyond > the current toy scale, doesn't understand the problem. Things we might > address include: > > * Will DNSBLs that work like v4 BLs, with a query per IP, blow out DNS > caches? If so, can this be solved by hacks like partitioned caches that > treat BL traffic separately? Would something like my B-tree hack work > better? If this problem is going to raise, it's going to raise exactly the same way with rDNS as well, so having v6 DNSBLs in place is going to make the problem worse by just a factor related only with the number of DNSBLs in place. 2x? 5x? This is a small factor, compared to the size of the problem itself. FWIW, the DNSBL case can be worked around using 0 as TTL for DNSBLs (directly on the DNSBL side, or on the caching side for resolvers with the ability to do that). This is going to increase the load to DNSBL mirrors, but that would probably be much more easily worked with than the cache blowout problem. Another chance is to move part of the logic into the lookup tool and make it query for the /64 network instead of the full address, and run DNSBLs accordingly. This would significantly reduce the size of the caching problem, but would render listings much less granular and whiltelisting of single hosts basically impossible... > * Is there some reasonable way for networks to publish allocation > granularity, e.g., this range is a /64 per user, that range is > individual hosts? If they can, how useful would it be to running BLs or > otherwise making filtering decisions? I already had the chance to tell you that, but RIPE DB provides an "assignment-size" field with this explicit purpose: inet6num: 2a02:09a8:FF00::/40 netname: SPIN-IT-IPv6-SOHO-Trieste1 descr: IPv6 SOHO residentials country: IT admin-c: AL6557-RIPE tech-c: SPIN3-RIPE mnt-irt: IRT-AS6734 status: AGGREGATED-BY-LIR assignment-size: 56 mnt-by: AS6734-MNT source: RIPE # Filtered IMHO encouraging a similar setup won't hurt. > * Is there a practical way to do hard or soft whitelisting of V6 mail > hosts? (Hard: no body filtering, soft: with body filtering) IMHO no real differences from IPv4 except those already cited above at point 1. > * Should large and small systems use the same filtering techniques? > Large systems have larger mail volume and so can build better models of > incoming traffic, small systems can afford cruder filters like no mail > from Korea IMHO there's no real difference with IPv4 here. Except that large systems will probably rely on local mirrors (and sometimes on technologies that do not involve DNS at all) hence they'll be less impacted by the caching problem: they can run everything with TTL set to 0 without heavily impacting lookup latencies. The same is not necessarily true for small systems. > * Can we build models to predict this stuff now, since under the most > optimistic scenario it'll still be years before the v6 mail volume > approaches v4 mail volume. DUNNO From sm@resistor.net Sun Aug 19 12:55:21 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 32BEA21F859C for ; Sun, 19 Aug 2012 12:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, 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 Vg3PlT-v1jNq for ; Sun, 19 Aug 2012 12:55:20 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 629F621F859B for ; Sun, 19 Aug 2012 12:55:20 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id q7JJtFbd027403 for ; Sun, 19 Aug 2012 12:55:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1345406119; bh=xQ4mZQKjkxfRaTd8HjGmn0/P2zv1iFAJLFSdn+Fnebc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=kPC2SM4BHeF8957HXW8MHyWDupmz13MixXJiHc6zjoU11dtnBPULqFNOfatq6LDJQ yZ1+ZBAqjQm0yAeHs1EkRj/liPPJY9//jreZPbg+jk1nQyxt/x4YliJCCDskPup3YI fciQ/Swl+YZh/CWLxcGB2HxwIvaV4TQ1G++bUgu0= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1345406119; i=@resistor.net; bh=xQ4mZQKjkxfRaTd8HjGmn0/P2zv1iFAJLFSdn+Fnebc=; h=Date:To:From:Subject:In-Reply-To:References:Cc; b=cexNS25mLxUU1EvaRjrVknWFFT8l+3brt14+QPJatKorqxYYHoahzo7uyQaC1Uu8J +HXI2HHbTSIj3lm7oOhqexnezskYgtHc+7Ovdw7Qu7a2qaQ5meyQ3vDlgPbN07vxOk 9fSI8XUnyUUL+PevamCXXS7xZyOg5ikwSPbbpuWo= Message-Id: <6.2.5.6.2.20120819124546.09822d20@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 19 Aug 2012 12:52:03 -0700 To: Anti-Spam Research Group - IRTF From: SM In-Reply-To: References: <20120818014025.41244.qmail@joyce.lan> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [Asrg] How will we manage IPv6 spam? 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, 19 Aug 2012 19:55:21 -0000 At 03:59 18-08-2012, Daniel Feenberg wrote: >It is one thing to say that support for IPv6 is the morally correct >action, and another to point out a benefit to the receiver of >accepting IPv6 mail, when all of the same mail is available over There isn't any morally correct action. >IPv4. Will it be possible for the IETF to convince major legitimate >senders to drop support for IPv4 mail? Would anyone here drop support No. >of IPv4 email for their employer or customer as a matter of >principle? No. The subject line is about how a problem can be tackled. Doing nothing is one of the options. Regards, -sm From johnl@iecc.com Sun Aug 19 16:39:05 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 E42FA21F8567 for ; Sun, 19 Aug 2012 16:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.145 X-Spam-Level: X-Spam-Status: No, score=-111.145 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, 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 btcEDr2YKW1V for ; Sun, 19 Aug 2012 16:39:04 -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 B63D821F8564 for ; Sun, 19 Aug 2012 16:39:02 -0700 (PDT) Received: (qmail 59650 invoked from network); 19 Aug 2012 23:38:58 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 19 Aug 2012 23:38:58 -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=50317912.xn--yuvv84g.k1208; i=johnl@user.iecc.com; bh=MqrU/Lzceiu7kjQU3KyomdhsQ1m6/fIAmBXm76XI0Z4=; b=Rh8rmOCERGJPDxo6uwUWdcFY08v4jmo9eSJNSWJhe6iNNQR8KsPxSA7/YiY5cm8PoFuspBKwstd6JnC65R+FEG64dYOZsLqgroEeBB7LzlvPX7Pnz3dNzn0OjxwA+D24MKDxP8T6o70bC7gpf1YkCPby7EZog9xrWZpolUxgzNQ= 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=50317912.xn--yuvv84g.k1208; olt=johnl@user.iecc.com; bh=MqrU/Lzceiu7kjQU3KyomdhsQ1m6/fIAmBXm76XI0Z4=; b=GeWWPX1ip/15a2KIQtdKAZZdOIAa5xiTHE0nzl0wVmc0qV4WJA0QY0CGFV2hTJaLS96Y7sMURFR013I9jYBLVtJTv+UulzMQ9UwM6FIBseva4s9pdnt26tTfrsRIes0Hp1U0p0SQk32g2Qjxrf5Q5NjtBnGCGSvpx76R8f1LUw8= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 19 Aug 2012 23:38:36 -0000 Message-ID: <20120819233836.95876.qmail@joyce.lan> From: "John Levine" To: asrg@irtf.org In-Reply-To: <5030F48B.4000601@bofhland.org> Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 7bit Subject: Re: [Asrg] rDNS and cache issues, was How will we manage IPv6 spam? 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, 19 Aug 2012 23:39:05 -0000 >If this problem is going to raise, it's going to raise exactly the same >way with rDNS as well, so having v6 DNSBLs in place is going to make the >problem worse by just a factor related only with the number of DNSBLs in >place. 2x? 5x? That's true, but people I've talked to at large mail systems say they're not planning to do rDNS lookups for v6 mail, both because of the cache problems and because they don't think it will catch much spam. >FWIW, the DNSBL case can be worked around using 0 as TTL for DNSBLs >(directly on the DNSBL side, or on the caching side for resolvers with >the ability to do that). That's true, but what would be really nice would be DNSBLs that tried to be smart about TTLs based on the amount of traffic an IP sends. I'd think it should be possible to estimate that pretty well from query logs. >make it query for the /64 network instead of the full address, ... >This would significantly reduce the size of the caching problem, but >would render listings much less granular and whiltelisting of single >hosts basically impossible... I think you'll also find that you're blacklisting whole racks at hosting companies when one customer has an insecure PHP script. >> * Is there some reasonable way for networks to publish allocation >> granularity >I already had the chance to tell you that, but RIPE DB provides an >"assignment-size" field with this explicit purpose: Do you really want people querying that at DNSBL rates? This needs to be at a lower level. >> * Can we build models to predict this stuff now, since under the most >> optimistic scenario it'll still be years before the v6 mail volume >> approaches v4 mail volume. > >DUNNO Hey, I know a research group where we could give it a try. R's, John From skull@bofhland.org Mon Aug 20 02:08:40 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 1811E21F8691 for ; Mon, 20 Aug 2012 02:08:40 -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 JpicmW2Kqz-9 for ; Mon, 20 Aug 2012 02:08:39 -0700 (PDT) Received: from mithrandir.bofhland.org (mithrandir.bofhland.org [IPv6:2a02:9a8:94::b]) by ietfa.amsl.com (Postfix) with ESMTP id 4852121F8690 for ; Mon, 20 Aug 2012 02:08:38 -0700 (PDT) Received: from enlil.local (baggins.skullkrusher.net [147.123.72.2]) by mithrandir.bofhland.org (Postfix) with ESMTPSA id BC4BE6CAE5 for ; Mon, 20 Aug 2012 11:08:35 +0200 (CEST) Message-ID: <5031FE91.9000508@bofhland.org> Date: Mon, 20 Aug 2012 11:08:33 +0200 From: "Emanuele Balla (aka Skull)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: Anti-Spam Research Group - IRTF References: <20120819233836.95876.qmail@joyce.lan> In-Reply-To: <20120819233836.95876.qmail@joyce.lan> X-Enigmail-Version: 1.4.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Asrg] rDNS and cache issues, was How will we manage IPv6 spam? 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, 20 Aug 2012 09:08:40 -0000 On 8/20/12 1:38 AM, John Levine wrote: >> If this problem is going to raise, it's going to raise exactly the same >> way with rDNS as well, so having v6 DNSBLs in place is going to make the >> problem worse by just a factor related only with the number of DNSBLs in >> place. 2x? 5x? > > That's true, but people I've talked to at large mail systems say > they're not planning to do rDNS lookups for v6 mail, both because of > the cache problems and because they don't think it will catch much > spam. Other than the spam problem there are other needs for rDNS lookups, starting from logging... So while I understand the approach (not that I completely agree with it), but I'm not sure it's completely feasible unless we change a lot of things in the way we usually work... > That's true, but what would be really nice would be DNSBLs that tried > to be smart about TTLs based on the amount of traffic an IP sends. > I'd think it should be possible to estimate that pretty well from > query logs. Sure, that could be a way: starting every listing with 0 TTL and increasing it up to a maximum if it's generating an intense mail flow. Doing the opposite, though (lowering the TTL as the mail source "calms down") could be less easy to do: the same presence of caching inhibits the DNSBL from estimating the lookup rate... Note anyway that we're only considering the case of positive DNS answers (or listed entities), but I'd expect that most of the cache blowup problem will be generated by NXDOMAINs, at list at first. We have much less control on that... >> make it query for the /64 network instead of the full address, ... >> This would significantly reduce the size of the caching problem, but >> would render listings much less granular and whiltelisting of single >> hosts basically impossible... > > I think you'll also find that you're blacklisting whole racks at > hosting companies when one customer has an insecure PHP script. Know that, yes... >> I already had the chance to tell you that, but RIPE DB provides an >> "assignment-size" field with this explicit purpose: > > Do you really want people querying that at DNSBL rates? This needs > to be at a lower level. Not suggesting it for end-user lookups. Simply suggesting that if that information is published in whois, it's there for whoever wants to collect it and use it (starting with DNSBLs). BTW, in order to make the same information available and easily queryable from end users, the most obvious place to put it is probably rDNS; but again, you'll have all the caching problems again. >>> * Can we build models to predict this stuff now, since under the most >>> optimistic scenario it'll still be years before the v6 mail volume >>> approaches v4 mail volume. >> >> DUNNO > > Hey, I know a research group where we could give it a try. ;-) From matthias@leisi.net Mon Aug 20 03:07:43 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 0D10121F84FD for ; Mon, 20 Aug 2012 03:07:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[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 hS1ktZER939x for ; Mon, 20 Aug 2012 03:07:42 -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 4218421F8494 for ; Mon, 20 Aug 2012 03:07:42 -0700 (PDT) Received: by obbun3 with SMTP id un3so12693494obb.13 for ; Mon, 20 Aug 2012 03:07:41 -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=9uaSiLdnlrpX+l3GqdAONYAqq31kSYpAiC6VkvTvY/E=; b=G3+RK8DueNNotFHZoVWBx+qKyjqT4WAGdBA2lCgzuSODxXGvuYfl6h2yCp1nc//LlS YZHOR/HAytqlkU71YEPqrS7k3e0+6Ymq3jlILDlk7wUMOhbX6A1j3ELKk2+mDWxdeXiU KvU+rWGLP6kIuy1B5SWDEAYA8/KJ8qHWUKTdSvN1HuBrHC/88D6bJS1yYLoqpJfatNcT gudAstmMwznqADwfrDTmnnELdnf/ZBG7oyIEdHFAQk3Kq/cT1ro7rGqvhtRvO3R+O3AF X56vPvVq+nQ20RB4A70o5qL2d22QvzSR2PFFF6Ge0AiqWrVFffk3C9GB9TXRT+F6kvp/ f2cA== Received: by 10.60.19.34 with SMTP id b2mr9826813oee.41.1345457261726; Mon, 20 Aug 2012 03:07:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.86.41 with HTTP; Mon, 20 Aug 2012 03:07:21 -0700 (PDT) In-Reply-To: <5031FE91.9000508@bofhland.org> References: <20120819233836.95876.qmail@joyce.lan> <5031FE91.9000508@bofhland.org> From: Matthias Leisi Date: Mon, 20 Aug 2012 12:07:21 +0200 Message-ID: To: Anti-Spam Research Group - IRTF Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkTTM1kqp1xQ8xn3T8CH3NF6gw7n1FH8ZzO3YVI46c0AA7ALBV9VYZC4WsQjNPaA58spPhc Subject: Re: [Asrg] rDNS and cache issues, was How will we manage IPv6 spam? 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, 20 Aug 2012 10:07:43 -0000 On Mon, Aug 20, 2012 at 11:08 AM, Emanuele Balla (aka Skull) wrote: > Note anyway that we're only considering the case of positive DNS answers > (or listed entities), but I'd expect that most of the cache blowup > problem will be generated by NXDOMAINs, at list at first. > We have much less control on that... There may be slight differences if we consider the wider case of DNSxLs in general, ie including whitelists which may have different cache characteristics. At dnswl.org, we can generally live with TTLs in the order of magnitude of days (although we make them shorter so that we can remove/change entries reasonably fast). At present, we have ~180k IPs listed (IPv4, there are only a handful of IPv6 addresses which we do not yet publish due to the unclarity about how this should be done). There are potentially another 100k or so IPs which we do not list (yet) for various reasons (time to edit them, questionable source, ...). The data changes very slowly, most often somewhere between 50 and 250 changes per day (including score changes etc, not necessarily removed/added IPs); some exceptional days may have 1'000 or 2'000 changes. As long as operators of "legitimate" sending mail systems do not change the distribution/IP patterns of their mailservers dramatically in an IPv6 world (and there are few reasons why they should do so), there is little impact on DNS infrastructure (auth + cache). For the case of abusive behaviour (ie, spammer using vast pools of IP addresses, eg > 10^3 IP addresses, either snowshoe-like or in cannon style), DNS caches will only blow if receiving systems are "dumb", ie do not handle dDoS-like patterns appropriately. That's already an issue today, and will only be "somewhat worse" in an IPv6 world. -- Matthias From johnl@iecc.com Mon Aug 20 09:51: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 3D0C121F86B7 for ; Mon, 20 Aug 2012 09:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.146 X-Spam-Level: X-Spam-Status: No, score=-111.146 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, 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 dcyaeTjG29rA for ; Mon, 20 Aug 2012 09:51: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 3CF2721F86B4 for ; Mon, 20 Aug 2012 09:51:34 -0700 (PDT) Received: (qmail 27781 invoked from network); 20 Aug 2012 16:51:32 -0000 Received: from leila.iecc.com (64.57.183.34) by mail1.iecc.com with QMQP; 20 Aug 2012 16:51:32 -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=50326b14.xn--yuvv84g.k1208; i=johnl@user.iecc.com; bh=IKjxdFKaO5Ex7G1FVlfa3mIgBxU2D3YTfM4u0dG4nWY=; b=YtwgmkwrV9KqKw1Awl9/v1Gw5fu3ZBKN8nznkuzNNIJ4dsvX0bPfx/bx4Qt5pyE3LK+2Ti+vrb9oNgs4B8HoAf5/sw1lX+0yr7vjsFdRm2m91AiHLH4Nsgrqy7r8LzKYC+UzLMGOq6Y77FW/xAcMWyWDEOufxHl5h+o5Lw4bc7c= 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=50326b14.xn--yuvv84g.k1208; olt=johnl@user.iecc.com; bh=IKjxdFKaO5Ex7G1FVlfa3mIgBxU2D3YTfM4u0dG4nWY=; b=VBbP5HysRyfERQOmiQ5lLDnx+Jy8bHjQbCQokmROR6xzaQ7JMWJdmHuyjkAsGfn8SxBSMcbGfToJ9zdBkLhPqsJpu6Gq+H04JjXT9b+MisCIdmY0SAIs860qmD2d3FRTYWOEWX1CmjMDTmHTLvtN4846fu5I8yDNvXMXcR+ryuE= VBR-Info: md=iecc.com; mc=all; mv=dwl.spamhaus.org Date: 20 Aug 2012 16:51:10 -0000 Message-ID: <20120820165110.78810.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] rDNS and cache issues, was How will we manage IPv6 spam? 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, 20 Aug 2012 16:51:36 -0000 >For the case of abusive behaviour (ie, spammer using vast pools of IP >addresses, eg > 10^3 IP addresses, either snowshoe-like or in cannon >style), DNS caches will only blow if receiving systems are "dumb", ie >do not handle dDoS-like patterns appropriately. That's already an >issue today, and will only be "somewhat worse" in an IPv6 world. How can an MTA tell whether a connection from a hitherto unseen IP is part of a DDoS or a real user sending mail for the first time? R's, John From martijn.grooten@virusbtn.com Thu Aug 23 08:35:08 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 774D721F858E for ; Thu, 23 Aug 2012 08:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 6uQYWkGdBxVj for ; Thu, 23 Aug 2012 08:35:07 -0700 (PDT) Received: from mx4.sophos.com (mx4.sophos.com [216.47.234.213]) by ietfa.amsl.com (Postfix) with ESMTP id BCACC21F8559 for ; Thu, 23 Aug 2012 08:35:06 -0700 (PDT) Received: from mx4.sophos.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 662604E028F for ; Thu, 23 Aug 2012 16:35:05 +0100 (BST) Received: from ABN-EXCH1A.green.sophos (abn-exch1a.green.sophos [10.100.70.61]) by mx4.sophos.com (Postfix) with ESMTPS id E9C664E0279 for ; Thu, 23 Aug 2012 16:35:04 +0100 (BST) Received: from ABN-EXCH1A.green.sophos ([fe80::67:3150:dacd:910d]) by ABN-EXCH1A.green.sophos ([fe80::67:3150:dacd:910d%16]) with mapi id 14.02.0247.003; Thu, 23 Aug 2012 16:35:03 +0100 From: Martijn Grooten To: "asrg@irtf.org" Thread-Topic: VB2012, Dallas, TX, USA Thread-Index: Ac2BQ2enASIH/5hJRneeFCCVRDcFvA== Date: Thu, 23 Aug 2012 15:35:02 +0000 Message-ID: <0D79787962F6AE4B84B2CC41FC957D0B01C70B52@ABN-EXCH1A.green.sophos> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.41.0.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Asrg] CFP: VB2012, Dallas, TX, USA 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, 23 Aug 2012 15:35:08 -0000 Call for last-minute papers for an annual conference about malware, spam an= d bad stuff like that. So if you've done some research into a botnet (taked= own), a recent spam campaign or a new anti-spam tool, this is your chance t= o present it. Deadline is next week. Martijn. With VB2012 in Dallas fast approaching, VB has issued a call for last-minut= e papers. The deadline is one week today (Thursday 30th August). If you have a piece of interesting research to share or have been working on something new and exciting please submit a proposal. (Those selected to present last-minute papers will receive a 50% discount on the conference registration). The selections will be made and speakers notified towards the middle of the week commencing 3rd Sept. Speakers are required to present a 30-minute talk at the conference in Dallas on 27th September. The full details are here: http://www.virusbtn.com/conference/vb2012/call/. ________________________________ Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England. Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.