Re: [Asrg] How will we manage IPv6 spam?
Paul Smith <paul@pscs.co.uk> Sat, 18 August 2012 00:14 UTC
Return-Path: <prvs=05771215A9=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 30BE621E80A0 for <asrg@ietfa.amsl.com>;
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
<asrg@ietfa.amsl.com>; 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 <asrg@irtf.org>;
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 <asrg@irtf.org>;
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 <asrg@irtf.org>;
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 <paul@pscs.co.uk>
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: <alpine.BSF.2.00.1208171554300.31068@joyce.lan>
<Pine.GSO.4.64.1208171642250.8836@nber6> <502EB1E1.6050807@mtcc.com>
<Pine.GSO.4.64.1208171702000.8836@nber6>
In-Reply-To: <Pine.GSO.4.64.1208171702000.8836@nber6>
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 <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: 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
- [Asrg] How will we manage IPv6 spam? John R. Levine
- Re: [Asrg] How will we manage IPv6 spam? Daniel Feenberg
- Re: [Asrg] How will we manage IPv6 spam? Michael Thomas
- Re: [Asrg] How will we manage IPv6 spam? Daniel Feenberg
- Re: [Asrg] How will we manage IPv6 spam? Paul Smith
- Re: [Asrg] How will we manage IPv6 spam? Michael Thomas
- Re: [Asrg] How will we manage IPv6 spam? John Levine
- Re: [Asrg] How will we manage IPv6 spam? Daniel Feenberg
- Re: [Asrg] How will we manage IPv6 spam? Daniel Feenberg
- Re: [Asrg] How will we manage IPv6 spam? Paul Smith
- Re: [Asrg] How will we manage IPv6 spam? Emanuele Balla (aka Skull)
- Re: [Asrg] How will we manage IPv6 spam? SM
- Re: [Asrg] rDNS and cache issues, was How will we… John Levine
- Re: [Asrg] rDNS and cache issues, was How will we… Emanuele Balla (aka Skull)
- Re: [Asrg] rDNS and cache issues, was How will we… Matthias Leisi
- Re: [Asrg] rDNS and cache issues, was How will we… John Levine