Internet and e-mail policy and practice
including Notes on Internet E-mail


Click the comments link on any story to see comments or add your own.

Subscribe to this blog

RSS feed

Home :: Internet

02 Mar 2011

A politically incorrect guide to IPv6, Part III Internet

In two previous messages we looked at the question of how hard it will be to get IPv4 address space once the original supply runs out, and how much v4 address space people really need. Today we look at e-mail and IPv6.

Of all the applications on the net, mail is probably the one that is least affected by NAT, and will be the least affected by running out of v4 addresses. For one thing, mail doesn't need a whole lot of IP addresses. You can easily put 10,000 users behind mail servers on a single IP, and even a giant mail system is unlikely to need more than a few hundred IPs. (For example, all of Hotmail's inbound servers sit behind 24 IPs.) So even if you had to go buy addresses for your v4 mail servers, you wouldn't have to buy very many.

Mail is by design store and forward, and does not need end-to-end connections. Most other applications expect end-to-end, which means that if you have a NAT or a firewall, you need kludges to get stuff through, which usually but not always always work. Mail forwarding is designed right in, relay or forward a message as many times as you want and it is still fine. Furthermore, current mail systems invariably separate mail submission and pickup from mail transfer. That is, when you send a message using a mail program like Outlook or Thunderbird, it submits the message to a nearby outgoing mail server (MTA, for Mail Transfer Agent), which then sends it along to the recipient's incoming MTA using the SMTP mail protocol. Once it gets there, the recipient's mail program uses POP or IMAP to pick the mail up. (In web mail, the submission and pickup happen within the web mail system's network.) On a network that used v6 internally, it would not require any special engineering to have a gateway MTA which accepted submissions and POP or IMAP pickups via IPv6 to connect to the users, and sent and received via SMTP to the rest of the world on IPv4.

Today there are zillions of mail sites, all of which have IPv4 addresses, so if you want your mail to work, you have to talk IPv4. Even if there turn out to be significant networks that run only on IPv6 (something I'll believe when I see it, other than semi-isolated ones behind NATs) they'll still have IPv4 mail servers to talk to the rest of the world. Given the likely low cost of buying or borrowing IPv4 space, and the fact that an extra level of relay causes no problems at all for mail, I'd expect everyone to have v4 mail connectivity if not forever, for a very long time. What would be the incentive not to?

Mail is also one of the toughest services to move to IPv6. The vast majority of attempted mail deliveries are unwanted spam or malware, so mail servers have to identify and reject as much of the unwanted mail as possible. One of the most effective ways to identify unwanted mail is IP reputation blacklists, tracking IP addresses that are unlikely to send wanted mail. For hosts with sufficiently poor reputations, a mail host can reject attempted mail deliveries, without going through the relatively expensive process of receiving and filtering the messages. Using well run sources of IP reputation data such as the Spamhaus lists, a mail server can reject 90% of attempted deliveries. Since receiving and filtering mail is by far the most expensive part of mail handling, these rejections mean a close to 90% decrease in the cost of running a mail system compared to receiving and filtering everything.

At this point, nobody knows how to do IPv6 reputation. Part of the reason is that we have no idea how people will use their v6 address space for mail. A single address per host, as in IPv4, is only one possibility. In the common situation that a host is allocated a 64 bit address range, it could use a different IPv6 address for every message it ever sent. Spammers will surely do that, and legitimate list managers might also be tempted, to improve tracking and bounce management.

IP reputation data has for over a decade been published in the DNS. (I finally wrote an RFC defining the syntax last year.) But a key reason those DNS lookups work is that mail comes from a relatively small set of addresses, so normal DNS cache behavior keeps the total DNS traffic to a tolerable level, handling repeated lookups for the same IP without going back to the master DNS server. If every spam has a different address, and requires a different DNS lookup, the increased load will be too much for most DNS caches. Most mail servers use other DNS techniques to check incoming traffic, such as a reverse DNS lookup to find the names of connecting hosts, which have the same cache busting problem.

We will eventually figure out both how people use IPv6 addresses for mail, and how to manage and publish v6 reputation data (I've been doing some experiments, which I'll blog about when I have enough results), but until then, running a mail server on v6 will be a lot harder than running one on v4. And since you'll be able to handle all the real mail on v4, why bother?

posted at: 18:45 :: permanent link to this entry :: 7 comments
posted at: 18:45 :: permanent link to this entry :: 7 comments

comments...        (Jump to the end to add your own comment)

IPv4 to IPv6 relay
I'm sure some providers will have relays with spam filtering that will take IPv4 email and send it to your IPv6 only mail server. This is real easy to do...

(by Franck Martin 28 Feb 2011 00:10)

great detail in your 3 part IPv6 posts and this last one really highlights the issue with filtering spam. My colleague shares your opinion and has written about the impact of IPv6 on message filtering systems for email security companies. You can read the article here if you are interested:

(by Sophie N 28 Feb 2011 10:37)

IPv6 Evangelist, Hurricane Electric
Actually, SMTP is the service I recommend people put up on IPv6 first.

It is the one where you can have mildly broken IPv6 connectivity and see what is happening while not having noticeable user impact.

I use several RBLs and a few other mechanisms to toss spam. In reality, grey-listing has actually proven quite a bit more successful in rejecting spam than the RBLs on my system. I haven't seen any meaningful increase in spam processing requirements since enabling my mailserver to do dual-stack and about 20-25% of my email is now coming and going via IPv6.


(by Owen DeLong 28 Feb 2011 19:52)

This may be a bit too pessimistic. Historically, whatever is different about spam was used to filter it. One thing that comes to mind was the relative lack of reverse DNS in spam compared to normal mail.

The same thing applies to a /64: if a normal /64 has at most a couple of hundred hosts and now you find one with millions of hosts, then it's a good chance that it is a spammer.

Another issue is that people tend to take solutions that work for IPv4, convert them to IPv6 and complain that it doesn't work.

For IPv4 you just look up the entire IPv4 address in a DNSBL. But for IPv6, you could just start with looking up a /64 (or even a /48) and then only look up longer addresses when indicated by the DNSBL. Or spam block lists may move to another distribution mechanism. For example, put the whole list on bittorrent and have MTAs look up addresses in a local copy of the list.

One last point. Personally I'd like to see the end-to-end principle applied to e-mail. Just set up an SSL connection to recipient's mail server at home or work and send the message. All ISPs provide is an extra opportunity for third parties to access your e-mail.

(by phicoh 01 Mar 2011 13:59)

By design DKIM does not depend on SMTP, there should be no special IPv6 issues. If I recall this correctly - for SPF I'm sure that it supports IPv6. Users with a static IPv6 should be free to run their own smtpd without paying for an extra IPv4. This cannot work with IPv4-only servers, but big mail providers will offer both IPv4 and IPv6. A (free) "Google Apps" account could be used as IPv4 MX and forward inbound IPv4-mail to an IPv6-smtpd. If that's correct only the sending side IPv6-only to IPv4-only is a serious problem.

(by frank 02 Mar 2011 02:59)

I really enjoyed reading this series of posts. I also agree with this post's sentiment that IPv4 is good enough, if not a lot better, for email.

There is some legitimate email being sent via IPv6. Some spam is too (although I believe at the moment it's a minority). I've also seen some email products that are (or claim to be) IPv6 ready, so the amount of IPv6 email is likely going to increase. Do you think we should actively discourage people from sending email over IPv6, seeing as that will eventually be abused by spammers as an easy way to avoid blacklists?

(by Martijn Grooten 02 Mar 2011 18:21)

> If that's correct only the sending side IPv6-only to IPv4-only is a serious problem

That's easily delt with, I'm running such a system for our users now. Set up a server that provides MSA service requiring SMTP auth with both v4 & v6 addrs and publish MTA services (MX records) with v4 only. If you're offering your users dual-stack mail reading service (IMAP/POP) then offering dual-stack MSA service is a natural. WRT small amounts of v6 spam, probably due to the lack of v6 spambot resources. The majority of US residential ISPs (DSL/cable for home) do not yet provide v6 service. Once that changes the spam landscape will probably do so too.

(by Dave Funk 04 Jul 2011 16:16)

Add your comment...

Note: all comments require an email address to send a confirmation to verify that it was posted by a person and not a spambot. The comment won't be visible until you click the link in the confirmation. Unless you check the box below, which almost nobody does, your email won't be displayed, and I won't use it for other purposes.

Email: you@wherever (required, for confirmation)
Title: (optional)
Show my Email address
Save my Name and Email for next time


My other sites

Who is this guy?

Airline ticket info

Taughannock Networks

Other blogs

Remembering JD Falk - 10 years later
223 days ago

A keen grasp of the obvious
New Hope for the Dead
465 days ago

Related sites

Coalition Against Unsolicited Commercial E-mail

Network Abuse Clearinghouse

© 2005-2020 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.