A Plan for Email over IPv6, part 3 – A solution
A solution
How do we deal with it?
Eventually, the Internet community will come up with a permanent solution for email over IPv6 but in the meantime, a transition model is required. The use of IPv6 whitelists is an interim solution.
Rather than using IP blocklists to reject mail from known bad IP addresses, email receivers who wish to receive email over IPv6 should use whitelists to only accept mail from known good IP addresses and reject all email from IPv6 IP addresses that are not on the list.
This IPv6 whitelist is a "Do not reject all mail from this IP address" list; email from these IP addresses may still go through traditional content filtering. IP addresses on this whitelist are there because they send email over IPv6 intentionally; they are not sending email without the computer owner's consent, as part of a botnet.
It is not unusual for email receivers in modern spam filters to use whitelists, or "do not block" lists but still filter the mail by content. For example, many large email receivers do not block the IP address ranges of large webmail providers but still apply content filtering. Other email receivers implement whitelists wherein a small set of IP addresses undergo no spam filtering.
A flowchart of the process is below:
Using an IPv6 whitelist has the following advantages:
It allows email communication between those Internet users who need to do it over IPv6 instead of IPv4.
It does not permit widespread abuse of email over IPv6 since senders must make an effort to get onto the whitelist.
The lists will not take up much memory or bandwidth since the total amount of legitimate senders over IPv6 is projected to be substantially fewer than the total amount of Internet users or devices. There simply are not that many senders who require sending email over IPv6, less than 20 million which is smaller than many IPv4 blocklists.
It is not unusual to put restrictions on IP addresses that are newly sending email. Today (2012) on IPv4, Internet users cannot simply start sending email out a new IP address without encountering problems; most spam filters will view mail from a new IP address as abusive and either block it or throttle mail from it. Therefore, representatives between those users contact each other informing them to expect to see mail from their dormant IP addresses in the near future, or else they ask for a pre-emptive whitelisting. Thus, using an IPv6 whitelist already has precedent. Just as new senders in IPv4 request pre-emptive whitelisting as a courtesy, in IPv6 they will have to request pre-emptive whitelisting as a requirement.
A further refinement is that receivers of email over IPv6 do not need to reject non-whitelisted anonymous senders over IPv6. Instead, they can throttle the senders by limiting the amount of mail they can send. As time passes, the IPv6 senders can build up a good reputation and move from the throttle list, where the amount of mail they can send per IP is limited, to the whitelist – where the amount of mail they can send per IP is nearly unlimited.
Thus, the key characteristic of the whitelist solution is not a default-treat-everyone-as-potentially-good-until-they-show-otherwise, but instead treat-everyone-as-suspicious-until-they-prove-otherwise. The decision to throttle or reject mail from untrusted senders is up to the recipient.
Email receivers may continue to filter the whitelisted sender’s message by content filter and either store it in the user's spam quarantine, or reject the message based upon spam content, but they must not block or throttle messages from those IP addresses simply because the sending IP address is IPv6.
IPs addresses in the whitelist can be either single IP addresses or in IP address ranges, it is up to the receiver to decide which format to use.
Other types of Whitelists, not just IP Addresses
It is not necessary to restrict whitelists to use only IP addresses. Email receivers can whitelist based upon domain and combine it with an SPF (see RFC 4408) or DKIM (see RFC 4871) validation, or by using certificates such as those exchanged in TLS (see RFC 5246).
The advantage of using either of these authentication methods is that instead a domain whitelist is more stable and easier for humans to read than a list of IP addresses. The drawback of using any of these options is that additional DNS queries or certificate exchanges must be performed during the initial SMTP conversation.
Large email providers prefer to make decisions about whether or not to accept or reject the mail as quickly as possible. The longer it takes to decide – which includes waiting for a DNS response and DNS timeouts are frequent – the more load the mail filters are under and the more hardware that is required. If an email receiver only uses an IP whitelist then it can perform an IP lookup as soon as the sending IP connects to it and reject as soon as it gets a verdict back. If the email receiver uses SPF, it must wait to perform the whitelist lookup after the MAIL FROM command in the SMTP conversation and wait for a DNS query to return. If the email receiver uses DKIM, it must wait until it receives the entire message and waits for the DNS query to return from looking up the public key. This slows down the email transaction and increases load on the email infrastructure.
Thus, using other types of authentication are more flexible but do not scale for larger email infrastructure without corresponding increases in hardware.
Posts in this series:
- A Plan for Email over IPv6, part 1 – Introduction, and How Filters Work in IPv6
- A Plan for Email over IPv6, part 2 - Why we use IP blocklists in IPv4 and why we can't in IPv6
- A Plan for Email over IPv6, part 3 - A solution
- A Plan for Email over IPv6, part 4 - Population of the whitelists
- A Plan for Email over IPv6, part 5 – Removals, key differences and standards