Our first inbound email via IPv6 (was spam!)
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.
On 6/5/12 10:22 AM, "Raymond Dijkxhoorn" <raymond@prolocation.net> wrote:
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?
Outbound SMTP will be enabled very soon (likely within 24 hours). - Jason
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.
On 2012-06-05 07:29, Raymond Dijkxhoorn wrote: [..]
;; 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
On 6/5/12 10:33 AM, "Jeroen Massar" <jeroen@unfix.org> wrote:
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.
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
On 6/5/2012 9:29 AM, Raymond Dijkxhoorn wrote:
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?
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
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
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.
On Tuesday, June 5, 2012 at 3:42 PM, Seth Mos wrote:
Op 5-6-2012 16:10, Livingood, Jason schreef:
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.
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. -- PacketDam: a cost-effective software solution against DDoS
On 6/5/2012 7:42 AM, Seth Mos wrote:
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.
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: http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electron... 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
On Sun, 10 Jun 2012, Randy Bush wrote:
the key question to me is when will my normal dns rbwls support ipv6? in exim-speak
and this time let's skip the usual round of telling me the worth of each element of my selection.
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... -- Mikael Abrahamsson email: swmike@swm.pp.se
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: http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electron... paul
participants (10)
-
Jack Bates
-
Jeroen Massar
-
Livingood, Jason
-
Matthew Kaufman
-
Mikael Abrahamsson
-
Paul Vixie
-
Randy Bush
-
Raymond Dijkxhoorn
-
Seth Mos
-
Vlad Galu