MARID D. Otis Internet-Draft Mail Abuse Prevention System Expires: February 8, 2005 August 10, 2004 Mail Policy Records (MPR) draft-otis-marid-mpr-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 February 8, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract For domains sending or receiving mail, there is often a desire to publish policies indicating types of mail sent or accepted, and to specify the collateral Mail Channel to assist in these policies. The challenge is to allow the recipient a deterministic means for obtaining this information, while not creating additional burdens for normal mail use. Need for a domain based mail policy facility has become pronounced as many institutions find their mailboxes forged to usurp and thus damage their trust relationships. For these exigent situations, it Otis Expires February 8, 2005 [Page 1] Internet-Draft Mail-PR August 2004 could be advantageous, as example, to request refusal of mail where the [RFC2822] From of Mailbox Domain does not indicate being from the prescribed Mail Channel. These policies may include other prescriptions, such as all outbound mail is digitally signed. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Policy Records . . . . . . . . . . . . . . . . . . . . . . . 4 5. Mail Policy Resource Record . . . . . . . . . . . . . . . . 6 6. Mail Channel Name List . . . . . . . . . . . . . . . . . . . 7 7. Mail Channel Address List . . . . . . . . . . . . . . . . . 7 8. Domain administrator advice . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1 Normative References . . . . . . . . . . . . . . . . . . . 8 10.2 Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . 11 Otis Expires February 8, 2005 [Page 2] Internet-Draft Mail-PR August 2004 1. Overview Terminology: Terminology conforms to [ID-mail-arch]. Terms used in the context of this document: Mail Channel- a prescribed set of Mail Transfer Agents identified by either a list of HELO/EHLO domains or IP addresses in CIDR notation. Mailbox Domain- the portion of the mailbox address on the right hand side of the "@" symbol. Discussion: The venue for discussing this proposal is the IETF MARID working group. [1] 2. Introduction With the DNS records proposed, domains MAY publish a Mail Policy Record (MPR) indicating policies for the use of that domain name, and possibly prescribing the Mail Channel Name List (MCNL) or the Mail Channel Address List (MCAL) records, for lists of associated HELO/ EHLO names or client IP addresses to assist assessments by the mail recipient. Mail Channel prescriptions for Mailbox Domain assessments assume administrative control over shared access for such assertions to produce a desirable result. As such, Mail Channel prescriptions are limited to situations where access to the Mail Channel can be assured as a means to protect a trust relationship with the sending domain and the recipients. Prescribing the Mail Channel for Mailbox Domains is not appropriate with many configurations and uses, as it could invite the problem a Mail Channel prescription attempts to curtail. Domains wishing to assert limited use of their Mailbox Domain, to assist recipients detect nonconforming mail, express this by publishing a DNS Mail Policy record. There is a DNS resource record used to indicate mail polices, and two types of records to prescribe the Mail Channel either by HELO/EHLO names or IP addresses. The Mail Policy Record (MPR) indicates the sending and receiving policies. The Mail Channel Address List (MCAL) enables an exception or white-listing that may be applied when processing forwarded mail. The Mail Channel Name List (MCNL) may be applied to assert the limited use of [RFC2821] or [RFC2822] Mailbox Domains. 3. Background A concise means to prescribe the Mail Channel is needed to establish a determinate burden for the recipient. This method should also Otis Expires February 8, 2005 [Page 3] Internet-Draft Mail-PR August 2004 naturally delegate to other domains without requiring follow-on queries. When considering possible schemes available, there are two related methodologies which enable such a solution. These two methods are defined within Client SMTP Validation (CSV) [ID-Marid-CSV] and Bounce Address Tag Validation [ID-BATV]. By listing authenticated and authorized HELO/EHLO domains to prescribe the Mail Channel, there is no need to resolve to an address. In the case of a message being forwarded, verifying the signature of the local-part of the [RFC2821] MAIL FROM as provided by Bounce Address Tag Validation [ID-BATV] removes the need to decipher the proximal [RFC2822] header. As an alternative to signature checking, the forwarding domain may publish its white-list using a CIDR based record list. An important aspect found combining these methods, is that information is obtained from a deterministic single query for each instance. The overhead for such is then confined to this single DNS lookup and found within a single DNS answer. This becomes important when considering the impact on the DNS cache and the relative amount of UDP traffic imposed upon the network. These deterministic aspects become attractive from the aspect of relative cost, security and network integrity. It should also be noted [RFC2822] headers are often spoofed and can not safely determine the message's origin. There is no means to determine the integrity of the Mail Channel and generally should be assumed insecure. 4. Policy Records There are three DNS records defined by this document. Each of these records are obtained by prepending the "_mp._smtp." sub-domains to the Mailbox Domain reference. The Mail Policy record types delineate their content. Rather than using a TXT RR with notations defined by Augmented BNF for Syntax Specifications (ABNF) [RFC2234] for later processing with a requisite parser, the Mail Policy Record (MPR) is defined as a single encoded IPv4 address record, the list of HELO/ EHLO domain names (MCNL) is defined using PTR records, and the address list of the Mail Channel (MCAL) is defined using APL records defined in A DNS RR Type for Lists of Address Prefixes [RFC3123]. If there is a Mail Channel for the [RFC2822] From Mailbox Domain, then forwarding by the recipient may be allowed to then rely upon [RFC2821] MAIL FROM local part signatures as defined in Bounce Address Tag Validation [ID-BATV] or upon specific forwarding domains having been white-listed by the receiving MTA of the forwarded mail. There are two fields that may reference specific policies, the [RFC2821] MAIL FROM, and the first Mailbox Domain in the [RFC2822] From. The process of deciding on the policies indicated by these two Otis Expires February 8, 2005 [Page 4] Internet-Draft Mail-PR August 2004 fields requires performing a series of conceptually discrete steps: Mailbox Domain Policy: What are the requested policies for the Mailbox Domain in question? This is obtained by performing an MPR, an IPv4 address record, lookup and analyzing the lower 24 bits of the returned address. Permitted Mailbox Domain Channel: Should mail be accepted, if the Mailbox Domain restricts allowable HELO/EHLO domain names? Acceptance is then determined by performing a MCNL PTR record lookup and finding a match with the current CSV HELO/EHLO domain name. Domain names within the MCNL are treated as being wildcarded to allow matches with all sub-domains. If the mail is not accepted and no exceptions are possible, then MTAs performing the Mail Channel check as part of receiving a message SHOULD reject that message with either "550 MAIL FROM Channel Failure." or "550 From Channel Failure." depending upon the field causing the rejection. There may be exceptions made with forwarded mail. Alternative rules may apply when restrictions are placed upon the Mailbox Domain and the Mail Channel fail in the case where the mail has been forwarded. Permitted Channel Failure: Should the mail be accepted, if the Mailbox Domain restricts allowable HELO/EHLO domain names, but the name does not match? Acceptance is then determined by the use of BATV and Return Path Validation when permitted by Mailbox Domain policy. If the BATV Return Path Validation is attempted but fails, " BATV check unsuccessful." should be appended to the error message sent upon rejection. Return Path Validation and Permitted Channel Failture: Should the mail be accepted, if the Mailbox Domain restricts allowable HELO/EHLO domain names, but the name does not match, and there is no Return Path Validation? Acceptance may also be determined by a rule established by the domain administrator of the receiving MTA that then allows preforming an MCAL APL lookup for predefined domains. Should the current IP address of the remote client then be included within the list, the mail is accepted. In other words, is the sender white-listed? The rule of Otis Expires February 8, 2005 [Page 5] Internet-Draft Mail-PR August 2004 allowable Mailbox Domains may be categorized based upon the mail recipient. 5. Mail Policy Resource Record The Mail Policy RR is an encoded A record with bit values used to indicate policy requests. _mp._smtp.domain IN A 127... The address octets are treated independently. The most significant octet is always the value of 127 decimal; see [RFC3330]. The Version octet defines the revision level of this mechanism starting at 1. The Send and Request octets comprise a summation of values used to provide various indications. +--------------+----------------------------------------------------+ | Send Bit | Meaning | | Value | | +--------------+----------------------------------------------------+ | 1 | BATV: This domain uses public key BATV for all | | | sent messages. | | 2 | Signed: This domain uses public key digital | | | signatures for all sent messages. | | 4 | WhiteList: This domain provides a comprehensive | | | MCAL list of all outbound SMTP clients. | | - | Other bit values are reserved for expansion and | | | must be set to zero. | +--------------+----------------------------------------------------+ +--------------+----------------------------------------------------+ | Req Bit | Meaning | | Value | | +--------------+----------------------------------------------------+ | 1 | MailFrom: The Mail Channel prescribed in the MCNL | | | RR should be the exclusive source of this MailBox | | | Domain for the MAIL FROM parameter. | | 2 | From: The Mail Channel prescribed in MCNL RR | | | should be the exclusive source of this MailBox | | | Domain for the From header. | | 4 | Ignore BATV: Return Path Validation by BATV should | | | not be used for acceptance when a Mail Channel | | | check fails. | | - | Other bit values are reserved for expansion and | | | must be set to zero. | +--------------+----------------------------------------------------+ Otis Expires February 8, 2005 [Page 6] Internet-Draft Mail-PR August 2004 6. Mail Channel Name List The Mail Channel Name List RR is comprised of a series of PTR records. As example: _mp.smtp.domain. IN PTR our-domain.com _mp.smtp.domain. IN PTR our-access-provider.com The target of the PTR record should be treated as a wildcarded record when doing a comparison with the HELO/EHLO domain presented by the CSV process. Taking the example our-domain.com would then match with the HELO/EHLO domain mx01.sjc.our-domain.com. 7. Mail Channel Address List The Mail Channel Address List RR is comprised of a series of APL records. As example: _mp.smtp.domain. IN APL 1:192.168.32.0/21 !1:192.168.38.0/28 The use of the address negation "!" is to exclude a range of addresses from a larger list. These lists of CIDR blocks are used to enable the white-listing of this domain for the purposes of selectively enabling this domain to forward mail. If the WhiteList value is present in the Mail Policy record, then it can be assumed to be representative of all mail sent by this domain with respect to any channel restrictions. 8. Domain administrator advice The use of the MCAL as a white-listing tool may be extended to other uses. The lack of a WhiteList value in the Send field of the MPR is intended to indicate the list is not comprehensive and only suitable for qualifying forwarded mail. In this case, other types of mail may be sent from servers not included in this list when the WhiteList value is not asserted. Currently the DNS structures within the UDP packet has a limit of 512 octets. Replies requiring more than 512 octets may create UDP fragmentation and, depending upon the connection and handling, in addition to a higher rate of packet loss, may also cause truncated or partial replies. Furthermore, delivery and resolver handling of truncated and partial responses varies, leading to additional delays and queries. Domain administrators are strongly advised to keep DNS replies below 512 octets for these reasons. With a complete response to an MCAL or MCNL query, SMTP server is able to implement the policies being requested. To help ensure Otis Expires February 8, 2005 [Page 7] Internet-Draft Mail-PR August 2004 complete and coherent answers are obtained from cached records, TTL values of the MPR, MCAL and MCNL records should be the same. Beware some DNS server implementation consider the SOA TTL as a default rather than a minimum. 9. Security Considerations The HELO/EHLO domain contained in the most recently added [RFC2822] Received headers should be visible to the user of the MUA to guard against address spoofing. Successful CSV authentication should append an "*" following the HELO/EHLO domain name in the Received header. A message being within the prescribed Mail Channel should also be visible to the user of the MUA to help guard against the use of sub-domains. If a domain applies mail policies to a domain, then all sub-domains used for mail must also implement mail policies. The nature of the security requirements for Mail Policies are significantly different from typical, "strong" methods required for most Internet security functions. The proposal also relies on security of the underlying IP network and on the integrity of DNS data. It performs a basic authentication of the mail, based on domain name registration of the client IP Address. There is no way a site can keep its hosts from being referenced as servers. This could lead to denial of service. DNS spoofers can supply false addresses. To decrease the success rate for this type of attack, the source port for DNS queries appearing on the Internet should be from random ports. Because this vulnerability exists already with names and addresses, this is not a new vulnerability, merely a slightly extended one. However, as Mail Policy records are used in an authorization context, the DNS servers can be protected by DNSSEC [RFC3008] should this vulnerability become intractable. The proposal relies on the integrity and authenticity of DNS data. 10. References 10.1 Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC0821] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. Otis Expires February 8, 2005 [Page 8] Internet-Draft Mail-PR August 2004 [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2234] Crocker, D., "Augmented BNF for Syntax Specifications", RFC 2234, November 1997. [RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC3008] Wellington, B., "Domain Name System Security (DNSSEC) Signing Authority", RFC 3008, November 2000. [RFC3123] Koch, P., "A DNS RR Type for Lists of Address Prefixes", RFC 3123, June 2001. [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [RFC3330] "Special-Use IPv4 Addresses", RFC 3330, September 2002. 10.2 Informative References [ID-BATV] Crocker, D., "Bounce Address Tag Validation (BATV)", August 2004. [ID-CSVCSA] Otis, D., Crocker, D. and J. Leslie, "sending SMTP client Authorization (CSA)", June 2004. [ID-Marid-CSV] Crocker, D., Otis, D. and J. Leslie, "Client SMTP Validation (CSV)", July 2004. Otis Expires February 8, 2005 [Page 9] Internet-Draft Mail-PR August 2004 [ID-Marid-CSVDNA] Leslie, J., Crocker, D. and D. Otis, "Domain Name Accreditation (DNA)", July 2004. [ID-mail-arch] Crocker, D., "Internet Mail Architecture", May 2004. URIs [1] Author's Address Douglas Otis Mail Abuse Prevention System 1737 North First Street, Suite 680 San Jose, CA 94043 USA Phone: +1.408.453.6277 EMail: dotis@mail-abuse.org Appendix A. Acknowledgements John Leslie provided helpful editorial comments. Otis Expires February 8, 2005 [Page 10] Internet-Draft Mail-PR August 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 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. Copyright Statement Copyright (C) The Internet Society (2004). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Otis Expires February 8, 2005 [Page 11]