[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Engineering Task Force                                  T. Zink
Internet-Draft                                                 Microsoft
Intended status: Informational                              May 22, 2012
Expires: November 15, 2012

     Recommendations for the use of whitelists for email senders
                  transmitting email over IPv6


   This document contains a plan for how providers of email services
   can manage one aspect of 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 blocklisting 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 address and move onto the next one.

   This document recommends that during the 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
   email 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 November 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

1.7.  Internal users

   Known corporate users of the ISP entity.

1.8.  Blocklist

   As defined in section 1 of RFC 5782 and typical usage described in
   section 6 of that same RFC.

1.9.  Whitelist

   As defined in section 1 of RFC 5782 and typical usage described in
   section 6 of that same RFC.

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 a IPv4 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 (as defined in section 1 of RFC 5782) 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 for multiple reasons:

   (a) To save on more expensive downstream content filtering.

   (b) To reduce the amount of spam that must be stored for the user
       in a spam folder and on the mail server.

   (c) To 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 address 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 IP addresses that were
   spamming, a spammer could send spam from an IP address, let the IP
   address it used get listed on a blocklist, but discard that IP
   address and move onto the next IP address.  By rotating through IP

Zink             Expires November 15, 2012                 [Page 5]

Internet-Draft    Transition of email services to IPv6    May 2012

   addresses quickly, a spammer would always be one step ahead of the
   blocklists, and the lists would lose their 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 is required.

   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. Whitelist population is described in section 4.

   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, and are not
   sending email without the computer owner's consent, as part of a

   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:

                    | 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 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.

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. The following
   are possible mechanisms to accomplish this:

   (a) Administrators may contact each other by email over IPv4, by
       telephone, by regular mail, by word-of-mouth, or any other form
           of communication.  Both parties may agree to whitelist each
           other, or one party may whitelist the other without the other
           doing the same.

   (b) Administrators may rely on a third party reputation service that
       provides lists of IP addresses of known good senders of email
           over IPv6.  An administrator may acquire this list and
           proactively whitelist all IP addresses on this list, or a subset
           of them.

   Email receivers may continue to filter the 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 messages
   from those IP addresses due to an IP filtering ban because the
   sending IP address is IPv6.

Zink             Expires November 15, 2012                 [Page 7]

Internet-Draft    Transition of email services to IPv6    May 2012

   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.

   It is not necessary to restrict whitelists to use only IP addresess.
   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
   drawback of using any of these options is that additional DNS queries
   or certificate exchanges must be performed which slows down the
   email transaction, increasing load on the email infrastructure.

5.  Security Considerations

   This document does not address any security issues inherent in IPv6
   itself but acknowledges the security considerations of RFC 5782 do
   apply to this document.  IPv6 security considerations will need to
   be addressed in this document as it develops.

6.  Privacy Considerations

   This document describes at a high level activities that ISPs should
   be sensitive to, where the collection or communication of Personally
   Identifiable Information (PII) may be possible.  In addition, when
   performing this transition, ISPs should be careful to protect any
   PII collected whether deliberately or inadvertently.

   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

   Leiba, B.

19.  Normative references

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              October 2008.

   [RFC4871]  Crocker, D., "Internet Mail Architecture", RFC 5598,
              July 2009.

19.  Informative references

   [RFC5321]  Wong, M. and Schlitt, W. "Sender Policy Framework (SPF)
              for Authorizing Use of Domains in E-Mail, Version 1",
                          RFC 4408, April 2006.

   [RFC4871]  Allman, E., et al, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, July 2009.

   [RFC5246]  Dierks, T., and Rescorla, E., "The Transport Layer
              Security (TLS) Protocol Version 1.2", RFC 5246
                          August 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
   1 Microsoft Way
   Redmond, WA  98052

   Email: tzink@microsoft.com
   URI:   http://www.microsoft.com

Zink             Expires November 15, 2012                [Page 10]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/