Re: [Asrg] DNSBL and IPv6

Paul Smith <paul@pscs.co.uk> Thu, 25 October 2012 15:50 UTC

Return-Path: <prvs=0645E458C4=paul@pscs.co.uk>
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 <asrg@ietfa.amsl.com>; 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 <asrg@ietfa.amsl.com>; 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 <asrg@irtf.org>; 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 <paul@pscs.co.uk>
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 <asrg@irtf.org>
References: <20121025024859.3176.qmail@joyce.lan> <A6AF6224-421E-4483-834B-A1F658BEC7C6@blighty.com> <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 <asrg@irtf.org>
List-Id: Anti-Spam Research Group - IRTF <asrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/asrg>, <mailto:asrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/asrg>
List-Post: <mailto:asrg@irtf.org>
List-Help: <mailto:asrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/asrg>, <mailto:asrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: 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