Internet DRAFT - draft-dougotis-smtp-caa
draft-dougotis-smtp-caa
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: <domain> (Not Confirmed)" or "X-Client-Domain: <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]
