INTERNET-DRAFT A. Church Expires: August 1, 2002 February 1, 2002 Authoritative Mail Sender DNS Resource Record draft-church-dns-mail-sender-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 Abstract This document defines a new experimental DNS resource record type, Authoritative Mail Sender (MS), which can be used to verify the authenticity of the domain name provided in the sender address of a mail message and help to prevent forgery of sender addresses. 1. Introduction / Motivation Forged headers have long been a problem with E-mail, as they can allow a malicious user to effectively hide their identity; in addition to simple forgery, senders of unsolicited bulk E-mail ("spam") often take advantage of this method to foil attempts at either blocking their messages or complaining about their mail to them or their service providers. To counter this problem, this document defines a new DNS resource record type, Authoritative Mail Sender, which allows a domain to define hosts which are authorized to send mail for users in that domain, and can be used by a receiving MTA to confirm that the domain in the sender's mailbox address given Church Expires August 1, 2002 [Page 1] Internet-Draft Mail Sender RR for DNS February 2002 in an E-mail message is in fact valid. 2. The MS Resource Record The Authoritative Mail Sender RR has mnemonic MS and RR type value ???(*). The RDATA for an MS RR consists of a as defined in RFC1035 [1], which gives the name of a host authorized to act as a sending MTA for the domain. MS records cause type A additional section processing for the given name. An MS query returns all MS records associated with the domain name given in the query. (*) A number needs to be assigned by the IANA. 3. Use of the MS RR The MS RR can be used by MTAs to establish whether the sending MTA of a particular message is authorized to send messages for the domain given in the message's sender's mailbox address. A transaction would typically proceed as follows; in this example, we assume that the mailbox provided as the sender address is "user@example.org": Sending MTA connects to receiving MTA Sending MTA sends message from "user@example.org" Receiving MTA queries DNS for MS records for "example.org" If no DNS data is available for the domain: Receiving MTA refuses message(*) Else if no MS records are available: Receiving MTA delivers message(**) Else: Receiving MTA searches MS records for a record matching sending MTA's network address If a record is found: Receiving MTA delivers message Else: Receiving MTA refuses message (*) This should not be a permanent refusal, but rather a "try again later", if DNS data is not available because of a timeout (as opposed to nonexistence of the domain). (**) Until this resource record becomes widely used, the lack of an MS record should not be considered to mean "no authorized sending MTA hosts", as this would prevent the delivery of most mail. A lack of authorized sending MTAs can be explicitly indicated by using a record with a host name which has an impossible network address, such as (for IPv4) 0.0.0.0. Church Expires August 1, 2002 [Page 2] Internet-Draft Mail Sender RR for DNS February 2002 4. Security Considerations Although not a problem specific to MS records, an attacker could potentially exploit the transaction sequence given in section 3 to cause a denial of service on the receiving MTA, by providing as the sender's domain a domain whose DNS the attacker controls, and deliberately delaying or refusing replies to MS queries. For this reason, receiving MTAs should place a reasonable timeout on queries for MS records. The MS data is only as trustworthy as the server which serves it; misconfigured or insecurely configured servers may be susceptible to injection of false data by attackers. Therefore, receiving MTAs should not rely on the presence of an MS record alone as affirmative proof of authenticity, unless the accuracy of the DNS data itself can be separately verified (e.g. via DNSSEC [2]). MS records provide information about addresses of MTA hosts for a domain, which can potentially be used to provide targets for an attacker, such as for a distributed denial of service (DDoS) attack. However, many organizations use the same host as both sending and receiving MTA, and since receiving MTAs for a domain can already be determined via the MX record, MS records do not provide any additional information. Furthermore, if an attacker can cause messages to be sent from a domain to a receiving MTA under his control, he can likewise determine the address(es) of sending MTAs for the domain without needing MS records. While not a security issue _per se_, failure to update MS records when a sending MTA is added or has its network address changed can result in mail being refused. References [1] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. [2] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. Author's Address Andrew Church Primabera Isejuku #315 10-1 Isejuku, Ichikawa-shi Chiba 272-0106, Japan E-mail: achurch@achurch.org Church Expires August 1, 2002 [Page 3] Internet-Draft Mail Sender RR for DNS February 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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 implmentation 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 assigns. 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." Church Expires August 1, 2002 [Page 4]