Recommendations for the use of whitelists for email senders transmitting email over IPv6
draft-tzink-ipv6mail-whitelist-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Terry Zink | ||
| Last updated | 2012-05-19 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-tzink-ipv6mail-whitelist-00
Internet Engineering Task Force T. Zink
Internet-Draft Microsoft
Intended status: Informational May 11, 2012
Expires: November 15, 2012
Recommendations for the use of whitelists for email senders
transmitting email over IPv6
draft-tzink-ipv6mail-whitelist-00
Abstract
This document contains a plan for how providers of email services
can manage the problem of email abuse over IPv6. Spammers can
send mail from a very large range of IPv6 addresses, and this will
make current antispam technology less effective. This is because
email receivers will have to maintain excessively large lists
of IP blocklists which either consume too many resources, or will
become stale and therefore ineffective as spammers quickly
discard one IP and move onto the next one. This document recommends
that during the interim transition of email from IPv4 to IPv6,
email receivers implement a whitelisting option where they only
allow email from permitted senders over IPv6 and reject mail
from everyone else sending email over IPv6.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 15, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Zink Expires November 15, 2012 [Page 1]
Internet-Draft Transition of email services to IPv6 September 2012
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Zink Expires November 15, 2012 [Page 2]
Internet-Draft Transition of email services to IPv6 May 2012
Table of Contents
1. Key Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction and Problem Statement . . . . . . . . . . . . . . 5
3. Important Notice of Limitations and Scope . . . . . . . . . . 5
4. Transition Model - Whitelists . . . . . . . . . . . . . . . . 6
5. Population of the IPv6 Whitelists . . . . . . . . . . . . . . 7
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 9
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Zink Expires November 15, 2012 [Page 3]
Internet-Draft Transition of email services to IPv6 May 2012
1. Key Terminology
This section defines the key terms used in this document.
1.1. Email
Email is a method of exchanging digital messages from an author to
one or more recipients.
1.2. Web mail
A service which offers web based access to email services which would
otherwise be accessed by dedicated email programs running on the
device used to access the email.
1.3. Host
An end user's host, or computer, as used in the context of this
document, is intended to refer to a computing device that connects to
the Internet. This encompasses devices used by Internet users such
as personal computers, including laptops, desktops, and netbooks, as
well as mobile phones, smart phones, home gateway devices, and other
end user computing devices which are connected or can connect to the
public Internet and/or private IP networks.
Increasingly, other household systems and devices contain embedded
hosts which are connected to or can connect to the public Internet
and/or private IP networks. However, these devices may not be under
interactive control of the Internet user, such as may be the case
with various smart home and smart grid devices.
1.4. SMTP
As defined in RFC5321
1.5. Internet Customer
An end user who leverages a connection to the Internet via an ISP and
is provisioned with a public IP to communicate on the Internet.
Zink Expires November 15, 2012 [Page 4]
Internet-Draft Transition of email services to IPv6 May 2012
1.6. Internet facing server
A server which is addressed with a public IP address that is able to
communicate with other publically addressed servers. A server
typically hosts a service that can be utilized by the Internet
community.
1.7. Internal users
Known corporate users of the ISP entity.
1.8. Blocklist
A list of IP addresses that are known to send spam. Email filters
typically reject mail from IPs on blocklists. Blocklists are also
known as blacklists.
2. Introduction and Problem Statement
With the depletion of IPv4 address space and the transition of
Internet infrastructure to IPv6, it is necessary to address the way
in which email services can be transitioned from an IPv4 transport to
that of IPv6. There are significant issues to be addressed around
the matter of abuse in an IPv6 based environment which have been
addressed and largely resolved when operating using IPv4 as a
transport mechanism.
The majority of email service providers currently utilize IPv4
blocklists to reject mail. This is frequently done upon the initial
email connection or sometime during the SMTP transaction (e.g., after
the HELO, MAIL FROM or RCPT TO). This is done to (a) save on more
expensive downstream content filtering, (b) reduce the amount of spam
that must be stored for the user in a spam folder, and (c) improve
the quality of spam filtering.
IPv4 blocklists are manageable because the size of IPv4 address space
is approximately 4 billion IPs. Even if in the worst case every
single IP were listed, this is very large but still manageable for
email filters with sufficient hardware. The size of the total IPv6
address space is 340 trillion trillion trillion IP addresses. This
is far too large for filters to handle or backend hardware to process
or maintain.
Even if blocklist maintainers listed only the IPs that were spamming,
a spammer could send spam from an IP address, let the IP it used get
listed on a blocklist, but discard that IP and move onto the next IP
address. By rotating through IPs quickly, a blocklist would always
Zink Expires November 15, 2012 [Page 5]
Internet-Draft Transition of email services to IPv6 May 2012
be one step behind spammers and lose its effectiveness. This would
also result in more spam in users' inboxes, and greatly increased
processing load for mail filters.
3. Transition Model - Whitelists
It is assumed that eventually the Internet will come up with a
permanent solution to email over IPv6. In the meantime, a transition
model will be required.
Rather than using IP blocklists to reject mail from known bad IPs,
email receivers who wish to receive email over IPv6 should use
whitelists to only accept mail from known good IPs and reject all
email from IPv6 IPs that are not on the list. This IPv6 whitelist is
a "Do not reject all mail from this IP" list, email from these IPs
may still go through traditional content filtering. IPs on this
whitelist are there because they send email over IPv6 intentionally,
not because they are part of a botnet and are sending email without
the computer owner's consent.
It is not unusual for email receivers in modern spam filters to use
whitelists, or "do not block" lists but still content filter the
mail. For example, many large email receivers do not block the IP
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:
+--------------+
| Inbound mail |
| arrives |
+--------------+
|
|
/----------\
+-- No -- / Is sending \ -- Yes --+
| \ IP IPv6? / |
| \----------/ |
| |
+------------+ /-------------------\
| Continue | / Is sending IP \
| normal | +-- No -- \ on IPv6 allow list? / -- Yes --+
| processing | | \-------------------/ |
+------------+ | |
| |
+-------------+ +------------+
| Reject mail | | Continue |
+-------------+ | normal |
| processing |
+------------+
Zink Expires November 15, 2012 [Page 6]
Internet-Draft Transition of email services to IPv6 May 2012
Using an IPv6 whitelist has the following advantages:
(a) It allows email communication between those Internet users who
need to do it over IPv6 instead of IPv4.
(b) It does not permit widespread abuse of email over IPv6 since
senders must make an effort to get onto the whitelist.
(c) 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 IPs that are newly sending
email. Today (2012) on IPv4, Internet users cannot simply start
sending email out a new IP without encountering problems; most spam
filters will view mail from a new IP 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 IPs 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.
4. Population of the IPv6 whitelists
It is outside the scope of this Internet Draft to specify how an
email receiver should build their own IPv6 whitelists.
Administrators may contact each other by email over IPv4, by
telephone, by regular mail, by word-of-mouth, or any other form of
communication. However, once one party or both parties have agreed
to whitelist each other, they must add the others' IP or IPs to their
whitelist. They may continue to filter the message in the 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 messages
from those IPs because of an IP filtering ban because the sending IP
is IPv6.
If any IPs from either party do send over IPv6 but are not included
Zink Expires November 15, 2012 [Page 7]
Internet-Draft Transition of email services to IPv6 May 2012
in the whitelist because they were not agreed to previously, email
from these IPs should be rejected.
IPs in the whitelist can be either single IPs or in IP ranges, it is
up to the receiver to decide which format to use.
5. Security Considerations
This document does not address any security issues inherent in IPv6
Itself with the exception of IP blocklists. It acknowledges that
there are as yet unresolved abuse issues specific to deploying email
infrastructures based on an IPv6 transport. Abuse issues include
general spam, phishing and spoofing of email addresses.
6. Privacy Considerations
This document describes at a high level activities that ISPs should
be sensitive to, where the collection or communication of PII may be
possible. In addition, when performing this transition, ISPs should
be careful to protect any PII collected whether deliberately or
inadvertently.
As noted, any sharing of data from the user to the ISP and/or
authorized third parties should be done on an opt-in basis.
Additionally the ISP and or authorized third parties should clearly
state what data will be shared and with whom the data will be shared
with.
Lastly, there my be legal requirements in particular legal
jurisdictions concerning how long any subscriber-related or other
data is retained, of which an ISP operating in such a jurisdiction
should be aware and with which an ISP should comply.
7. IANA Considerations
There are no IANA considerations in this document.
8. Acknowledgements
The authors wish to acknowledge the following individuals and groups
Zink Expires November 15, 2012 [Page 8]
Internet-Draft Transition of email services to IPv6 May 2012
for performing a detailed review of this document and/or providing
comments and feedback that helped to improve and evolve this
document:
None as yet
Large section of this document are based ...
19. Informative references
[RFC1958] Carpenter, B., "Architectural Principles of the Internet",
RFC 1958, June 1996.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC5211] Curran, J., "An Internet Transition Plan", RFC 5211,
July 2008.
Appendix A. Document Change Log
[RFC Editor: This section is to be removed before publication]
-01 version:
Zink Expires November 15, 2012 [Page 9]
Internet-Draft Transition of email services to IPv6 May 2012
o -01 version published
Appendix B. Open Issues
[RFC Editor: This section is to be removed before publication]
No open issues to date
Authors' Addresses
Terry Zink
Microsoft
1 Microsoft Way
Redmond, WA 98052
US
Email: tzink@microsoft.com
URI: http://www.microsoft.com
Zink Expires November 15, 2012 [Page 10]