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

Versions: 00

IETF-MARID                                          A. Lorenzen
Internet Draft                             Server Authority Inc
Expires: October 2004                                April 2004


     DNS Naming Convention for Outbound Internet Email Servers
               draft-lorenzen-marid-mxout-00.txt


Status of this Memo

   This document is an Internet-Draft and is subject to all
   provisions of Section 10 of RFC2026.  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/ietf/1id-abstracts.txt.

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

   This Internet-Draft will expire on October 20, 2004.


Abstract

   This document offers a recommended standardized FQDN (Fully
   Qualified   Domain Name) naming convention pattern for servers
   used to send outbound internet email.

   The purpose is to allow inbound internet email servers to
   recognize outbound email servers designated as authorized or
   unauthorized by those in control of DNS for the sending server
   IP addresses.

   Please address comments and discussion of this document to the
   ietf-mxcomp@imc.org mailing list.


Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and
   "OPTIONAL" in this document are to be interpreted as described
   in RFC-2119 [ ].


Lorenzen, A.        Expires October 20, 2004             [Page 1]


Internet-Draft      .mxout. Naming Convention          April 2004


Table of Contents

   1. Introduction ............................................ 2

   2. Specification of the Naming Convention .................. 3
      2.1 Specification of mxout DNS A record ................. 4
      2.2 Shared Purpose Machines ............................. 5

   3. Assumptions ............................................. 5

   4. Anticipated Benefits .................................... 5

   5. Security Considerations ................................. 5

   6. Informative References .................................. 5

   7. Acknowledgements ........................................ 6

   8. Author's Addresses ...................................... 6

   9. Full Copyright Statement ................................ 6

   10. Appendix: Spam Control Proposal Evaluation Checklist ... 7


Introduction

   Many large ISPs have a PTR record for each IP address they
   control, including IP addresses assigned to home users such as
   cable modem, DSL, or dialup usres. Independent organizations
   have attempted to compile lists of such IP addresses for use
   by inbound email servers in rejecting mail from unauthorized
   sources. Some inbound email server administrators have written
   code to reject connections based on naming convention patterns
   of dynamic IP assignment such as "pool" or "dhcp" etc.

   These lists may be extremely time consuming to maintain and
   contain inaccuracies which lead to rejection of mail
   recipients wanted. Often, the ISP whose IP addresses are being
   used to send mail, has had no input into the formation or
   maintenance of the list of authorized and unauthorized
   patterns or IPs - and may make changes which dramatically
   affect accuracy, without notice to the list maintainer.

   ISPs with customers who are not authorized to operate an
   outbound email server have used port 25 blocking as a method
   to prevent unauthorized outbound mail server operation. A side
   effect of port 25 blocking is that customers cannot utilize
   the outbound server of their choice, such as a corporate email
   server while travelling or at home.

   An ISP with many home user customers may gain substantial
   advantages by conformance to a standard naming convention such


Lorenzen, A.        Expires October 20, 2004             [Page 2]


Internet-Draft      .mxout. Naming Convention          April 2004


   as .mxout. for authorized outbound servers, and a DNS A record
   announcing their .mxout. conformance. Inbound email servers
   may then reject all mail from one of that ISPs IP addresses if
   the verified DNS of the connecting IP does not conform to the
   .mxout. naming convention.

   Example of Foo ISP, Inc., an  ISP with both home user and
   business access customers:

      00-000-0-00.nyc-14.fooisp.net    (home cable modem user)

      00.cpe.0.hxz.adsl.fooisp.net     (business DSL user)

      rwclmhc000.fooisp.net            (Foo's outbound server)

   To conform to the .mxout. naming convention, Foo ISP, Inc.
   changes naming convention to:

      rwclmhc000.mxout.fooisp.net      (Foo's outbound server)

   and, if Foo ISP, Inc. wants to to authorize a class of
   business DSL customer to operate an outbound email server:

      00.cpe.0.hxz.adsl.mxout.fooisp.net     (business DSL user)

   Inbound email servers can now reject viruses and zombie spam
   sources which connect directly from any IP with a PTR record
   ending in .fooisp.net, which does not end with
   mxout.fooisp.net.


1. Specification of the Naming Convention for Outbound Email
Servers

   differentiator.standard-identifier.example.com

   No characters other than a dot (.) comes between the standard
   identifier and the base domain name.

   Correct: nyc09.mxout.example.com

   Incorrect: nyc.mxout09.example.com

   The differentiator portion of the FQDN used for location or
other codifying, is placed to the LEFT of the standard
identifier and is separated from the standard identifier by a
dot.

   Correct: a09.mxout.example.com, toledo.mxout.example.com,
   nyc.mxout.example.com.

   Incorrect: mxouta09.example.com, mxout.toledo.example.com,
   mxoutnyc.example.com



Lorenzen, A.        Expires October 20, 2004             [Page 3]


Internet-Draft      .mxout. Naming Convention          April 2004


   At least one character and one dot shall appear immediately to
   the left of standard identifier, to prevent spoofing and
   simplify parser design by bounding the standard identifier
   with dots.

   Correct: nyc-44.mxout.example.com

   Incorrect: mxout.example.com, nyc-44-mxout.example.com


1.1 Specification of mxout DNS A record

   A DNS A record:

   mxout    IN    A  127.0.0.x

   shall be included in the zone file for each domain which uses
   the outbound server naming convention specified in 1.0 above.

   The purpose of the mxout A record is to verify that the domain
   owner is participating in the .mxout. naming convention, and
   for the domain owner to optionally convey instructions for
   rejecting connections from unauthorized outbound servers which
   utilize that domain name.

   The IP address returned by the mxout A record may optionally
   be interpreted by the querying inbound email server as an
   instruction from the outbound server domain administrator.

   Instructions inferred by responses 127.0.0.1 and 127.0.0.2 may
   optionally be followed by all inbound internet email servers.

   Instructions inferred by responses 127.0.0.3 through 127.0.0.7
   must not be followed by any inbound internet email server with
   users who forward email accounts inbound to that server, and
   may optionally be followed by other inbound internet email
   servers.

   An inbound email server which does not meet the requirements
   for, or have the capacity for the lookups required by
   127.0.0.3 through 127.0.0.7, may treat response 127.0.0.3
   through 127.0.0.7 the same as response 127.0.0.2.

   The recommended meaning for 127.0.0.1 through 127.0.0.7 is as
   follows:

   127.0.0.1 "Servers conforming to the .mxout. convention using
   this domain as a base, are authorized outbound email servers."

   (Only identifies authorized servers - does not specify
   anything about unauthorized servers.)

   127.0.0.2 "Servers conforming to the .mxout. convention using
   this domain as a base, are authorized outbound email servers.
   Please reject connections from any server which uses this
   domain as a base, and does not conform to the .mxout.
   convention."

   (Also specifies a convention for recognizing unauthorized
   servers by exclusion.)

   127.0.0.3 "Servers conforming to the .mxout. convention using
   this domain as a base, are authorized outbound email servers.
   Please reject connections from any server which uses this
   domain as a base, and does not conform to the .mxout.
   convention. In addition, please reject mail having an
   envelope-from of this base domain, if the connection is from a
   server using any base domain which does not conform to the
   .mxout. convention."

   (Additionally specifies a broad designated sender
   authorization for this domain, basically allowing all servers
   where the domain owner has reverse DNS delegation and the
   domain owner chooses to conform to the .mxout. convention.
   This broad designated sender specification would authorize
   sending servers who demonstrate this nominal level of server
   control, such as hotels which force travellers to use special
   SMTP setting or greeting cards sites and others who forge the
   supposed sender email domain in the envelope-from.)

   127.0.0.4 "Servers conforming to the .mxout. convention using
   this domain as a base, are authorized outbound email servers.
   Please reject connections from any server which uses this
   domain as a base, and does not conform to the .mxout.
   convention. In addition, please reject mail from our
   authorized servers if the envelope-from domain does not share
   a name server host with this domain."

   (An example application for this "shared name server host"
   restriction: a measure of AUP policy enforcement for an ISP
   which hosts domains for a large number of customers. No list
   needs to be maintained as hosting customers are acquired or
   leave.)

   127.0.0.5 "Servers conforming to the .mxout. convention using
   this domain as a base, are authorized outbound email servers.
   Please reject connections from any server which uses this
   domain as a base, and does not conform to the .mxout.
   convention. In addition, please reject mail claiming to be
   from this base domain, if the connection is from a server
   using any base domain which does not conform to the .mxout.
   convention. In addition, please reject mail from our
   authorized servers if the envelope-from domain does not share
   a name server with this domain."

   (Combines the 127.0.0.3 and 127.0.0.4 instruction. Designates
   all .mxout. conforming servers in the world as authorized to
   send for this domain. Additionally specifies to reject mail
   from this domain authorized servers, if the envelope-from
   domain cannot prove a relationship to this domain by way of
   shared name server hosts.)

   127.0.0.6 "Servers conforming to the .mxout. convention using
   this domain as a base, are authorized outbound email servers.
   Please reject connections from any server which uses this
   domain as a base, and does not conform to the .mxout.
   convention. In addition, please reject mail with an
   envelope-from of this base domain, if the connection is from a
   server using any base domain other than this one."

   (Designates only its own servers as authorized senders for
   this domain, and specifies that all others are unauthorized.
   An example application for this strict designation might be a
   high security domain such as those which process financial
   transactions.)

   127.0.0.7 "Servers conforming to the .mxout. convention using
   this domain as a base, are authorized outbound email servers.
   Please reject connections from any server which uses this
   domain as a base, and does not conform to the .mxout.
   convention. In addition, please reject mail with an
   envelope-from of this base domain, if the connection is from a
   server using any base domain other than this one. In addition,
   please reject mail from our authorized servers if the
   envelope-from domain does not share a name server with this


Lorenzen, A.        Expires October 20, 2004             [Page 4]


Internet-Draft      .mxout. Naming Convention          April 2004


   domain."

   (Combines the 127.0.0.4 and 127.0.0.6 instruction. Designates
   only its own servers as authorized senders for this domain,
   and specifies that all others are unauthorized. Further
   classifies all envelope-from domains that do not share a name
   server with this domain, as unauthorized.)


1.2 Shared Purpose Machines

   Small organizations may put www, inbound email, outbound
   email, dns, and other functions on one shared purpose machine.
   It is proposed that the PTR record be named with priority to
   the fact that one of the machine functions is outbound email,
   thus something.mxout.example.com, and a matching A record
   included in forward DNS.


2. Assumptions

   By conforming to this convention, outbound server operators
   prove reverse delegation or full knowledge and cooperation
   from the entity with reverse delegation. Reverse delegation is
   unlikely to be granted to short term customers or
   non-customers.

   Upstream vendors asked to set PTR records using this naming
   convention should be fully aware that the machine will be used
   for outbound internet email, and may thus be better prepared
   to enforce AUPs (Acceptable Use Policy.)


3. Anticipated Benefits

   Inbound email servers may optionally skip additional anti-spam
   processing for messages from outbound servers which conform to
   a standardized naming convention.

   A standardized naming convention may allow inbound email
   servers to identify connection attempts which are from
   machines not authorized by IP block administrators as outbound
   email servers.

   A standardized naming convention requires less programming
   logic to recognize authorized outbound email servers, than
   accommodating numerous non-standard naming conventions. The
   need for updates (as IP addresses of outbound servers change)
   is eliminated by a standardized FQDN naming convention.

   A standardized naming convention eliminates the need for a
   look up table of base domains and their non-standard FQDN
   naming convention for outbound email servers.


4. Security Considerations

   The proposed FQDN naming convention relies on queries of the
   domain name system and thus inherits security risks of the
   domain name system, including inaccuracy introduced by DNS
   poisoning, DDOS (Distributed Denial Of Service) attacks, and
   other exploits.

   The internet email system already relies on queries of the
   domain name system. Most inbound email servers will not accept
   mail if the envelope-from domain does not answer a DNS query.
   Similarly, an inbound server making use of .mxout. checking,
   may not accept mail if it has cached the presence of an mxout
   A record for example.com, but due to some transient failure of
   the DNS system, does not get an accurate PTR record response
   for the connecting server at the moment of attempted delivery.

   All losses associated with trusting messages which later are
   found to contain malicious code or unwanted content, or
   rejecting messages which are wanted by recipients - are
   possible, depending on policies adopted by individual inbound
   email servers regarding actions to take based on the
   interpretation of FQDNs encountered during message delivery
   connections.

   All adverse consequences from forwarding accounts that are
   shared by other designated sender schemes, are issues of
   concern for inbound email servers using .mxout. to reject mail
   based on the envelope-from. Inbound servers should not use
   .mxout. for rejecting based on the envelope-from domain, or
   should not allow their recipient users to forward accounts
   from other domains, unless the forwarder ISP is trusted and
   verified to be prepared to properly handle bounces back to
   forwarded accounts and any other pertinent issues.

   To guard against FQDN spoofing, the inbound server software
   must check for an exact match between forward and reverse DNS
   of the connecting IP, if the PTR record response would qualify
   the message for acceptance. If the PTR record response
   qualifies the message for rejection, it is not necessary to
   cross-check the DNS response.


Informative References

   1.  Wong, M., "Sender Policy Framework", Internet Draft,
   February 2003,
   http://www.ietf.org/internet-drafts/draft-mengwong-spf-
   00.txt

   2.  Nelson, R., "SMTP DNS authorization", May 2003,
   http://www.crynwr.com/spam/smtp-dns-authorization.html


Lorenzen, A.        Expires October 20, 2004             [Page 5]


Internet-Draft      .mxout. Naming Convention          April 2004


   3.  Levine, J. et al, "Lightweight MTA Authentication Protocol
   (LMAP) Discussion and Comparison", February 2004,
   http://asrg.kavi.com/apps/group_public/download.php/31/draft-i
   rtf-asrg-lmap-discussion-00.txt

   4. Crocker, D., "Spam Control Proposal Evaluation Checklist",
June 2003, Appendix of
http://asrg.kavi.com/apps/group_public/download.php/30/draft-c
rocker-spam-techconsider-02.txt


Acknowledgments

   The author gratefully acknowledges the contributions of the
   worldwide community of open source programmers and legislative
   advocates, Derek Balling, Brad Knowles, Petru Paler, Kristin
   Zhivago, Bruce Gingery, and Kenneth Beauregard.


Author's Addresses

   April Lorenzen
   Server Authority Inc
   POB 293, Jamestown RI 02835 USA
   Phone: (810) 636-2514
   Email: ietf@codelock.com

   Please address comments and discussion of this document to the
   ietf-mxcomp@imc.org mailing list.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights
   Reserved.

   This document and translations of it may be copied and
   furnished to others, and derivative works that comment on or
   otherwise explain it or assist in its implementation may be
   prepared, copied, published and distributed, in whole or in
   part, without restriction of any kind, provided that the above
   copyright notice and this paragraph are included on all such
   copies and derivative works. However, this document itself may
   not be modified in any way, such as by removing the copyright
   notice or references to the Internet Society or other Internet
   organizations, except as needed for the purpose of developing
   Internet standards in which case the procedures for copyrights
   defined in the Internet Standards process must be followed, or
   as required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will
   not be revoked by the Internet Society or its successors or
   assignees.

   This document and the information contained herein is provided
   on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIMS 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.


Lorenzen, A.        Expires October 20, 2004             [Page 6]


Internet-Draft      .mxout. Naming Convention          April 2004


10.   APPENDIX

               Spam Control Proposal Evaluation Checklist

     1) Adoption Effort

     Requires labor costs to alter forward DNS records and PTR
records for outbound internet email servers, internal
company resource tracking databases, possible
reconfiguration of internal use scripts or software written
to utilize old DNS names.

     Many inbound email servers are already capable of finding
PTR record and checking for a forward DNS match, as well as
doing a DNS A record lookup. However, writing or
installation of some additional code is required to
specifically parse for .mxout. in the connecting IP DNS, and
to take a specific action based on the IP returned from an
mxout A record query, such as reject before DATA, or
continue.

     2) Threshold to benefit

     One major USA based cable/dsl operator adoption on the
sender end is likely to result in payback of labor costs for
receiving end implementation in less than one month.

     http://www.senderbase.org/search

     Ironport Senderbase stats suggest that the volume of mail
sent from non-authorized USA based cable/dsl ISP IP
addresses represents a substantial percentage of worldwide
spam and viruses. The author suggests that adoption by the
top twelve USA based cable/dsl ISPs listed on Senderbase,
would result in a substantial and immediate - within seconds
- benefit to any individual ISP implementing the receiving
end.

     Another benefit would be the reduction of duplication of
implementation and maintenance efforts around the world by
those investing energy into trying to keep track of all the
non-standard "maybe-this-is-their-outbound" naming
conventions and changes, and resulting false positives when
guesses are inaccurate or outdated.

     3) Impact on Participants

     Lowered operational costs for abuse desk, bandwidth,
storage, reduced inbound server loading due to "before DATA"
rejections and lightweight nature of requirements.

     Annoyances which arise from renaming machines. However, only
the relatively small number of outbound email servers need
to be renamed, while the vast millions of home cable/dsl
user IP addresses can be left as is.

     4) Impact on Others

     This is an ISP server level measure, having little impact on
consumers other than incorrect implementation resulting in
undelivered mail or undeliverable notices.

     5) Ongoing Usage effort

     New IP addresses put into service as outbound servers must
be named by the .mxout. convention and there is some effort
involved in enforcing this policy within an ISP with
multiple decision makers.

     So long as the inbound implementation specification does not
change, no ongoing usage effort on the inbound side.

     ISPs, EDUs, etc - which allow certain customers to operate
outbound email servers will need to give those customers
reverse delegation or will need to set up PTR records as
requested by those customers. This is an ongoing customer
service cost, if reverse delegation is not already the
common practice.

     6) Balance of burdens

     The burden seems reasonably balanced between sender and
receiver, with neither needing to make major implementation
investments nor incurring major ongoing costs.

     7) Use by Full Internet

     Since this is a DNS distributed solution, it does scale
globally, yet is also useful when used by as few as one
sender and one receiver.

     8) Growth of Internet

     Remains useful and scaleable regardless of internet size.

     9) Efficiency

     Believed to be lighterweight in terms of CPU cycles used in
the inbound server, than many proposed solutions which do
not have a substantially greater potential to reduce inbound
unauthorized mail volume.

     Like all DNS based anti-spam solutions, takes advantage of
caching through already existing software.

     10)Cost

     Low cost - just the cost of labor to change DNS records for
outbound server domains or domains which are not authorized
to operate outbound servers - possibly under $150 per server
for inhouse labor costs.


Lorenzen, A.        Expires October 20, 2004             [Page 6]

Internet-Draft      .mxout. Naming Convention          April 2004


     11)Reliability

     As reliable and secure as the DNS system itself :).
Consequences of failure of lookup is that spam may be
received during times of DNS errors or timeouts, which could
be brought on intentionally by well-known methods of DNS
DDOS or other DNS subversion. Risks of receiving spam are
lower or not unlike present risks of receiving spam.

     In unlikely circumstances or poorly designed inbound
systems, false positives could occur, not unlike the current
risks of poor designed inbound systems.

     12)Internet Impact

     Reduction of unauthorized email in proportion to adoption.

     13)Spam Impact

     Reduction in proportion to adoption, lessened by spammer
moves to other practices.

     14)Circumvention

     Spammers may create their own .mxout. PTR records if they
have reverse delegation or a willing accomplice ISP, and
utilize a domain they control forward DNS for. However,
there is no way that they can cause ten thousand cable modem
IP addresses over which they have no reverse delegation or
ability to alter forward DNS - to appear to have an .mxout.
naming convention.

     In the case of adoption by major cable/dsl ISPs, spammer
circumvention must take the form of finding a new delivery
path, abandoning the present highly efficient zombie
delivery system which has allowed them to dramatically
increase spam volume in the past year.

     15)Personal post/Reply

     None.

     16)Mailing List

      Please address comments and discussion of this document to
the ietf-mxcomp@imc.org mailing list.

     17)Inter-Enterprise

     Mail between enterprise units benefits from additional
protection from virus infected non-.mxout. labelled machines
belonging to the enterprise.


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