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

Versions: 00 01 02 draft-ietf-appsawg-nullmx

INTERNET DRAFT                                   Mark Delany, Editor
Title: draft-delany-nullmx-00.txt                         Yahoo! Inc
Expires: 4 October 2005                                 5 April 2005

       A NULL MX Resource Record means "I never accept email"


Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.

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


Abstract

A common strategy of SMTP servers when deciding whether to accept an
email or not, is to ensure that the 2821.MailFrom contains a domain
willing to accept non-delivery email (aka bounces).

When the 2821.MailFrom domain has a DNS MX Resource Record (RR), it is
making an explicit statement that it is willing to accept
email. However, when the domain has just a DNS A (or AAAA) RR, there
is no such clarity as most hosts on the Internet advertise an A RR
regardless of whether they want to accept email or not.

The NULL MX RR formalizes the existing mechanism by which a domain
communicates that it will never accept email.



Delany                    Expires October, 2005                       [Page 1]

Internet-Draft            NULL MX                                   April 2005


Introduction

This document formally defines the "NULL MX" as a simple mechanism by
which a domain can indicate that it will never accept email.

SMTP clients have a prescribed sequence for resolving how to deliver
email to a domain. Section 5 of RFC2821 [RFC2821] covers this in
detail, but in essence the SMTP client first looks up a DNS MX RR and
if that is not found it falls back to looking up a DNS A RR.

However, many domains do not accept email, but do have A records. If
they have no MX records then senders will attempt to deliver mail to
those A records.

If there is no SMTP listener at that address then the message will be
attempted repeatedly for a long period before the sending MTA gives up
on delivery. This will delay notification to the sender in the case of
misdirected mail, and will consume resources at the sender.

If the domain has an SMTP listener at that address that rejects all
connections (for instance with a 554 response as a connection-opening
response) or has MX records pointing to such a listener then the
sender will be notified in a timely fashion, but resources (generating
a bounce) will still be consumed by the sender and it requires
additional services to be provided which wouldn't usually be needed.

These resource usage problems are exacerbated when large volumes of
email are sent using falsified email addresses in a domain which does
not accept email as its envelope sender, causing large numbers of
bounces to be generated and to consume large amounts of resources
(spool space and outgoing TCP sessions) at the sender of the bounces.

This document formally defines a NULL MX as an alternative which will
cause all mail delivery attempts to a domain to fail immediately,
without any reconfiguration of existing MTAs.


SMTP server benefits

Being able to detect domains that never accept email offers many
resource savings to an SMTP server. In the first instance, it can
choose to reject email during the SMTP conversation that does not
present a deliverable 2821.MailFrom domain.

In the second instance, if an SMTP server accepts an email, it can be
confident that an attempt to send a non-delivery email will likely be
answered by another SMTP server. This greatly helps to reduce
non-delivery queues. This contrasts greatly with the current situation
where a non-delivery email for, eg, www.example.net, will sit in the
queue for a full queue lifetime as SMTP connection attempts to



Delany                    Expires October, 2005                       [Page 2]

Internet-Draft            NULL MX                                   April 2005


www.example.net simply timeout.


Parallel Considerations

Clearly the perpetrators of abusive mail can adapt such that the "vast
class of email" that this mechanism helps identify, simply move over
to using 2821.MailFrom domains that have valid MX RRs.

Certainly this is true, but the direct benefits to the SMTP server still
apply. When an SMTP server queues a non-delivery email, the target
domain will accept the email or give a definitive rejection so the queue
entry will be removed promptly, thus keeping the queues short.

More importantly, there are parallel developments in Internet email,
particularly in sender authentication, that provide better mechanisms
for SMTP servers to authenticate email from those domains that do
legitimately accept email.


The NULL MX Resource Record

To indicate that a domain never accepts email, it advertises a
solitary MX RR with a RDATA section consisting of an arbitrary
preference number 0, and a dot terminated null string as the mail
exchanger domain, to denote that there exists no mail exchanger for a
domain.

The dot termination denotes that the null MX domain is considered to
be absolute, and not relative to the origin of the zone, the behavior
of dot termination and the formatting of this record is as described
in STD13 [STD13].

The interpretation of a NULL MX RR only applies when the domain as a
single MX RR. If a domain advertises multiple MX RRs, the
interpretation is unchanged from that defined by RFC2821.


The "I never send email" Corollary

A presumption of an SMTP server when presented with an "I never accept
email MX" might be to decline to accept such email as it knows that a
non-delivery will never be accepted.

SMTP servers MAY 550 reject mail sent by a MAIL FROM domain that has a
NULL MX record.


Security Considerations

SMTP mail is inherently insecure in that it is feasible for even



Delany                    Expires October, 2005                       [Page 3]

Internet-Draft            NULL MX                                   April 2005


fairly casual users to negotiate directly with SMTP servers. This
proposal is about eliminating one small section of SMTP insecurity.

It is claimed that there are legitimate cases where a domain may send
email but never wants to receive email. SMTP servers that reject mail
from domains that advertise a NULL MX risk losing email from those
domains.


Normative References

  [STD13]       Mockapetris, P., DOMAIN NAMES - CONCEPTS AND
                FACILITIES", STD 13, November, 1987.

  [RFC2821]     Klesin, J., Editor, "Simple Mail Transfer Protocol",
                RFC 2821, April 2001.


Acknowledgments

The editor wishes to thank Steve Atkins, James Lick, John Levine, der
Mouse, Daniel Quinlan and Suresh Ramasubramanian for their valuable
suggestions and constructive criticism.


Editor's Address

    Mark Delany
    Yahoo! Inc
    701 First Avenue
    Sunnyvale, CA 95087
    USA

    Email: mx0dot@yahoo.com


Please send comments to the editor at the above address. This feedback
email address will remain valid until this draft expires or is
replaced with a subsequent revision.


Copyright Notice

   Copyright (C) The Internet Society (2005).

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

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE



Delany                    Expires October, 2005                       [Page 4]

Internet-Draft            NULL MX                                   April 2005


   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.


  RCS: $Id: draft-delany-nullmx-00.txt,v 1.2 2005/04/05 15:42:29 markd Exp $



Delany                    Expires October, 2005                       [Page 5]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/