One document matched: draft-haas-smtp-check-mail-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-24 01:27:38 |