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.