Re: [Asrg] How will we manage IPv6 spam?

Daniel Feenberg <feenberg@nber.org> Sat, 18 August 2012 10:58 UTC

Return-Path: <feenberg@nber.org>
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 <asrg@ietfa.amsl.com>; 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 <asrg@ietfa.amsl.com>; 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 <asrg@irtf.org>; 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 <feenberg@nber.org>
X-X-Sender: feenberg@nber6
To: Anti-Spam Research Group - IRTF <asrg@irtf.org>
In-Reply-To: <502EE00A.6050501@mtcc.com>
Message-ID: <Pine.GSO.4.64.1208180636520.12975@nber6>
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> <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 <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 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
>