Are there any folks here who would be inclined to do SMTP over IPv6? I have
a test v6 network with is ready to do email but getting some real world data
to verify headers would be more helpful. Please send me an email offlist if
you are interested.
Thanks,
Zaid
The NANOG list mail server is IPv6-enabled. Your above message came into our mail server over IPv6. So by just using this list you'll be testing your mailserver over IPv6.
Antonio Querubin
808-545-5282 x3003
e-mail/xmpp: tony@lava.net
So for example here's Antonio's reply header going to the list over v6 transport then out to our site also by v6:
Received: from s0.nanog.org (s0.nanog.org [2001:48a8:6880:95::20]) by crow.ecs.soton.ac.uk (crow.ecs.soton.ac.uk [2001:630:d0:f110::25b]) envelope-from <nanog-bounces+tjc=ecs.soton.ac.uk@nanog.org> with ESMTP id m673381995435214jA ret-id none; Thu, 08 Jul 2010 03:03:19 +0100
Received: from localhost ([::1] helo=s0.nanog.org) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from <nanog-bounces@nanog.org>) id 1OWgRQ-000HxK-8m; Thu, 08 Jul 2010 02:02:20 +0000
Received: from outgoing03.lava.net ([2001:1888:0:1:202:b3ff:fe1d:6b98]) by s0.nanog.org with esmtp (Exim 4.68 (FreeBSD)) (envelope-from <tony@lava.net>) id 1OWgPi-000G1S-Si for nanog@nanog.org; Thu, 08 Jul 2010 02:00:35 +0000
One other thing I also notice is that there is a high correlation between use of TLS and IPv6, I guess a lot of people with IPv6 clue also enable TLS:
Received: from s0.nanog.org (s0.nanog.org [IPv6:2001:48a8:6880:95::20])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(No client certificate requested)
by uplift.swm.pp.se (Postfix) with ESMTPS id F1B959F
for <swmike@swm.pp.se>; Thu, 8 Jul 2010 09:10:41 +0200 (CEST)
By default, at least on Debian, TLS and IPv6 (if available, even if only using link local addresses) are on by default, so there's not too much that needs to be done to use TLS on the SMTP side.
TLS wasn't enabled on my Debian using Postfix, so I guess it depends on more factors than just "running Debian". IPv6 seems to be on by default, yes.
Exim tends to be the default installed MTA from everything i've seen, and its TLS configuration is done as part of the split config method they use - check /etc/exim4/conf.d/main/03_exim4-config_tlsoptions
I can't speak for anything other then what I see on default installs - given I only use exim myself, no real experience with postfix beyond my ISPConfig3 server.
I can confirm that STARTTLS was enabled out of the box on my Debian unstable
system... using the snakeoil cert of course.
IPv6 (port 25 incoming) was not enabled out of the box. I needed to add
"inet_protocols = ipv4, ipv6" to enable it.
I figured I would share actual data for everyone here, roughly 1:4.22 messages that are handled by my system go over some sort of IPv6 transport.
(excluding connections from itself-to-itself.. i should make these be IPv6)
puck:~> grep sm-mta /var/log/maillog | grep IPv4 | grep -v 204.42.254.5 | wc -l
22696
puck:~> grep sm-mta /var/log/maillog | grep IPv6 | wc -l
5371
The technical community lists are good fodder for this data. (eg: nanog, *-nsp)
I do wonder if gmail.com gives out AAAA addresses for their MX, and the same for other mail solutions.
This seems like something that is a no-brainer for me, as latency on email isn't a big deal where for HTTP transactions it can be.
- Jared
A few people have sent private replies commenting on the email/IPv6 deployment stats I posted.
I thought I would also share some nameserver statistics to give an idea of what I see (at least at puck.nether.net) for IPv6 vs IPv4 queries.
I won't break down the numbers for everyone, just posting the raw values from a bind stats dump.
The stats are from ~June 21st to now.
[View: _bind]
++ Name Server Statistics ++
359127071 IPv4 requests received
6024171 IPv6 requests received
++ Resolver Statistics ++
[Common]
12966 mismatch responses received
[View: default]
9028037 IPv4 queries sent
733851 IPv6 queries sent
8431489 IPv4 responses received
705457 IPv6 responses received
...
800617 IPv4 NS address fetches
807581 IPv6 NS address fetches
16773 IPv4 NS address fetch failed
759240 IPv6 NS address fetch failed
[View: _bind (Cache: _bind)]
++ Socket I/O Statistics ++
9047706 UDP/IPv4 sockets opened
741832 UDP/IPv6 sockets opened
73995 TCP/IPv4 sockets opened
1362 TCP/IPv6 sockets opened
9047703 UDP/IPv4 sockets closed
741831 UDP/IPv6 sockets closed
91701 TCP/IPv4 sockets closed
1569 TCP/IPv6 sockets closed
1421 UDP/IPv4 socket bind failures
10 UDP/IPv6 socket bind failures
10718 TCP/IPv4 socket connect failures
632 TCP/IPv6 socket connect failures
9025101 UDP/IPv4 connections established
733586 UDP/IPv6 connections established
63200 TCP/IPv4 connections established
729 TCP/IPv6 connections established
17709 TCP/IPv4 connections accepted
208 TCP/IPv6 connections accepted
29998 UDP/IPv4 recv errors
6842 UDP/IPv6 recv errors
1055 TCP/IPv4 recv errors