In preparation for the World IPv6 Launch, inbound (SMTP) email to the
comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC.
Roughly one minute later, at 9:35:30 UTC we received our first
inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail
was spam, and was caught by our Cloudmark messaging anti-abuse platform
(the sender attempted a range of standard spam tactics in subsequent
connections).
In the past several hours we have of course seen other messages from a
range of hosts, many of which were legitimate email so it wasn't just
spam! 
Since the Internet is of course more than just the web, we encourage
others to start making non-HTTP services available via IPv6 as well.
Jason Livingood
Comcast
Jason,
In preparation for the World IPv6 Launch, inbound (SMTP) email to the
comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC.
Roughly one minute later, at 9:35:30 UTC we received our first
inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail
was spam, and was caught by our Cloudmark messaging anti-abuse platform
(the sender attempted a range of standard spam tactics in subsequent
connections).
You specificly tell 'inbound' ... by that you mean the MX record was added. But just to be sure. Comcast is also sending out over IPv6 now right? And if so, what protocol is preferred by default? Outgoing mail over IPv4 or over IPv6?
Since the Internet is of course more than just the web, we encourage
others to start making non-HTTP services available via IPv6 as well.
Watching logs here to see if things (at least mail for me now) will raise the next few days...
Bye,
Raymond.
Hi!
In preparation for the World IPv6 Launch, inbound (SMTP) email to the
comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC.
Roughly one minute later, at 9:35:30 UTC we received our first
inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail
was spam, and was caught by our Cloudmark messaging anti-abuse platform
(the sender attempted a range of standard spam tactics in subsequent
connections).
In the past several hours we have of course seen other messages from a
range of hosts, many of which were legitimate email � so it wasn't just
spam! 
Since the Internet is of course more than just the web, we encourage
others to start making non-HTTP services available via IPv6 as well.
Looking more closely... Is this still work in progress?
;; ANSWER SECTION:
comcast.net. 358 IN MX 5 mx3.comcast.net.
comcast.net. 358 IN MX 10 mx1.comcast.net.
comcast.net. 358 IN MX 5 mx2.comcast.net.
;; ADDITIONAL SECTION:
mx2.comcast.net. 6958 IN A 76.96.30.116
mx3.comcast.net. 358 IN A 68.87.26.147
mx1.comcast.net. 358 IN AAAA 2001:558:fe14:70::22
You are now only accepting IPv6 if all IPv4 fails?
Or will AAAA records for mx2 and mx3 added later?
Bye,
Raymond.
[..]
;; ANSWER SECTION:
comcast.net. 358 IN MX 5 mx3.comcast.net.
comcast.net. 358 IN MX 10 mx1.comcast.net.
comcast.net. 358 IN MX 5 mx2.comcast.net.
;; ADDITIONAL SECTION:
mx2.comcast.net. 6958 IN A 76.96.30.116
mx3.comcast.net. 358 IN A 68.87.26.147
mx1.comcast.net. 358 IN AAAA 2001:558:fe14:70::22
You are now only accepting IPv6 if all IPv4 fails?
Or will AAAA records for mx2 and mx3 added later?
Though it can work, it used to be a really bad idea as there where a
couple of SMTP systems (Communigate Pro being one of them I recall)
which just failed when not seeing an "A" on an MX, this as they did not
understand IPv6...
There is bound to be other systems that are broken like that that will
not failover to the secondary MX, as such, you might want to add an IPv4
address there too just in case.
Greets,
Jeroen
Op 5-6-2012 16:10, Livingood, Jason schreef:
In preparation for the World IPv6 Launch, inbound (SMTP) email to the
comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC.
Roughly one minute later, at 9:35:30 UTC we received our first
inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail
was spam, and was caught by our Cloudmark messaging anti-abuse platform
(the sender attempted a range of standard spam tactics in subsequent
connections).
In the past several hours we have of course seen other messages from a
range of hosts, many of which were legitimate email � so it wasn't just
spam!
Since the Internet is of course more than just the web, we encourage
others to start making non-HTTP services available via IPv6 as well.
I always wondered why (ISPs) never started with rolling out IPv6 email servers first, the fallback from 6 to 4 is transparent and invisible to the end user at a delay of a maximum of 30 seconds.
I enabled v6 for my email before my website since the impact if it didn't work on the 1st try was almost nil.
Still waiting for the 1st Country to top Romania' 6% deployment. I'm sure we can do better then 0.21.
IMHO Asking users if they want IPv6 is the wrong way round, you enable IPv6 and then allow for opt-out in the service portal.
That's basically what the Romanian ISP did. They have not gone bankrupt either, so maybe it's not all as bad as we think.
Cheers,
Seth
Outbound SMTP will be enabled very soon (likely within 24 hours).
- Jason
Hi! Seth,
In the past several hours we have of course seen other messages from a
range of hosts, many of which were legitimate email � so it wasn't just
spam!
Since the Internet is of course more than just the web, we encourage
others to start making non-HTTP services available via IPv6 as well.
I always wondered why (ISPs) never started with rolling out IPv6 email servers first, the fallback from 6 to 4 is transparent and invisible to the end user at a delay of a maximum of 30 seconds.
I enabled v6 for my email before my website since the impact if it didn't work on the 1st try was almost nil.
Still waiting for the 1st Country to top Romania' 6% deployment. I'm sure we can do better then 0.21.
IMHO Asking users if they want IPv6 is the wrong way round, you enable IPv6 and then allow for opt-out in the service portal.
That's basically what the Romanian ISP did. They have not gone bankrupt either, so maybe it's not all as bad as we think.
I think its pretty simple. Many do this, but protection is little. Abuse also but that may change. To get to the point. There are no widely available IPv6 blacklists. Like you are used to have on IPv4. Might be a legitimate reason ...
Lets see how Comcast does.
Bye,
Raymond.
Thanks for the advice. You are seeing inbound records in the very first
stage. More AAAA RRs are coming. The next 24-48 hours around World IPv6
Launch will be interesting.
Jason
It is actually opt-in. But they've advertised it a lot in the months before mass deployment and their user base was educated and willing enough to toggle the knob.
My email will come in via IPv6 as soon as Postini has IPv6 inbound and outbound. As far as I can tell, they still have neither, despite requests going back to 2009.
Matthew Kaufman
"Livingood, Jason" <Jason_Livingood@cable.comcast.com> writes:
In preparation for the World IPv6 Launch, inbound (SMTP) email to the
comcast.net domain was IPv6-enabled today, June 5, 2012, at 9:34 UTC.
Roughly one minute later, at 9:35:30 UTC we received our first
inbound email over IPv6 from 2001:4ba0:fff4:1c::2. That first bit of mail
was spam, and was caught by our Cloudmark messaging anti-abuse platform
(the sender attempted a range of standard spam tactics in subsequent
connections). ...
rim shot:
i suggest that the e-mail industry consider a two-level approach to
rejecting ipv6 spam based on source address.
for more information see:
paul
the key question to me is when will my normal dns rbwls support ipv6?
in exim-speak
!dnslists = list.dnswl.org
dnslists = dialups.mail-abuse.org \
: rbl-plus.mail-abuse.org \
: dnsbl.sorbs.net \
: zen.spamhaus.org
and this time let's skip the usual round of telling me the worth of each
element of my selection.
randy
My thoughts on this is that unless ISPs start to announce what "one customer" is, this is pretty hard. It's a problem in IPv4, but even more so in IPv6.
Wouldn't it help a lot if there was a way to publish that "in this /42, there is one customer per /56, and in this other /42, there is one customer per /48"?
How can that be done via DNS (if that is still a favourable mechanism to distribute information like this)? Whois is not a good way...
the key question to me is when will my normal dns rbwls support ipv6?
in exim-speak
My thoughts on this is that unless ISPs start to announce what "one
customer" is, this is pretty hard. It's a problem in IPv4, but even more
so in IPv6.
i have assiduously avoided gaining serious anti-spam fu. but it seems
to me that ipv6 does not create/enable significantly more spam-bots.
randy
Randy Bush <randy@psg.com> writes:
> ...
i have assiduously avoided gaining serious anti-spam fu. but it seems
to me that ipv6 does not create/enable significantly more spam-bots.
the malware will generally have complete control over the bottom 64 bits
of an ipv6 address. there's no reason to expect to ever receive more than
one spam message from any single ipv6 source.
so, we'll all be blackholing /64's.
moreover, there are going to be more native endpoints in ipv6 than there
were in ipv4, since the NAT incentives are very different in the larger
address pool.
so, we'll all need network operators to whitelist the parts of their
address spaces that they plan to send e-mail from, so that we can avoid
having to blackhole things one /64 at a time.
as before: for more information see:
paul
Actually, I've had a problem with my version of sendmail on solaris choosing mx1.comcast.net and then reporting host not found. I think this is an issue with address selection, despite the server not being setup for v6 (os/sendmail are set for v6 support, but no assignment). I can't think of another reason why it would bounce 800+ emails with relay=mx1.comcast.net but have 0 logs for mx2/mx3.
Jack