Internet DRAFT - draft-haas-smtp-check-mail

draft-haas-smtp-check-mail









Application Working Group                                        C. Haas
Internet-Draft                                                   Ovation
Updates: 2821, 1035, 1183                                    August 2003



                   SMTP - Checking Mail Domain Origin
                    draft-haas-smtp-check-mail-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/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 (2003).  All Rights Reserved.

Abstract

   This document describes a method to eliminate domain name "spoofing"
   over SMTP by introducing a new DNS resource record (RR) [1] type
   "MDO" that contains valid SMTP sending server for a specified DNS
   domain. In doing so it addresses section 7.1 of RFC 2821, "Mail
   Security and Spoofing".

1. Overview

   The current SMTP specification [2] has no provision to ensure that a
   "client" has permission to send from a specified domain when sending
   Internet mail, although it does addresses the fact that this issue
   can and will occur. Currently the MAIL FROM command is parsed to see



Haas                                                            [Page 1]

RFC nnnn           SMTP - Checking Mail Domain Origin        August 2003


   if it fits the syntax of "user@example.com". This means that any user
   of any domain can send from any other domain without restrictions.
   Virus writers and mass mailers have exploited this fact by sending
   their mail from random addresses and from the recipient's own
   address.

   Section 7.1 of RFC 2821 advocated "that useful functionality not be
   disabled in the hope of providing some small margin of protection
   against an ignorant user who is trying to fake mail." Unfortunately
   the scope of the problem has gone from ignorant users to
   knowledgeable virus writers and mass mailers. While this document is
   in no way a means to end viruses and unsolicited bulk email (UBE), it
   is a means for a domain name holder to control the integrity of mail
   sent from their domain.

   The goal of this document is to introduce a new DNS RR type called a
   Mail Domain Origin (MDO) record that will be similar to the current
   MX record, except its only purpose is to qualify hosts as valid
   senders for specified domains.

   This document relies on knowledge of RFC 2821, which defines the
   current mail protocol, as well as RFC 1034 and 1035 which define the
   DNS specification.

2. Definitions

   The terms "sender" and "recipient" can be ambiguous when dealing with
   mail routing, as there can be multiple hops between the message
   origin and its intended destination. In this document, the term
   "sending machine" will designate the machine initiating the SMTP
   connection and the term "recipient machine" will designate the
   machine receiving the SMTP session. The term "server" has
   deliberately been left out to avoid any confusion.

   In addition, the term "gateway" defines a machine that routes mail
   between two networks. When a gateway is involved, either the sending
   machine or the recipient machine will actually be the gateway.

3. The MDO Resource Record

   The MDO RR is defined with mnemonic MDO and type code <undefined>.

   The MDO RR has the structure given below:

      <owner> <ttl> <class> MDO <hostname>

   <hostname> is required in all MDO RRs




Haas                                                            [Page 2]

RFC nnnn           SMTP - Checking Mail Domain Origin        August 2003


   <hostname> is the domain name of a host that is authorized to send
   mail from the domain specified in <owner>. The format of the MDO RR
   is class insensitive. MDO records cause type A additional section
   processing for <hostname>.

   Like MX records, MDO records are not implicitly recursive. An MDO
   record defined for host.example.com gives privileges to neither
   sub.host.example.com nor example.com.

   While most hosts that have MX records listed will have duplicate MDO
   records, the reverse won't necessarily be true. An organization might
   have 3 mail servers that can accept incoming mail (thus having MX
   records) but might have 6 servers that are allowed to send mail. This
   list could include the 3 original incoming mail servers along with 2
   off-site web servers and an internal mailing list server.


      example.com.   IN  MX  10  mail1.example.com
      example.com.   IN  MX  15  mail2.example.com
      example.com.   IN  MX  20  mail3.example.com

      example.com.   IN  MDO     mail1.example.com
      example.com.   IN  MDO     mail2.example.com
      example.com.   IN  MDO     mail3.example.com
      example.com.   IN  MDO     ww1.example.com
      example.com.   IN  MDO     ww2.example.com
      example.com.   IN  MDO     listsrv.example.com

4. Handling MAIL FROM command

   Upon receiving the MAIL FROM command from the sending machine, the
   recipient machine will lookup the domain of the address listed in
   MAIL FROM and check the MDO records for IP addresses that match the
   IP of the machine initiating the SMTP session. If the IP address is
   NOT listed, the recipient machine will return an error code of:

      550 Sender not authorized for specified domain

   If the sending machine is listed in the MDO records, then the
   standard 250 OK will be returned.

5. Gateways

   The MDO record is intended to help protect domain name owners on the
   public Internet. Therefore, gateways that take mail from a private
   network to a public network should have an MDO record as well as
   implement MDO records checking for all outbound email. Gateways that
   accept mail from the public Internet should also implement MDO record



Haas                                                            [Page 3]

RFC nnnn           SMTP - Checking Mail Domain Origin        August 2003


   checking. However, recipient servers in private networks behind a
   gateway are not expected to implement MDO record checking because
   this would require the gateway to have an MDO record in every sending
   domain.

6. Ramifications

   While the changes proposed in this document are relatively minor,
   their scope will reach across the entire Internet.

      a) No machine will be allowed to send mail unless it has a proper
   MDO record or it routes its mail through a machine with a proper one.
   While most organizations have one or more central mail servers, many
   have single machines that act as their own SMTP sending servers.
   These machines would be required to have MDO records for the domains
   that they send from.

      b) Because sending machines need MDO records, organizations might
   decide to route all outgoing mail through certain SMTP machines, thus
   increasing the number of outgoing messages per machine.

7. Notes

   This specification is only intended to give domain name holders
   control over mail sent from their domains. It in no way provides a
   mechanism for controlling which user at a specified domain can send
   mail. It is hoped that domain name holders will enforce their own
   policies so that one user cannot spoof another user's address.

8. References

   [1] Mockapetris, P., "Domain Names - Implementation and
       Specifications", STD 13, RFC 1035, November 1987.

   [2] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
       August 1982.

9. Security Considerations

   If an organization had machines capable of sending and receiving SMTP
   traffic but only utilized the sending portion, this specification
   would require either that machine to have an MDO record or that
   machine to route through a gateway. Using the MDO record an attacker
   could find additional SMTP machines that a normal MX record lookup
   wouldn't show. However, the impact of this is negligible because this
   information could easily be found using a port scan.

10. Author's Address



Haas                                                            [Page 4]

RFC nnnn           SMTP - Checking Mail Domain Origin        August 2003


   Chris Haas
   Ovation
   201 Main St.
   6th Floor
   La Crosse, WI 54601
   USA

   Email:ChrisH@OvationAdvertising.com

11. Full Copyright Statement

   Copyright (C) The Internet Society (2003).  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.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.










Haas                                                            [Page 5]