Subject: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities

From: "O'Reirdan, Michael" <[email-masked]>
Date: Thu, 21 Jul 2011 18:21:53 +0000

Chaps

I would like to bring to your attention and solicit comments on the following draft.

http://tools.ietf.org/html//draft-oreirdan-rosenwald-ipv6mail-transition-00

Thanks

Mike O'Reirdan

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 21 Jul 2011 19:50:15 +0000

Thanks for submitting the –00, Mike. A few notes for reviewers:
- This is a very early first draft (and is from some folks new to the IETF), so be gentle and give lots of good feedback
- It seems we need to sort out the appearance of some RFC 2119 language in here and whether it may be better to be less focused on 'recommendations for…' and more 'suggested phases of the transition of mail services to IPv6' (a slight tonal shift)

I also suggest that the dates don't apply, since every mail provider is at a different stage of readiness. As a result, sections 5, 6, and 7 probably should not have dates and may instead be Phase 1, 2 and 3 or something like that.

Jason

On 7/21/11 2:21 PM, "O'Reirdan, Michael" <[email-masked]<mailto:[email-masked]>> wrote:

Chaps

Thanks

Mike O'Reirdan

_______________________________________________ v6ops mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Roger Jørgensen <[email-masked]>
Date: Thu, 21 Jul 2011 22:18:11 +0200

On Thu, Jul 21, 2011 at 9:50 PM, Livingood, Jason
<[email-masked]> wrote:
<snip>
> I also suggest that the dates don't apply, since every mail provider is at a
> different stage of readiness. As a result, sections 5, 6, and 7 probably
> should not have dates and may instead be Phase 1, 2 and 3 or something like
> that.

Just a first impression, good idea and the drafts will be useful as a background
document for education of IPv6 at work :-)

And about the dates, they are actual quite useful since they give an idea about
the scale of the task at hand.

But if they are replaced by phase 1 and up, then maybe add a line
about suggested
time frame for the total transition, and for each phase?

-- 

Roger Jorgensen           |
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Jul 2011 15:48:44 +0200

Hi,

> I also suggest that the dates don't apply, since every mail provider is at a different stage of readiness. As a result, sections 5, 6, and 7 probably should not have dates and may instead be Phase…

I think that the dates in there are actually the main contribution of
that draft.  Create the necessary push for those that still have no
IPv6 on their mail systems to do it in a *timely* way.

Gert Doering
        -- running an IPv6-enabled MTA since about 10 years or so
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jul 2011 09:59:35 -0400

> IPv6 on their mail systems to do it in a *timely* way.

I think the dates in the draft are completely disconnected from reality.

Keith

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Jul 2011 16:17:26 +0200

Hi,

> I think the dates in the draft are completely disconnected from reality.

Indeed, given that IPv6 testing should have been done long ago, and
we should already be well into Phase 2.

Gert Doering
        -- NetMaster

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jul 2011 10:33:30 -0400

> we should already be well into Phase 2.

but of course, we're years away from being able to do that on any kind of widespread scale, due to lack of deployment of native v6, and lack of an efficient and generally-applicable transition mechanism.

Keith

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Jul 2011 16:48:43 +0200

Hi,

On Fri, Jul 22, 2011 at 10:33:30AM -0400, Keith Moore wrote:
> but of course, we're years away from being able to do that on any kind 
> of widespread scale, due to lack of deployment of native v6, and lack 
> of an efficient and generally-applicable transition mechanism.

You're certainly living in a different reality than I am :-)

Recent studies show that about 50% of the ISPs connected to the 3 largest
exchange points in Europe already have native IPv6.  Many of them not
"all the way to the end customers", but sufficient to enable IPv6 to
mail servers.

My private MX has had (native!) IPv6 since about 10 years, and our
corporate MX got native IPv6 a few months ago (due to antispam-vendor 
challenges, not due to lack of support in the network or the MTA itself).

Many of the mailing lists that I read are transported over IPv6 since
years (like cisco-nsp, or v6ops).

Recently, a few of the largest e-mail service providers in germany,
t-online.de and Strato turned on IPv6 on their MXes (Strato for all
their "entry level webspace + mail" shared platform customers, which
according to their press release hosts ~4 million different customer
domains)...

Gert Doering
        -- NetMaster

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jul 2011 11:01:19 -0400

> "all the way to the end customers", but sufficient to enable IPv6 to

Only for the ISPs' mail servers.   Not for their customers' mail servers.  It's the "all the way to end customers" bit that matters, and universal availability there is years away.

> challenges, not due to lack of support in the network or the MTA itself).

I congratulate you.  But neither that nor the other examples you cited are a good indication of what's available to everyone.

Keith

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Jul 2011 17:20:52 +0200

Hi,

On Fri, Jul 22, 2011 at 11:01:19AM -0400, Keith Moore wrote:
> Only for the ISPs' mail servers.   Not for their customers' mail servers.  

Our customers' mail servers are in our hosting facility, and can have 
native IPv6 just fine.

> It's the "all the way to end customers" bit that matters, and 
> universal availability there is years away.

You don't need universal availability on the last DSL line to have
IPv6 *on servers*.  Which are usually not located behind consumer
products.

IPv6 on business links is available today.

> I congratulate you.  But neither that nor the other examples you cited 
> are a good indication of what's available to everyone.

Everyone can have a web + e-mail presence at strato.de - with nice
anti-spam filtering, and IPv6.  Their service offering is very explicitely
targeting "everyone"...

But as I said, I live in a reality where (native!) IPv6 has arrived years 
ago, and I like that place.

Gert Doering
        -- NetMaster

---

From: Philip Homburg <[email-masked]>
Date: Fri, 22 Jul 2011 17:34:26 +0200

In your letter dated Fri, 22 Jul 2011 11:01:19 -0400 you wrote:
>Only for the ISPs' mail servers.   Not for their customers' mail servers.  It'
>s the "all the way to end customers" bit that matters, and universal availabil
>ity there is years away.

I don't see why it's the 'all the way to end customers' bit that matters. 
Huge amounts of e-mail go to and from big players. 

And as always, most of them don't do anything.

For websites, individual users have to have IPv6 otherwise they can reach
content over IPv6. And latency is important.

For mail, in most cases there are ISP (or other) operated mail servers
involved.

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 22 Jul 2011 08:40:51 -0700

On Jul 22, 2011 6:49 AM, "Gert Doering" <[email-masked]> wrote:
> > I also suggest that the dates don't apply, since every mail provider is
at a different stage of readiness. As a result, sections 5, 6, and 7
probably should not have dates and may instead be Phase 1, 2 and 3 or
something like that.
> IPv6 on their mail systems to do it in a *timely* way.

+1 for the dates being good as well.

Like w6d, I really believe it helps having meaningful dates for
organizations to work towards.

Cb

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 22 Jul 2011 16:40:57 +0100

On 22/07/2011 15:33, Keith Moore wrote:
> [...] lack of an efficient and generally-applicable transition
> mechanism.

It's probably my operator-tinted spectacles acting up, but I don't see what
transition mechanisms have to do with this draft.  Email servers generally
reside on provider-controlled infrastructure, which (in the scale of
things) is relatively simple to get up and running on IPv6.  Ok, if you're
a Comcast or a Google, it's going to be hard - like any other transition to
a new class of service.  But most providers don't operate at that scale and
can implement this sort of thing relatively easily, and certainly within
the very conservative timescales indicated.

It's the last mile which is the problem, and email service infrastructure
tends not to be hosted on the last mile these days.  If you're on a
last-mile connection, all that's necessary is to ensure that there is a
good failover mechanism between your MUA and the MTA/MSA - and this is
something which already works reasonably well.  But that is out of scope
for this draft.  If you're hosting infrastructure on the last mile, then
you deserve what you get.

I'm sure you can still pull out corner cases where ipv6 transport to
provider networks is difficult.  But for the majority of provider networks,
getting IPv6 into the core infrastructure is not hard.

Nick

---

From: Fred Baker <[email-masked]>
Date: Fri, 22 Jul 2011 08:59:27 -0700

On Jul 22, 2011, at 8:20 AM, Gert Doering wrote:

> You don't need universal availability on the last DSL line to have IPv6 *on servers*. 

and by the way, the entire series of MUA/MTA and MTA/MTA links don't have to have IPv6 for it to be used on some of them. If one end user is IPv6-only, the other is IPv4-only, and at least one MTA in between is dual, nobody should notice an issue.

My initial comment to Michael, when he pointed the draft out to me, was that email seems like the poster child of an easy application to add IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support it already and the current OS's support IPv6. The primary thing preventing mail/IPv6 is network IPv6 deployment, which is in progress.

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Jul 2011 18:35:44 +0200

Hi,

On Fri, Jul 22, 2011 at 08:59:27AM -0700, Fred Baker wrote:
> My initial comment to Michael, when he pointed the draft out to me, was 
> that email seems like the poster child of an easy application to add IPv6 
> to, as the applications (SMTP, POP, and IMAP) mostly support it already 
> and the current OS's support IPv6. 

Seconded.  Plus, if mail gets delayed by a few minutes due to IPv6 breakage,
it helps *noticing* problems without impacting user experience in a very
massive way (like for IPv6 HTTP running into timeouts).

> The primary thing preventing mail/IPv6 is network IPv6 deployment, which 
> is in progress.

Yes.  And mail/IPv6 can help network IPv6 deployment by showing folks
that there indeed is IPv6 packets to be seen, monitored, and cared for :-)

Gert Doering
        -- NetMaster

---

From: "George, Wesley" <[email-masked]>
Date: Fri, 22 Jul 2011 12:55:14 -0400

While I agree that there are some things that need to be addressed when considering use of IPv6 transport for email, I think that there's probably two drafts necessary here.
One would be focused exclusively on IPv6 transition for email, including timeframes/phases as appropriate and some BCP for enabling IPv6 on mail servers,  both for server to server and server to client communication, including issues and considerations not directly related to abuse. The other would be focused on abuse considerations for using IPv6 for mail.

The reason that I think we need a separate draft on abuse considerations is that I think it will be significant all by itself, it will likely have a different group of folks both interested in working on it and as an audience, and there's a timing consideration.
What I mean by timing is that a draft that serves as a call to arms to enable IPv6 on mail servers and gives recommendations and considerations on how to do so is widely applicable, and many folks can benefit from that immediately, especially if they are not as concerned about the impacts of spam when enabling IPv6. So we'd do well to rapidly get it to a state where it's useful to folks considering their IPv6 deployment steps. Then, this gives us the opportunity to really consider the abuse problems and identify some gaps that we need IETF to come up with better solutions for, as you allude to in your current security considerations text. In other words, we need a thorough gap analysis on mail Abuse with a specific focus on IPv6 so that we can identify what can be done today, as well as work that needs to be farmed out to either existing WGs or possibly even a new WG dedicated to protocol changes necessary to solve the identified problems. It should probably have significant input from MAAWG, since they probably know a thing or two about this ;-)

Regarding the current draft section 11, I realize that this is an early draft, but I think that you need a significant amount of explanation/justification/rationale to support those recommendations if indeed they are to become requirements (even if requirements in a BCP/Informational draft are a little more like suggestions anyway). Based on feedback I've gotten from some of our mail/systems folks, expecting to require DKIM across the board is not realistic due to the costs to implement it at scale. I view whitelists as problematic to scale unless you're talking about a very small number of servers that you exchange email with, or you are proposing some sort of semi-automated whitelist that is updated like todays spam blacklists. Perhaps it's just unclear where you're suggesting that they be used, and if so I'll wait for a revision before saying much else.

Thanks,

Wes George

From: [email-masked] [mailto:[email-masked]] On Behalf Of Livingood, Jason
Sent: Thursday, July 21, 2011 3:50 PM
To: O'Reirdan, Michael; [email-masked]
Cc: John R. Levine; Joe St Sauveur; Dave Crocker
Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities

Thanks for submitting the -00, Mike. A few notes for reviewers:
- This is a very early first draft (and is from some folks new to the IETF), so be gentle and give lots of good feedback
- It seems we need to sort out the appearance of some RFC 2119 language in here and whether it may be better to be less focused on 'recommendations for...' and more 'suggested phases of the transition of mail services to IPv6' (a slight tonal shift)

Jason

Chaps

http://tools.ietf.org/html//draft-oreirdan-rosenwald-ipv6mail-transition-00<http://tools.ietf.org/html/draft-oreirdan-rosenwald-ipv6mail-transition-00>

Thanks

Mike O'Reirdan

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jul 2011 13:27:40 -0400

> IPv6 *on servers*.  Which are usually not located behind consumer

This might be true for your customers.  But it's not an appropriate assumption to make for all mail servers on the Internet.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jul 2011 13:28:53 -0400

> Huge amounts of e-mail go to and from big players. 

If the document wants to make clear that it only applies to "big players", that might be okay.  Though I worry about recommendations coming from IETF that threaten to further marginalize small players.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jul 2011 13:32:59 -0400

> My initial comment to Michael, when he pointed the draft out to me, was that email seems like the poster child of an easy application to add IPv6 to, as the applications (SMTP, POP, and IMAP) mostl…

I guess my view is sort of the opposite - there's really little point to upgrading mail to use IPv6 until most of the net has IPv6 access.

Of course it's a good idea for operators to gain experience with use of SMTP over IPv6, and ramp up usage of it, especially because things like source-address based reputation services are going to have to work differently.  But that's not the same thing as universally rolling it out on a fixed timetable.

I'm not sure how much value there is in having a "poster child" for IPv6, as opposed to actual use of IPv6 to do things that you can't really do well in IPv4.    Maybe it matters.  But that's a marketing question, and I'm an engineer.

Keith

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Jul 2011 11:39:02 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Gert Doering
> Sent: Friday, July 22, 2011 9:36 AM
> To: Fred Baker
> Cc: Joe St Sauveur; [email-masked]; Keith Moore; Dave Crocker; John R. Levine
> > My initial comment to Michael, when he pointed the draft out to me,
> > was that email seems like the poster child of an easy application to
> > add IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support
> > it already and the current OS's support IPv6.
> 
> Seconded.  Plus, if mail gets delayed by a few minutes due to IPv6
> breakage, it helps *noticing* problems without impacting user
> experience in a very massive way (like for IPv6 HTTP running into
> timeouts).

Since the word "applications" appeared twice in there, I wonder if this might be better suited to be developed inside APPSAWG instead of, or perhaps in conjunction with, V6OPS.

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jul 2011 15:25:15 -0400

> Since the word "applications" appeared twice in there, I wonder if this might be better suited to be developed inside APPSAWG instead of, or perhaps in conjunction with, V6OPS.

My suggestion to the authors was that they run it by [email-masked], which is the old IETF smtpext WG mailing list.

Keith

---

From: Gert Doering <[email-masked]>
Date: Fri, 22 Jul 2011 23:15:46 +0200

Hi,

> This might be true for your customers.  But it's not an appropriate assumption to make for all mail servers on the Internet.

Neither is your assumption that there is no IPv6.  So what?

Gert Doering
        -- NetMaster

---

From: "John R. Levine" <[email-masked]>
Date: 22 Jul 2011 23:48:28 +0200

> My initial comment to Michael, when he pointed the draft out to me, was that email seems like the poster child of an easy application to add IPv6 to, as the applications (SMTP, POP, and IMAP) mostl…

Setting up an IPv6 mail server is easy.  The problem is that the vast 
majority of incoming mail is hostile, and IPv4 mail filtering techniques 
don't migrate well to IPv6.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Jul 2011 14:57:48 -0700

Sure, though any transition will involve things outside of SMTP's scope as well.

From: Keith Moore [mailto:[email-masked]]
Sent: Friday, July 22, 2011 12:25 PM
To: Murray S. Kucherawy
Cc: Gert Doering; Fred Baker; Joe St Sauveur; [email-masked]; Dave Crocker; John R. Levine
Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Gert Doering
Sent: Friday, July 22, 2011 9:36 AM
To: Fred Baker
Cc: Joe St Sauveur; [email-masked]<mailto:[email-masked]>; Keith Moore; Dave Crocker; John R. Levine
Subject: Re: [v6ops] Draft on email transition to IPv6 from IPv4 for sevice providers and other communities

My suggestion to the authors was that they run it by [email-masked]<mailto:[email-masked]>, which is the old IETF smtpext WG mailing list.

Keith

---

From: Bob Van Zant <[email-masked]>
Date: Fri, 22 Jul 2011 15:01:29 -0700

On Fri, Jul 22, 2011 at 2:48 PM, John R. Levine <[email-masked]> wrote:
> The problem is that the vast majority of incoming mail is hostile, and
> IPv4 mail filtering techniques don't migrate well to IPv6.

This statement simply doesn't hold true for IPv6 email. Gert's saying
it. I'm saying it. Someone else on this thread said it. We're all
speaking from experience.

We sit on this list and occasionally criticize the networking gear
vendors for dragging their feet (and we should). Who's dragging their
feet now?

-Bob

---

From: Olivier MJ Crepin-Leblond <[email-masked]>
Date: Sat, 23 Jul 2011 00:06:20 +0200

On 22/07/2011 23:48, John R. Levine wrote :
>> it already and the current OS's support IPv6. The primary thing
>> preventing mail/IPv6 is network IPv6 deployment, which is in progress.
>
> majority of incoming mail is hostile, and IPv4 mail filtering
> techniques don't migrate well to IPv6.
>

I keep on hearing here that people don't run IPv6 on their mailers
because of spam coming over IPv6.

Does anyone actually have real figures from their gateways for:
1. the percentage of spam using IPv6 vs. IPv4
2. the percentage of spam in their mail incoming via IPv6

Thanks,

Olivier

-- 
Olivier MJ Crépin-Leblond, PhD
http://www.gih.com/ocl.html

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Fri, 22 Jul 2011 18:27:13 -0400 (EDT)

On Fri, 22 Jul 2011, John R. Levine wrote:

>> to, as the applications (SMTP, POP, and IMAP) mostly support it already and 
>> the current OS's support IPv6. The primary thing preventing mail/IPv6 is 
>> network IPv6 deployment, which is in progress.
>

What I've done in the past is have a dual-stack exchanger receive email 
from anywhere, then funnel that to an IPv4 mail server to do the work of
filtering.  Yes, that may seem to be blasphemy, but it worked at that time 
despite the hoops I had to jump through.

wfms

---

From: "John R. Levine" <[email-masked]>
Date: 23 Jul 2011 00:18:56 +0200

> speaking from experience.

I'm also speaking from experience.

The current amount of IPv6 mail is a tiny trickle compared to IPv4 mail. 
Any half assed approach will work for a trickle, but that says nothing 
about how it would work for real production mail.

> vendors for dragging their feet (and we should). Who's dragging their

Nobody.  As I've said several times, if you're saying that managing IPv6 
mail is easy, you've self-identified as not understanding the problem.

R's,
John

---

From: "John R. Levine" <[email-masked]>
Date: 23 Jul 2011 00:20:17 +0200

> 2. the percentage of spam in their mail incoming via IPv6

On my system, both of those numbers are close enough to zero as not to 
matter. I get so little spam over v6 that I can look at each one 
individually.

Regards,

---

From: Bob Van Zant <[email-masked]>
Date: Fri, 22 Jul 2011 15:31:06 -0700

On Fri, Jul 22, 2011 at 3:18 PM, John R. Levine <[email-masked]> wrote:
> The current amount of IPv6 mail is a tiny trickle compared to IPv4 mail. Any
> half assed approach will work for a trickle, but that says nothing about how
> it would work for real production mail.

Why would you waste time solving a problem you don't have? We all want
to solve the IPv6 spam problem. What IPv6 spam problem? We want to
create IPv6 blacklists in the context of email. Why? Who would you put
on that blacklist?

A company I used to work for told customers that we had a chicken and
egg problem here. Without seeing real IPv6 email we can't tell you who
the bad guys are. Without knowing who the bad guys are we can't give
you an IPv6 email solution that is on par with our IPv4 offerings.

> mail is easy, you've self-identified as not understanding the problem.

What problem? I've read about a lot of problems that people are
predicting we'll eventually have. Is there a real IPv6 mail problem
*today*?

---

From: "John R. Levine" <[email-masked]>
Date: 23 Jul 2011 00:32:10 +0200

> What I've done in the past is have a dual-stack exchanger receive email from 
> anywhere, then funnel that to an IPv4 mail server to do the work of

That's what I do, too, but the DNSBLs that catch 90% of the v4 spam don't 
do anything when mail is coming from the v4 address of my v6 gateway.

For the umpteenth time, the current trickle of v6 mail tells us nothing 
useful about what we'll need to do to handle v6 mail at the scale we're 
handling v4 mail.

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 23 Jul 2011 00:35:45 +0200

> create IPv6 blacklists in the context of email. Why? Who would you put

Sorry, I have no idea what your point is.

If you're saying that moving mail to v6 is so hard that it will all stay 
on v4, I wouldn't disagree with you, but that does run counter to IETF 
dogma.

> you an IPv6 email solution that is on par with our IPv4 offerings.

Right.  So it appears that you are proposing to set up IPv6 mail servers 
that will fall over and die if the bad guys ever point their botnets at 
IPv6 addresses.  That seems, ah, short sighted.

Regards,

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Jul 2011 23:03:46 +0000

On Jul 22, 2011, at 6:32 PM, John R. Levine wrote:
That's what I do, too, but the DNSBLs that catch 90% of the v4 spam don't do anything when mail is coming from the v4 address of my v6 gateway.

How would that ever happen?   If the SMTP connection is to your SMTP server, which has an IPv6 address, it will be an IPv6 connection, not an IPv4 connection.   If your gateway is doing protocol translation, and your SMTP server doesn't have an IPv6 address, that's out of scope—we're talking about v6 connections here, not protocol translators.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Jul 2011 23:05:53 +0000

On Jul 22, 2011, at 6:35 PM, John R. Levine wrote:
Right.  So it appears that you are proposing to set up IPv6 mail servers that will fall over and die if the bad guys ever point their botnets at IPv6 addresses.  That seems, ah, short sighted.

The problem with spam is not that your SMTP server falls over and dies.   It's that you have to filter through a bunch of crap.   If someone wants to point their botnet at you, it's going to suck, and no RBL in the world is going to make it not suck.

---

From: Bob Van Zant <[email-masked]>
Date: Fri, 22 Jul 2011 16:06:26 -0700

> Sorry, I have no idea what your point is.

You're yapping to this list that IPv6 email is so hard. You're calling
people naive if they don't agree with you (I think there's a word for
this). My point is that there is no IPv6 email abuse problem right now
and people should quit saying that a lack of an IPv6 blacklist or
reputation system is a legitimate reason to avoid deploying SMTP over
IPv6.

> that will fall over and die if the bad guys ever point their botnets at IPv6
> addresses.  That seems, ah, short sighted.

You're not being helpful. Why don't you just sit quietly on the
sidelines until the rest of us make SMTP over IPv6 safe enough for
you.

---

From: Bob Van Zant <[email-masked]>
Date: Fri, 22 Jul 2011 16:08:51 -0700

On Fri, Jul 22, 2011 at 4:05 PM, Ted Lemon <[email-masked]> wrote:
> The problem with spam is not that your SMTP server falls over and dies.
> It's that you have to filter through a bunch of crap.   If someone wants to
> point their botnet at you, it's going to suck, and no RBL in the world is
> going to make it not suck.
>

A big botnet with clean IPs directed straight at a single domain can
impose a world of hurt. This is the problem that John is trying to
scare us all with. The great news for all of us today is that there's
no such thing as an IPv6 botnet.

Though, any mail system worth its weight can do IP-based throttling;
even for IPv6.

---

From: "David Prall" <[email-masked]>
Date: Fri, 22 Jul 2011 19:17:22 -0400

> From: Olivier MJ Crepin-Leblond
>

My dual-stack Ironport at home doesn't send out reports detailing what was
received via IPv4 or IPv6, although it does tell me daily what happened,
yesterday 12,345 (96.9%) messages received were stopped by reputation
filter, 88 (0.7%) were spam, 299 (2.3%) were clean. I'm hoping that the 88
messages that were determined to be spam locally are helping to build an
IPv6 reputation database. Nope all the spam via IPv4. 

I've seen a number of discussions about DNSBL's for IPv6. Do we start with a
single address, add a second, then ramp up to a /64, then to a /48. We'll
probably break a few things, just as what has happened along the way with
IPv4 and spam.

David

--
http://dcp.dcptech.com

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jul 2011 19:17:43 -0400

> Neither is your assumption that there is no IPv6.  So what?

I haven't made any such assumption.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 22 Jul 2011 19:24:34 -0400

> speaking from experience.

It's not true for IPv6 email _now_.  But as soon as major providers start accepting mail via IPv6 SMTP, it's fairly predictable that spammers will start sending spam than way.  Then what?

IPv6 and IPv4 are different enough that it's a bit difficult to anticipate which source-address-based countermeasures will be effective in IPv6.  So it seems a bit silly to say that countermeasure X must be in place before anyone should accept IPv6 SMTP mail.  Of course, countermeasures based on content analysis should work about as well for IPv6 as IPv4.

Maybe that's all that can reasonably be said about the subject at the moment.

Keith

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Fri, 22 Jul 2011 19:27:00 -0400 (EDT)

On Fri, 23 Jul 2011, John R. Levine wrote:

> That's what I do, too, but the DNSBLs that catch 90% of the v4 spam don't do 
> anything when mail is coming from the v4 address of my v6 gateway.

I still have fond (yes, fond!) memories of getting my very first spam 
through a mail server in Germany that was dual-stacked onto my own 
workstation.  That was in 2002.  I proudly showed my boss that IPv6 does 
indeed work. :-)

> useful about what we'll need to do to handle v6 mail at the scale we're 

Right.

wfms

---

From: Sander Steffann <[email-masked]>
Date: Sat, 23 Jul 2011 01:50:07 +0200

Hi,

> 2. the percentage of spam in their mail incoming via IPv6

Some numbers from a tiny mail server:
- Total number of incoming messages: 23425
  - Over IPv4: 23229
    - After blacklists: 7752
      - Spam: 928
  - Over IPv6: 192
    - Spam: 3

70.6% of incoming IPv4 mail was spam.
1.6% of incoming IPv6 mail was spam.

These numbers are so small that statistically they are not reliable, but they might give an indication…
Sander

---

From: Ted Lemon <[email-masked]>
Date: Sat, 23 Jul 2011 00:08:10 +0000

On Jul 22, 2011, at 7:27 PM, William F. Maton Sotomayor wrote:
> I still have fond (yes, fond!) memories of getting my very first spam through a mail server in Germany that was dual-stacked onto my own workstation.  That was in 2002.  I proudly showed my boss that IPv6 does indeed work. :-)

I bet it came through an open relay.

:)

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 22 Jul 2011 17:09:54 -0700

Ipv6 dnsbl do exist http://virbl.bit.nl

More to come in the future I am sure.

---

From: "John R. Levine" <[email-masked]>
Date: 23 Jul 2011 07:49:16 +0200

> The problem with spam is not that your SMTP server falls over and dies.   It's that you have to filter through a bunch of crap.   If someone wants to point their botnet at you, it's going to suck,…

I gather that you don't know anyone whose mail servers get a billion 
connections per day, over 90% of which is spam.  I do.

It's hard to avoid the impression that few people in this discussion are 
familiar with the operation of large mail systems.  If your system gets 
100K connections per day, any half-assed design will do.  If it gets 100M 
connections per day, you have to know what you're doing.

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 23 Jul 2011 07:50:18 +0200

Ah, I see this isn't the discussion we thought we were having.

Regards,

---

From: "John R. Levine" <[email-masked]>
Date: 23 Jul 2011 07:52:44 +0200

> Though, any mail system worth its weight can do IP-based throttling;

Big botnets don't send a million spams from each of a thousand IPs, they 
send a dozen spams from each of a million IPs.  IP based throttling is 
mostly useful to choke back over-eager ESPs, who are not a big volume 
problem in the first place.

I'm sorry if I hurt your feelings when I say that you don't understand the 
issues of large mail systems, but it's painfully obvious.

Regards,

---

From: "t.petch" <[email-masked]>
Date: Sat, 23 Jul 2011 12:24:43 +0200

----- Original Message -----
From: "Fred Baker" <[email-masked]>
To: "Gert Doering" <[email-masked]>
Cc: "John R. Levine" <[email-masked]>; "Joe St Sauveur"
<[email-masked]>; <[email-masked]>; "Keith Moore"
<[email-masked]>; "Dave Crocker" <[email-masked]>
Sent: Friday, July 22, 2011 5:59 PM

> and by the way, the entire series of MUA/MTA and MTA/MTA links don't have to
have IPv6 for it to be used on some of them. If one end user is IPv6-only, the
other is IPv4-only, and at least one MTA in between is dual, nobody should
notice an issue.

Not quite true.  If there is an IPv6 MTA somewhere in the chain, then an MTA/MUA
will likely see an IPv6 address in the header, in the 'Received: from' so any
software, perhaps those concerned with detecting and analysing possible 'spam',
that looks at those fields will be affected.

Tom Petch
>
> My initial comment to Michael, when he pointed the draft out to me, was that
email seems like the poster child of an easy application to add IPv6 to, as the
applications (SMTP, POP, and IMAP) mostly support it already and the current
OS's support IPv6. The primary thing preventing mail/IPv6 is network IPv6
deployment, which is in progress.

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 23 Jul 2011 06:14:27 -0700

> that looks at those fields will be affected.

This happens today, on this mailing list no less. It's happened for more than a decade now.

---

From: Joel Jaeggli <[email-masked]>
Date: Sat, 23 Jul 2011 16:10:51 -0400

Apologies I hake been reading that thread backwards to forwards.

these are my own thoughts.

headings 5 6 7 are actually subheadings of 4 not new sections in their own right.

The timeline specified seems effectively arbitrary, deployments are in various stages there are a small number for example that crossed the threshold 7 (modula the part about turning ipv4 off more than 10 years ago. likewise even in scenario where the majority of internet connected mailservers support ipv6 it seems likely that mailservers operate at scale will maintain A records until the percentage traffic received on them drops to a negligible percentage. A timeline therefore whether measured in years or not is only locally significant except perhaps on very long timescales.

The document couples ipv6 email service, with customer ipv6 transport deployment when really they're fairly decoupled, e.g. from my vantage point I use the same mailservers regardless of which network to which I am presently attached and to the extent that some them have AAAA records for IMAP, MX and submission services I expect those even when my client is not presently in a location that can use them. likewise I expect comcast t-mobile google and apples mail services timelines to be uncoupled from from t-mobile or comcast offering v6 transport to by devices.

---

From: Fred Baker <[email-masked]>
Date: Sat, 23 Jul 2011 19:13:33 -0400

> IPv6 and IPv4 are different enough that it's a bit difficult to anticipate which source-address-based countermeasures will be effective in IPv6.  So it seems a bit silly to say that countermeasure…

The best countermeasures, to my knowledge, are a combination of reputation (spam tends to come from bots, and bots tend to not be in one's business-partner's networks) and Bayesian or Bayesian-style filters (e.g., content-based). The latter, as you note, doesn't need to depend on source address (although in reality it probably does figure in); the former does. Of course, spammers will enjoy nesting in places that use privacy addresses, which for better or worse at the moment means that Windows machines will be a botmaster target, and is an argument for MAC-address or DHCP-based schemes. But you and I both know the obvious solution there; subnets develop reputations, not EIDs.

I'll argue that we probably know pretty well how to defend IPv6 networks. We may not have collected the reputation data for addresses or prefixes yet, but we know how to do that. We already have the Bayesian data, modulo the source address. It's largely - as with many things in IPv6 - a matter of turning things on.

As near as I can tell, delaying the start of that process is - as with anything in which one arbitrarily delays - a matter of delay. The work has to get done eventually, and delay mostly puts off the beginning - the work is the same.

---

From: Keith Moore <[email-masked]>
Date: Sun, 24 Jul 2011 00:08:42 -0400

> As near as I can tell, delaying the start of that process is - as with anything in which one arbitrarily delays - a matter of delay. The work has to get done eventually, and delay mostly puts off t…

I think we disagree about the effectiveness of address-based reputation, but there's no reason to argue about it.

As for delay, I think that network providers that also provide mail service should think in terms of rolling out IPv6-based mail service in the same timeframe as they're rolling out their IPv6-based, publicly accessible, datagram routing service.  But they'd probably be wise to rate-limit the IPv6 email traffic somehow and ramp it up gradually as they fine-tune their spam filters.

The reason I think the dates in the draft are unrealistic is that I don't see most access providers providing native IPv6 access anywhere nearly that soon.  I'd love to be proven wrong about that, though.

Keith

---

From: "John R. Levine" <[email-masked]>
Date: 24 Jul 2011 07:49:51 +0200

> I'll argue that we probably know pretty well how to defend IPv6 networks.

Conceptually, sure.  But the details are surprisingly difficult once you 
get into them.  As you note, body filtering won't change much, if at all, 
but using an IP reputation check as a first pass is so much faster that it 
has to work.  That's where the scaling issues come in.  The IPv4 address 
space is small enough that it's practical to keep a reputation database of 
each address, but in v6 that's hopeless.  Even if you aggregate everything 
to /64, which is a bad idea for various reasons, it's still hopeless. 
You can aggregate at varying sizes, but now there's the questions both of 
how the DNSBL decides what sizes to use, and how clients do queries 
without blowing out DNS caches, a problem I failed to anticipate in RFC 
5782.  You can ask networks to publish assertions about the way they 
manage their address space, but you have to be prepared for their answers 
to be lies if they find that in their short term self-interest, or if 
they're just incompetent.

Many people have noted that the total number of hosts in the world that 
send any mail that anyone wants is only about 100,000, so it'd be a whole 
lot more efficient to whitelist those and body filter their mail rather 
than blacklisting the rest, if there were some way to manage whitelists 
that won't degenerate into a pay-to-mail shakedown.

These scaling and management issues are somewhat similar to the IPv6 rDNS 
problem which was discussed by some guys from big ISPs last year in 
draft-howard-isp-ip6rdns-04.txt.

All these problems are clearly soluble, but at this point we really have 
no idea what IPv6 traffic will look like once there's enough of it to 
matter, and the amount of traffic will spike painfully when one or two 
botnets start sending to v6.  So probably the best thing to say about mail 
traffic management is to put in a placeholder and note that anyone who 
runs a mail system MUST be prepared to update and adapt what they do as 
the world figures it out.

Regards,

---

From: Keith Moore <[email-masked]>
Date: Sun, 24 Jul 2011 02:01:01 -0400

On Jul 24, 2011, at 1:49 AM, John R. Levine wrote:
> 
> All these problems are clearly soluble, but at this point we really have no idea what IPv6 traffic will look like once there's enough of it to matter, and the amount of traffic will spike painfully when one or two botnets start sending to v6.  So probably the best thing to say about mail traffic management is to put in a placeholder and note that anyone who runs a mail system MUST be prepared to update and adapt what they do as the world figures it out.

Sounds pretty vague to me.  Is it even worth saying that?  Does it provide any useful instruction to the reader?

The only thing that seems clear at this point is that having a sudden flood of IPv6 mail isn't in anyone's interest except perhaps the spammers'.   Mail service operators need to start dealing with SMTP-over-IPv6 soon so that they'll have experience with it, but they also need to be able to throttle the flow of IPv6 mail so that, even if there is a flood, there's time to learn what works well and what doesn't.    

I'm not sure what the best way to do this is - maybe have DNS servers randomly return MX records with v6 addresses (or not) with a configurable probability?   Everything else seems like it would have the undesirable side-effect of delaying IPv4 mail traffic.

Keith

---

From: Gert Doering <[email-masked]>
Date: Sun, 24 Jul 2011 14:19:28 +0200

Hi,

On Sun, Jul 24, 2011 at 02:01:01AM -0400, Keith Moore wrote:
> I'm not sure what the best way to do this is - maybe have DNS
> servers randomly return MX records with v6 addresses (or not) with
> a configurable probability?   Everything else seems like it would
> have the undesirable side-effect of delaying IPv4 mail traffic.

Please explain why returning a MX records with v6+v4 address will
delay IPv4 mail traffic.

Gert Doering
        -- NetMaster

---

From: Joel Jaeggli <[email-masked]>
Date: Sun, 24 Jul 2011 09:46:29 -0400

On Jul 24, 2011, at 1:49 AM, John R. Levine wrote:

> Conceptually, sure.  But the details are surprisingly difficult once you get into them.  As you note, body filtering won't change much, if at all, but using an IP reputation check as a first pass is so much faster that it has to work.  That's where the scaling issues come in.  The IPv4 address space is small enough that it's practical to keep a reputation database of each address, but in v6 that's hopeless.  Even if you aggregate everything to /64, which is a bad idea for various reasons, it's still hopeless. You can aggregate at varying sizes, but now there's the questions both of how the DNSBL decides what sizes to use, and how clients do queries without blowing out DNS caches, a problem I failed to anticipate in RFC 5782.  You can ask networks to publish assertions about the way they manage their address space, but you have to be prepared for their answers to be lies if they find that in their short term self-interest, or if they're just incompetent.

I've been using milter greylist with ipv6 support for a couple of years, autowhitelisting is fairly effective for capturing the ipv6 sources that I expect to receive mail from (just as it does in ipv4) and I don't expect that to change much, if a sender uses a different source address for each connection they're never going to get whitelisted.

> Many people have noted that the total number of hosts in the world that send any mail that anyone wants is only about 100,000, so it'd be a whole lot more efficient to whitelist those and body filter their mail rather than blacklisting the rest, if there were some way to manage whitelists that won't degenerate into a pay-to-mail shakedown.
> 
> These scaling and management issues are somewhat similar to the IPv6 rDNS problem which was discussed by some guys from big ISPs last year in draft-howard-isp-ip6rdns-04.txt.
>

---

From: "John R. Levine" <[email-masked]>
Date: 24 Jul 2011 23:23:44 +0200

> I've been using milter greylist with ipv6 support for a couple of years, autowhitelisting is fairly effective for capturing the ipv6 sources that I expect to receive mail from (just as it does in i…

I haven't updated my greylister to do v6 yet (not enough traffic to 
bother) but that doesn't surprise me a bit.  Greylisting remains a 
remarkably efficient way to make v4 botnet traffic go away, even though 
the bad guys could easily defeat it if they wanted to.

I was thinking about shared v6 client lists, though, so each little host 
doesn't have to go through the same slow learning process.

Regards,

---

From: Michael Newbery <[email-masked]>
Date: Mon, 25 Jul 2011 16:00:26 +1200

> I guess my view is sort of the opposite - there's really little point to upgrading mail to use IPv6 until most of the net has IPv6 access.

[ignoring for the moment the ongoing discussion on spam and *-lists]

You need up upgrade mail to use IPv6 as soon as
* you have customers that only have IPv6 transport
* there is any significant amount of traffic that is IPv6 only

It isn't that day far in the future when most of the world is IPv6 that matters; it's that day that is almost upon us now, when there is stuff you are missing because OTHER parts of the Internet can't---or won't---speak IPv4.

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Jul 2011 00:35:51 -0400

>> I guess my view is sort of the opposite - there's really little point to upgrading mail to use IPv6 until most of the net has IPv6 access.

I probably should say at the outset that my position on this has shifted a bit.  I now do think that there's some point to rolling out IPv6 email if for no other reason than to gain experience with it (and especially spam filtering in the IPv6 environment) before the deluge hits.   Because there will come a point at which IPv4 will be abandoned on a massive scale, and at that point everyone who has been relying on IPv4 to send mail will suddenly start using IPv6.

> * there is any significant amount of traffic that is IPv6 only

I don't disagree with the above.  However:

- Is anyone really planning on offering _only_ IPv6 transport anytime soon, as opposed to IPv6 with some sort of NATed IPv4 access, perhaps tunneled over IPv6?  I have a difficult time believing that anyone wants to offer customers a service that won't let them access 99.9% of the current Internet.   At the very least I think the provider would give them a web proxy to let them access v4 only content, an SMTP forwarder to let them send mail to domains that only have v4 MXes, and an SMTP server that can act as a backup MX, relaying incoming IPv4 mail to the customer's v6-only SMTP server. 

- Similarly, at least in the near future, anyone who wants their mail to be delivered is going to have to be able to send to IPv4 MXes, so I don't think that there will be a significant amount of SMTP traffic that cannot fall back to IPv4 anytime soon.

As I've said for years, I think email and the web will be the last applications to fully migrate to IPv6.   It's not that I doubt the access providers' resolve to migrate their email services.  It's that I think that all of those enterprises out there that are running their own mail systems will be slow to upgrade, and it will still be necessary to accept mail from them and deliver it to them.

But I think it's a good idea to encourage operators (not just access, but enterprise also) to start rolling out SMTP over v6 so that they can get experience with it. 

Keith

---

From: Michael Newbery <[email-masked]>
Date: Mon, 25 Jul 2011 17:34:00 +1200

> I probably should say at the outset that my position on this has shifted a bit.  I now do think that there's some point to rolling out IPv6 email if for no other reason than to gain experience with…

Yes. I suspect that time may come sooner than many are expecting.
> - Is anyone really planning on offering _only_ IPv6 transport anytime soon, as opposed to IPv6 with some sort of NATed IPv4 access, perhaps tunneled over IPv6?  I have a difficult time believing th…

On the inside, customer facing side? Yes. In that, an ISP may very well have customers with IPv6 only transport. LTE for instance. Such an ISP would then want to listen to SMTP from its customers using IPv6.

Now, such an ISP might very well offer NAT64, but I struggle to see the sense in having an ISP NAT64 its *own* customers so its SMTP server doesn't have to speak IPv4. Surely it's simpler to support native IPv6 transport?
> - Similarly, at least in the near future, anyone who wants their mail to be delivered is going to have to be able to send to IPv4 MXes, so I don't think that there will be a significant amount of S…

I agree of course. I doubt any ISP of any size won't be able to find an IPv4 address for its mail servers anytime soon. But, not all mall comes from the ISP's servers.

---

From: Philip Homburg <[email-masked]>
Date: Mon, 25 Jul 2011 09:10:08 +0200

In your letter dated Mon, 25 Jul 2011 00:35:51 -0400 you wrote:
>- Is anyone really planning on offering _only_ IPv6 transport anytime soon, as
> opposed to IPv6 with some sort of NATed IPv4 access, perhaps tunneled over IP
>v6?  I have a difficult time believing that anyone wants to offer customers a 
>service that won't let them access 99.9% of the current Internet.   At the ver
>y least I think the provider would give them a web proxy to let them access v4
> only content, an SMTP forwarder to let them send mail to domains that only ha
>ve v4 MXes, and an SMTP server that can act as a backup MX, relaying incoming 
>IPv4 mail to the customer's v6-only SMTP server. 
>
>- Similarly, at least in the near future, anyone who wants their mail to be de
>livered is going to have to be able to send to IPv4 MXes, so I don't think tha
>t there will be a significant amount of SMTP traffic that cannot fall back to 
>IPv4 anytime soon.

So for outbound: 
- Say you are behind a CGN together with a couple of thousand other customers
  and you have DNSBLs that track reputation at a per IPv4 address granularity,
  what do you think would happen if any of those other customers gets infected
  and starts sending spam?

  If we want make e-mail something that can be done only be a few big parties
  then there is no need to support IPv6. If we want small parties to be able
  to do their own e-mail, then accepting mail over IPv6 is very important.

Inbound:
- A site that is behind a CGN can only accept inbound SMTP on IPv6. So there
  is a need for big secondaries that accept mail over IPv4 and forward it
  over IPv6. This is potentially destroys all the good parts about running
  your own MX.

  If most of the e-mail arrives over IPv6 then having to live with a 
  secondary for legacy IPv4 may be acceptable. If most mail continue to flow
  over IPv4 then it is pointless.

So, think that everybody who is dual stack today, should start sending and
accepting mail over IPv6 as soon as possible.

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Jul 2011 06:57:39 -0400

>  to do their own e-mail, then accepting mail over IPv6 is very important.

interesting point.

I'd like to believe that the DNSBLs will be discredited when this happens, but my experience with those in general is that people already have too much misplaced faith in them, so I don't suppose this will change much.

> accepting mail over IPv6 as soon as possible.

another interesting point.  thanks.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Jul 2011 12:14:47 +0000

On Jul 25, 2011, at 12:35 AM, Keith Moore wrote:
- Is anyone really planning on offering _only_ IPv6 transport anytime soon, as opposed to IPv6 with some sort of NATed IPv4 access, perhaps tunneled over IPv6?  I have a difficult time believing that anyone wants to offer customers a service that won't let them access 99.9% of the current Internet.   At the very least I think the provider would give them a web proxy to let them access v4 only content, an SMTP forwarder to let them send mail to domains that only have v4 MXes, and an SMTP server that can act as a backup MX, relaying incoming IPv4 mail to the customer's v6-only SMTP server.

Most internet connections nowadays can be configured with a stable, globally-routable IPv6 address, but not with a globally-routable IPv4 address, or at least not with a stable one.   This means that you can't receive SMTP connections.   But you can still originate SMTP connections, as long as the other end is willing to accept them.

So I would say that the time when IPv6-only transport is necessary for certain applications is already with us.   I would expect there to be loud and vociferous disputes as to whether or not the hoi polloi should be allowed to have such connections, but that's a separate matter: my point is that there is in fact an application _right now_ that can only be achieved if people turn up IPv6 for outgoing connections.

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Jul 2011 15:18:45 +0100

> IPv6 on their mail systems to do it in a *timely* way.

I agree; I think a 'push' is a good thing.

There is now reason however why sites can't start supporting dual-stack mail now. Many sites as Joel says have been doing this for years. Sure, they're not the huge mail providers that John refers to, but a typical enterprise (in my case campus/university) is a different beast.

We have been running dual-stack relays for quite some time, using MailScanner, which is open source.  We are in the 100's of K's of connections bracket, load-wise.  We would not consider running IPv6-only for the foreseeable future.  In terms of IPv6 spam levels, it's about 25%, compared to 90%+ for IPv4, but the bulk of that spam appears to be from dual-stack list servers, in that it comes from manually-configured IP addresses, rather than autoconfigured ones.  There are some dual-stack mail list servers that contribute a lot of it.  That 25% is somewhat higher than Sander's figure, but again it's a relatively small sample, and IPv6 transport mail remains just under 1% of the IPv4 transport volume.  Compare that to about 5% of our external traffic overall being IPv6.

There have been some blips with having IPv6 support, e.g. when the IETF ran with its secondary/backup mail servers for a test period, but hadn't added reverse DNS for those MXes, so our mail servers rejected their mail over IPv6 and surprisingly - to me at least - they didn't fall back to IPv4 transport, so I dropped off some lists as a result of that.

In some senses, it would be nice to be the target of an IPv6 SMTP botnet, to learn from it... until we are, then we're following the 'run dual-stack and adapt as necessary' suggestion.  If we had to turn off IPv6 on our MXes, it wouldn't take long to do and in practice we'd not miss out on much, if any, external mail.

Tim

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 25 Jul 2011 08:05:39 -0700

> >>>> You don't need universal availability on the last DSL line to have
IPv6 *on servers*.
> >>>
> >>> and by the way, the entire series of MUA/MTA and MTA/MTA links don't
have to have IPv6 for it to be used on some of them. If one end user is
IPv6-only, the other is IPv4-only, and at least one MTA in between is dual,
nobody should notice an issue.
> >>> My initial comment to Michael, when he pointed the draft out to me,
was that email seems like the poster child of an easy application to add
IPv6 to, as the applications (SMTP, POP, and IMAP) mostly support it already
and the current OS's support IPv6. The primary thing preventing mail/IPv6 is
network IPv6 deployment, which is in progress.
> >>
> >> I guess my view is sort of the opposite - there's really little point
to upgrading mail to use IPv6 until most of the net has IPv6 access.
>
> I probably should say at the outset that my position on this has shifted a
bit.  I now do think that there's some point to rolling out IPv6 email if
for no other reason than to gain experience with it (and especially spam
filtering in the IPv6 environment) before the deluge hits.   Because there
will come a point at which IPv4 will be abandoned on a massive scale, and at
that point everyone who has been relying on IPv4 to send mail will suddenly
start using IPv6.
> - Is anyone really planning on offering _only_ IPv6 transport anytime
soon, as opposed to IPv6 with some sort of NATed IPv4 access, perhaps
tunneled over IPv6?  I have a difficult time believing that anyone wants to
offer customers a service that won't let them access 99.9% of the current
Internet.   At the very least I think the provider would give them a web
proxy to let them access v4 only content, an SMTP forwarder to let them send
mail to domains that only have v4 MXes, and an SMTP server that can act as a
backup MX, relaying incoming IPv4 mail to the customer's v6-only SMTP
server.

Yes, ipv6 only + nat64 is a real and tactical near term architecture
documented in ietf, 3gpp, and gsma. This architecture is deployed in beta at
t-mobile USA and will transition to production real soon now for wireless
devices.

I am just providing you a data point on why native v6, especially mobile
clients and the services they access (email ...), is very important in the
near term to avoid nat44 and nat64 on various access networks.

Cb

> - Similarly, at least in the near future, anyone who wants their mail to
be delivered is going to have to be able to send to IPv4 MXes, so I don't
think that there will be a significant amount of SMTP traffic that cannot
fall back to IPv4 anytime soon.
>
> As I've said for years, I think email and the web will be the last
applications to fully migrate to IPv6.   It's not that I doubt the access
providers' resolve to migrate their email services.  It's that I think that
all of those enterprises out there that are running their own mail systems
will be slow to upgrade, and it will still be necessary to accept mail from
them and deliver it to them.
>
> But I think it's a good idea to encourage operators (not just access, but
enterprise also) to start rolling out SMTP over v6 so that they can get
experience with it.