Internet DRAFT - draft-bajaj-mail-srv

draft-bajaj-mail-srv



INTERNET-DRAFT                                                Gary Bajaj
<draft-bajaj-mail-srv-03.txt>                                 November 2004
Request for Comments: 
Category: 


             Use of SRV records for POP3, POP3S, IMAP and IMAPS.


   Status of this Memo

      This memo defines an Experimental Protocol for the Internet
      community.  This memo does not specify an Internet standard of
      any kind.  Discussion and suggestions for improvement are
      requested.  Distribution of this memo is unlimited.

      This document is an Internet-Draft and is subject to all
      provisions of Section 10 of RFC2026.

      By submitting this Internet-Draft, I certify that any applicable
      patent or other IPR claims of which I am aware have been
      disclosed, or will be disclosed, and any of which I become aware
      will be disclosed, in accordance with RFC 3668.

      Internet-Drafts are working documents of the Internet Engineering
      Task Force (IETF), its areas, and its working groups.  Note that
      other groups may also distribute working documents as
      Internet-Drafts.

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

      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/1id-abstracts.html

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html


   Copyright Notice

      Copyright (C) The Internet Society (2004).


   Abstract

      DNS records for the mail services POP3, POP3S, IMAP and IMAPS do
      not currently provide failover switching as do the DNS MX records
      for SMTP.  This document looks at the issues involved and
      recommends a solution using SRV records.




Expires May 2005                                          [Page 1]

   Introduction

      Mail servers that require high availability might be multi-homed
      with upstream connectivity to two or more ISPs.  This is
      traditionally accomplished by running BGP4 such that each upstream
      provider would route to the site's own IP block.  If connectivity
      to one ISP fails, incoming connections would seamlessly be routed
      through the other ISP.  For various reasons including IP
      allocation constraints, cost and networking expertise, running
      BGP4 is impratical for most small ISPs.  If using DNS only, SMTP
      can be made fault tolerant by using multiple MX records, one for
      each IP serviced by the mail server so that each MX record is
      tried in turn until an IP responds.  Such failover protection
      using DNS is not currently possible for POP3 and IMAP connections.

      Using SRV [RFC2782] records seems to be the obvious solution to
      making POP3, POP3S, IMAP and IMAPS redundant.  SRV records also
      provide for load balancing when using multiple servers that have
      access to mail spool on a shared mass storage device such as NAS.

      Examples:

      SRV RRs:

      _pop3._tcp SRV 1 0 110 host1.example.com.
      _pop3._tcp SRV 1 0 110 host2.example.com.
      _pop3._tcp SRV 0 0 110 host3.example.com.
      _imap._tcp SRV 1 0 143 host1.example.com.
      _imap._tcp SRV 1 0 143 host2.example.com.
      _imap._tcp SRV 0 0 143 host3.example.com.
      _pop3s._tcp SRV 0 3 995 host1.example.com.
      _pop3s._tcp SRV 0 1 995 host2.example.com.
      _imaps._tcp SRV 0 3 993 host1.example.com.
      _imaps._tcp SRV 0 1 993 host2.example.com.

      A RRs:

      host1      A    10.0.0.2
      host2      A    172.16.1.2
      host3      A    172.16.1.3

      host1 and host2 are the same multi-homed host that can accept both
      insecure (pop3, imap) and secure (pop3s, imaps) connections.
      host3 is a separate host that is not multi-homed and does not
      accept secure connections.
      Connect to either 10.0.0.2 or 172.16.1.2 if either is available
      (the probability of being selected is 75% for 10.0.0.2 and 25% for
      172.16.1.2) to download mail over a secure POP3 or IMAP connection
      Connect to 172.16.1.3 and if not available connect to either of
      10.0.0.2 or 172.16.1.2 to download mail over an insecure POP3 or
      IMAP connection.





Expires May 2005                                          [Page 2]

   Transitioning Considerations

      When transitioning from using a non-SRV solution to using an SRV
      based solution, old non-SRV aware clients will continue to look
      for A records.  These will not benefit from redundancy until
      updated, but will continue to work.  A DNS proxy solution that
      returns the IPs of hosts found within SRV records to MUAs querying
      A records for that host might be possible for old clients.


   IANA Considerations

      Well known labels have to be allocated for the first label of the
      SRV records.  This document has used _pop3, _imap, _pop3s and
      _imaps.


   Security Considerations

      None.


   References

   [RFC 2026]
      Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   [RFC2782]
      A DNS RR for specifying the location of services (DNS SRV). A. Gul
      brandsen, P. Vixie, L. Esibov. February 2000. RFC 2782.


   Author's Address

         Gary Bajaj
            BITNETS Inc.
            PO Box 58065 RPO Inglewood
            Edmonton, Alberta T5L 4Z4
	    Canada
            +1 (780) 418-5151
            netguru@bitnets.com


   Acknowledgements

         Mark Andrews (ISC)
         Gerrit Schunk


      Copyright (C) The Internet Society (2004).

      This document is subject to the rights, licenses and restrictions
      contained in BCP 78 and at www.rfc-editor.org, and except as set
      forth therein, the authors retain all their rights.

Expires May 2005                                          [Page 3]

      This document and the information contained herein are provided on
      an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
      REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
      THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
      EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT

      THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
      ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
      PARTICULAR PURPOSE.

      The IETF takes no position regarding the validity or scope of any
      Intellectual Property Rights or other rights that might be claimed
      to pertain to the implementation or use of the technology
      described in this document or the extent to which any license
      under such rights might or might not be available; nor does it
      represent that it has made any independent effort to identify any
      such rights.  Information on the ISOC's procedures with respect to
      rights in ISOC Documents can be found in BCP 78 and BCP 79.

      Copies of IPR disclosures made to the IETF Secretariat and any
      assurances of licenses to be made available, or the result of an
      attempt made to obtain a general license or permission for the use
      of such proprietary rights by implementers or users of this
      specification can be obtained from the IETF on-line IPR repository
      at http://www.ietf.org/ipr.

      The IETF invites any interested party to bring to its attention
      any copyrights, patents or patent applications, or other
      proprietary rights that may cover technology that may be required
      to implement this standard.  Please address the information to the
      IETF at ietf-ipr@ietf.org.

Expires May 2005                                          [Page 4]