Internet Draft Douglas Otis Category: Standards Track Mail Abuse Prevention System draft-dougotis-smtp-caa-00.txt May 2004 Expires: December 2004 SMTP Client Address Authorization (SMTP-CAA) 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 This Internet-Draft will expire in December 2004. Abstract The helo/ehlo domain reported by a client at the beginning of an SMTP [RFC2821] session has largely been ignored without reliable means to verify this information. To properly recognize a domain sending mail, the domain of the client must be verifiable. This document utilizes a DNS SRV record that extends the definitions for fields of this record as defined in [RFC2782] where the label becomes unique by appending a label of "__caa" following the Proto field. Server verification of permitted client addresses becomes possible as a method to confirm the domain of a client without having prior information shared. Cooperation between client and server domains utilizing this method exclude third party masquerades as originating from within cooperative domains. Initially only a notice of Unknown or Unconfirmed will be added to mail from uncooperative domains unless the domain is determined to be not valid, where then the mail Otis [Page 1] RFC Draft May 2004 will be refused. This added notice provides assurance the server is checking client domains in addition to alerting users to the level of mail compliance on received mail. Once use of this method is common practice in conjunction with other means for confirming the client domain, mail may be refused if the client and/or domain fails these confirmation checks. Introduction Use of DNS SRV-CAA enables publishing outbound SMTP hosts of a domain as a strategic solution for preventing client domain spoofing which threatens network integrity. DNS references using the helo/ehlo domain scales with DNS MX host relationships, in addition, a practice using the MX RR targets (or labels if the MX host is on a different domain) for defining the SRV-CAA name provides a method where all outbound SMTP hosts can be resolved using a series of DNS queries. This convention then allows validations for a higher level domain that may appear in the Mail-From as example. For determining the validity of the Mail-From address however, a hint can be obtained by the helo/ehlo domain, otherwise all MX RR targets as SRV-CAA labels may need queried. The companion SRV-CAA RR to the MX RR confirms a message was sourced from a valid client of this domain. Exceptions for a Mail-From check must be allowed however for situations where the Mail-From domain is unrelated to the client. In these situations of not being able to confirm the source of the Mail-From, alternative means for determining the client/domain relationship should be used. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. Applicability Statement It is expected the SRV-CAA records will enable SMTP servers a means to confirm the client helo/ehlo domain when receiving connections from SMTP clients without a prior relationship established. Normally, an SMTP server restricts mail to being destine for only domains published as labels in the server MX records. In the absence of stronger methods, use of the DNS SRV-CAA record allows servers to also confirm the domain of the client publishing a SRV-CAA record, in addition to checking destination domains. This check may eventually extend to requiring Mail-From be within client domains or requiring other mechanisms to enable acceptance of mail in exceptional cases where client domains are unrelated to the Mail-From domain. This specification is optional, and will only affect cooperating Otis [Page 2] RFC Draft May 2004 domains. Any domain not offering SRV-CAA records will be unaffected, and any SMTP server not checking for client SRV-CAA records at the time of receipt will be unaffected. However, both domains working together CAN exclude forged mail domains. If SRV-CAA records are to apply to Mail-From domains, forwarding must be explicit. For example if somebody@example.com account had a ".forward" file to somebody@another-example.com, then mail sent to the former will be received by the latter, but with no change in the SMTP Mail-From return path. It would be unreasonable to bridge domains subject to ad hoc ".forward" file changes. Either another mechanism exists between domains hosting SMTP clients and servers, or the return path needs to be rewritten by the sender to denote the current client with enough information retained to allow the original return path to be used. This document does not offer details regarding this issue, other than to note this exception. Introductory Example If an SRV-CAA cognizant SMTP server wants to verify the authorization of an SMTP client using TCP protocol for the where the domain returned in the helo/elho response was "mx_01.example.com", it does a lookup of: _smtp._tcp.__caa.mx-01.example.com The example zone file near the end of this document contains answering RRs for an SRV-CAA query. Format of the SRV-CAA RR The format of SMTP SRV-CAA RR, whose DNS type code is 33: _smtp._tcp.__caa.Name TTL Class SRV Priority Weight Port Target (There is an example near the end of this document.) Service Service is the symbolic name of the desired service which is "_smtp" as defined in this document. As per [RFC2782], an underscore '_' is prepended to the service identifier to avoid collisions with DNS labels used to locate hosts. Proto Proto is the symbolic name of the desired protocol which is "_tcp", Otis [Page 3] RFC Draft May 2004 as defined in this document. As per [RFC2782], underscore '_' prepended to prevent collisions with DNS labels used to locate hosts and "__caa" label is appended after the Proto identifier to avoid collisions with labels used to discover services. Name Name is the domain this RR refers to and, by convention, is also either a target or label used to access an MX host for this domain. As with other SRV RR queries, the SRV-CAA RR name used for queries is composed from the domain name obtained from client helo/ehlo identification; there is an example near the end of this document. TTL Standard DNS meaning [RFC 1035]. Class Standard DNS meaning [RFC 1035]. SRV-CAA records are defined for the IN Class. Priority The meaning of Priority differs from [RFC2782]. Priority is generally used to indicate the nature of the client list as defined by the service protocol, for example whether the list is complete or open-ended. Priority should be the same for all SRV-CAA records accessed by the same label and, if not, then records in this set are treated as if a message format decoding error had occurred. Priority with a value of zero indicates a closed or comprehensive list. A value of 1 indicates the client is open or not fully defined. A value of 65535 means the list is null and contains no valid hosts. The label "localhost" rather than "." may used as a placeholder for the target with a record defining a null client list. Weight The meaning of Weight differs from [RFC2782]. Weight defines the nature of the target. Weight can have the following meaning as defined by the summation of the values distinguishing four SMTP message-handling components, a service, and a domain relationship: 1 = Mail User Agents (MUAs) 2 = Mail Submission Agents (MSAs) 4 = Mail Transfer Agents (MTAs) 8 = Mail Delivery Agents (MDAs) 16 = Mail Sender Rewriting of Mail-From (SR) Otis [Page 4] RFC Draft May 2004 32 = Mail Domain Bridging of Mail-From (DBFM) As a client, a MUA on behalf of end-users introduces mail into the mail system using SMTP. An MSA accepts mail from an MUA and performs any necessary processing before relaying the mail. MTA and MSA implement server and client roles in transferring mail to its destination. MTAs may relay mail to other MTAs in sequence before reaching a destination MDA. The MUA obtains mail from the MDA using a protocol other than SMTP. These components are often combined and are denoted by a summation of the Weight value. The Mail Domain Bridging acts as a method for indicating a relationship with Mail-From domains differing from the helo/ehlo domain. Bridging allows a limited number of domains to be included as authorized but a preferred method would be to use a helo/ehlo domain sharing the same root domain to simplify address resolution. This feature does allow a check upon receipt at the MUA if the headers are trusted and the mail does not indicate either a Not Confirmed or Unknown domain. Port The meaning of Port differs from [RFC2782]. Port indicates the allowed server port accessed by the client to initiate communications. The range is 0-65535. A port value of 0 indicates all server ports are allowed. This is a 16 bit unsigned integer in network byte order. This value will be 25 unless the host also accepts mail on other ports, in which case, the value of port should be zero. Target The meaning of Target differs from [RFC2782]. Target is the domain name of the client. There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC1034 or RFC2181). Implementors are urged, but not required, to return the address record(s) in the Additional Data section. Unless and until permitted by future standards action, name compression is not to be used for this field. Domain Administrator Advice Expecting everyone to update their server applications when the first client publishes a SRV-CAA RR is futile nor is this effective in some environments. Therefore SRV-CAA will coexist with other means used to authorize the client. Otis [Page 5] RFC Draft May 2004 Where clients within a domain are spread over several hosts, it seems advisable to have a list of address records at the same DNS node as the SRV-CAA RR. Currently there's a practical limit of 512 bytes for DNS replies. It is advised that domain administrators limit the size of the SRV RRsets described by this proposal such that the total response size, exclusive of optional elements of the additional data section, be under 512 octets. Usage rules A SRV-CAA cognizant server SHOULD use this procedure to verify the address of the client has been authorized: Do a lookup for QNAME=_smtp._tcp.__caa.name, QCLASS=IN, QTYPE=SRV. If the reply is NOERROR, ANCOUNT>0 and there is at least one SRV- CAA RR which specifies the requested label in the reply. If there were no SRV-CAA RR matching this label, the client authorization is Unknown. Else, for all such RR's, do a query for the address records of the target name, using a QTYPE appropriate to the network protocol used by the client, for example, if the client reached the server over IPv4, then QTYPE=A, and if the client reached the server over IPv6, then QTYPE=AAAA". If the Priority indicated an open list, and there was no match, then the client authorization is Not Confirmed. If the Weight indicates the host is a DBMF, this is not used to resolve authorization of the helo/ehlo domain. A DBMF entry is to resolve for differing Mail-From domains where the DBMF target points to a domain to query MX records to obtain labels to transpose into SRV-CAA queries. If the Weight indicates that the client host is a DBMF as well as other mail components, then this is treated as a format error. The DBMF target domain MX targets are used to construct a SRV-CAA query based on the MX preference. The above steps are repeated for these SRV-CAA records. A domain referenced as an MBMF, however, is not allowed to also reference another DBMF within its SRV-CAA records or this is also treated as a format error. Otherwise, if Weight indicates a component different from DBMF that has a matching address, and the port information indicates an authorized port in use, then client authorization is Confirmed. If the component was not a DBMF record, the client list is closed, and there was no match, the Otis [Page 6] RFC Draft May 2004 client authorization is then not valid and is rejected with a 550 Requested Action not Taken. If the mail is accepted but the client is either Not Confirmed or Unknown, a header is appended to the message being "X-Client- Domain: (Not Confirmed)" or "X-Client-Domain: (Unknown)" respectively. Fictional Example This example uses fictional mx-01.example.com as an aid in understanding SRV-CAA records. Publishing the SRV-CAA records i optional. This is (part of) the zone file for a fictitious example.com: $ORIGIN example.com. @ SOA server.example.com. root.example.com. ( 1995032001 3600 3600 604800 86400 ) NS server.example.com. NS ns1.ip-provider.net. NS ns2.ip-provider.net. _smtp._tcp.__caa.mx-01 SRV 0 0 0 fred.example.com. SRV 0 0 0 sam.example.com. MX 10 mx-01.example.com. fred A 172.30.79.11 sam A 172.30.79.12 mx-01 A 172.30.79.13 server A 172.30.79.14 In this example, an SMTP client "mx-01.example.com" in the "example.com." domain needs an SRV lookup of "_smtp._tcp.__caa.example.com." and possibly A lookups of "fred.example.com.", and/or the other hosts named. IANA Considerations IANA will register the "__caa", "_smtp", and "_tcp" and "X-Client- Domain:" labels for use with this document. Security Considerations Otis [Page 7] RFC Draft May 2004 The author believes this RR to not cause any new security problems. Some problems become more visible, though. There is no way a site can keep its hosts from being referenced as servers. This could lead to denial of service. With SRV, DNS spoofers can supply false addresses. Because this vulnerability exists already with names and addresses, this is not a new vulnerability, merely a slightly extended one, with little practical effect. However as SRV-CAA records are used in an authorization context, the DNS servers should be protected by DNSSEC [RFC3008]. SRV-CAA Labeled TXT Records A TXT record associated with the same label used to access the SRV- CAA may be used to provide information related to error reporting as determined by the Service protocol specification. Otis [Page 8] RFC Draft May 2004 Informative References STD 2: Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. RFC 1034: Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. RFC 1035: Mockapetris, P., "Domain names - Implementation and Specification", STD 13, RFC 1035, November 1987. RFC 974: Partridge, C., "Mail routing and the domain system", STD 14, RFC 974, January 1986. RFC 2181: Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, July 1997. RFC 2219: Hamilton, M. and R. Wright, "Use of DNS Aliases for Network Services", BCP 17, RFC 2219, October 1997. RFC 3008 Wellington, B, "Domain Name System Security (DNSSEC) Signing Authority", November 2000. RFC 3225 D. Conrad., "Indicating Resolver Support of DNSSEC." December 2001. RFC 3226 Gudmundsson, 0, "DNSSEC and IPv6 A6 aware server/resolver message size requirements. December 2001. RMF Vixie, Paul. "Repudiating Mail-From". http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00658.html RFC 2782: Gulbrandsen, A., P. Vixie, and L. Esibov, L.,"A DNS RR for specifying the location of services (DNS SRV)" February 2000. RFC 2821: Klensin, J., "Simple Mail Transfer Protocol" April 2001. RFC 2822: Resnick, P., "Internet Message Format" April 2001. Otis [Page 9] RFC Draft May 2004 Author's Address: Douglas Otis Mail Abuse Prevention System (MAPS) 1732 North First St. #680 San Jose, CA 95112 dotis@mail-abuse.org Otis [Page 10] RFC Draft May 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). 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 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Otis [Page 11]