INTERNET-DRAFT John R. Levine Category: Experimental Taughannock Networks Expires: August 7, 2004 Februrary 7, 2004 A Flexible Method to Validate SMTP Senders in DNS draft-levine-fsv-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 Flexible Sender Validation (FSV) is a lightweight validation technique to detect and deter some kinds of e-mail address forgery. It publishes information in the DNS about IP addresses authorized to send mail for a domain. FSV uses redundant copies of IP data to permit both efficient use by very high-volume mail servers, and simple implementation on low to moderate volume mail servers. 1. General Considerations 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 RFC 2119 [1]. 2. Address Forgery Although SMTP has never provided any security against forged Internet Draft Flexible Sender Validation [Page 1] Internet Draft February 4, 2004 return addresses in e-mail, only in recent years has forgery become a significant problem in Internet e-mail. Forgery includes ``joe jobs'', forged mail sent to discredit the nominal sender, ``phishing'', mail impersonating an organization with whom the recipient does business, and random spam, viruses, and worms, to hide the true location of the sender. Many organizations mandate by policy that all outgoing mail is sent through the organization's own mail servers, in which case forgery can often be detected by checking whether a message was sent from an authorized IP address for the domain. Even when all of a domain's mail comes from known specific addresses, there are situations when their mail can legitimately be sent from elsewhere, e.g., mail forwarders. This document does not address forwarding and related issues such as roaming users, electronic greeting cards, and courtesy web page notifications, because they've been beaten to death elsewhere and the workarounds for FSV are the same as for other IP validation systems such as DMP, RMX. and SPF. 3. DNS considerations FSV works by adding records to a domain's DNS zone that describe the IP addresses that send the domain's mail. Previous sender validation schemes have used two styles of DNS records, a ``block'' record that contains all of the IP addresses for a domain, or ``factored'' records where there is (conceptually at least) a separate record for each IP address and every domain. Block records have the advantage that a DNS client can fetch all of the data for a domain in a single request. They have the disadvantage that they need some sort of internal structure to represent lists of IP address ranges which the DNS client has to parse, and that the record for a domain with many servers might exceed 512 bytes, requiring a TCP rather than UDP transaction. Factored records have the advantages that they are easy to test using logic similar to that used to check DNSBLs (DNS blacklists, such as the MAPS RBL), and each individual record is small, so it will always fit in a UDP packet. The have the disadvantage that large domains can potentially require vast numbers of them, and that it can be hard to tell whether the absence of a factored record for a particular IP means that the IP isn't authorized for the domain, or that the domain hasn't published any records at all. Rather than trying to resolve the tension between block and factored records in one direction or the other, FSV panders to all factions by providing both. Since block records can be large enough to require a TCP Internet Draft Flexible Sender Validation [Page 2] Internet Draft February 4, 2004 transaction, clients SHOULD use block records if the data from the record will be cached within the client for a substantial amount of time (up to the TTL of the record.) Clients that don't cache SHOULD use factored records since they will normally be cached within local DNS caches. 4. Mail server considerations Depending on the design of a mail server, either block or factored records may be handled more efficiently. High-volume mail servers often run many threads within a single process, with each thread managing an SMTP session. Those servers would prefer block records since a domain's data would be parsed once and then saved in the server and reused by any subsequent SMTP session in the same server without needing any more DNS traffic. Low to medium volume mail servers typically start up a separate copy of the SMTP daemon for each SMTP session. Since they will usually only look up one (domain,IP) pair per session, they work better with factored records which avoid the fixed overhead of retrieving and parsing block records only to throw the parsed data away after a single use. 5. Identifying the relevant domain For efficient implementation, the domain on which FSV keys is the domain in the envelope return address given in the MAIL FROM command in the SMTP session. For bounce messages with a null return path, the host name in the HELO or EHLO command may be used instead. If HELO/EHLO arguments are to be validated, FSV data must be present for all host names used in HELO/EHLO commands as well as for domains in mail. Since a server typically has only a single IP address, its FSV data will be small. Or, in the common case where the hosts are within the domain used in mail, the hosts can use the domain's FSV data via a CNAME record. 6. Structure and usage of FSV DNS records FSV records are stored in a pseudo-subdomain called _fsv. The FSV records for example.com would be in _fsv.example.com. The block records are stored under the _fsv name itself as a TXT record and an A record. The TXT record contains a series of character strings, each of which is either an IP address or a CIDR range. An IP address is either an IPv4 address consisting of four digit strings separated by dots, or an IPv6 address consisting of eight hex strings separated by colons. A CIDR range is an address followed by a slash and a number representing the size of the range. No other characters such as spaces, comments, or other punctuation are permitted in the Internet Draft Flexible Sender Validation [Page 3] Internet Draft February 4, 2004 FSV TXT record. A TXT record with impermissible characters or other format errors such as more or less than four components in an IPv4 address, more or less than eight components in an IPv6 address, a non-digit or a component greater than 255 in an IPv4 address, or a non-hex digit or a component greater than FFFF in an IPv6 address, is discarded. The two low octets of the A record at _fsv contains the number of text strings in the corresponding TXT record so that if, for example, the TXT record contains six strings the A record contains 0.0.0.6. The high two octets are reserved for future use and must be zero. The reason for the redundant A record is twofold. One is as an extra check for possible truncation of a potentially large TXT record. The other is as an easily and efficiently testable indication that FSV data is present for a domain. If a domain exists but sends no mail, its _fsv TXT record contains a single null string and the A record contains 0.0.0.0. Other than standard CNAME records, FSV provides no facilities for nesting, indirection, range merging, or any other operations on its contents. A CNAME record can be used if a domain's FSV data is identical to another domain's data. Otherwise, each domain must list its full set of servers. If a domain's data is derived from another domain's data or its own MX data, the domain's management is free to use any software it wants to construct the FSV data, but that process is invisible to and of no interest to FSV clients. FSV TXT data is deliberately in a trivial format that can easily be parsed by an obvious state machine in a single pass without backing up. This makes it straightforward to diagnose and reject invalid data. Factored records are represented as subdomains under _fsv using the standard encoding from rDNS and DNSBLs. IPv4 addresses are reversed by component and prepended to the _fsv name, so that for example, the factored record to check whether address 10.11.12.13 is valid for the domain example.com is 13.12.11.10._fsv.example.com. IPv6 addresses are encoded similarly to IPv6 rDNS, by reversing the hex digits and appending _ip6, so that the record to check whether address 4321:0:1:2:3:4:567:89ab is valid for example.com would be (this name is broken into two lines for typographical purposes): b.a.9.8.7.6.5.0.4.0.0.0.3.0.0.0.2.0.0.0.1.0.0.0.0.0.0.0.1.2.3. 4._ip6._fsv.example.com. If an address is valid for a domain, its factored record exists and contains an A record with value 127.0.0.2. If its address is not valid, its factored record does not exist. Other values for an A record are reserved and MUST NOT be used. Wildcards can be used to decrease the number of unique Internet Draft Flexible Sender Validation [Page 4] Internet Draft February 4, 2004 records needed to encode a range of addresses. The addresses listed in the block and factored records MUST be the same. For example, assume that example.com has outgoing mail servers in four CIDR ranges and a single additional address. $ORIGIN example.com ; keep for a day $TTL 24h ; the block record ; (the next line is broken in two for typographical reasons) _fsv TXT "10.1.2.0/24" "10.3.4.0/23" "10.5.6.0/24" "10.7.8.8/30 "10.9.9.9" ; count of TXT fields, and also indicate that FSV data exists _fsv A 0.0.0.5 ; factored records ; 10.1.2/24 *.2.1.10._fsv A 127.0.0.2 ; 10.3.4/23 *.4.3.10._fsv A 127.0.0.2 *.5.3.10._fsv A 127.0.0.2 ; 10.5.6/24 *.6.5.10._fsv A 127.0.0.2 ; 10.7.8.8/30 8.8.7.10._fsv A 127.0.0.2 9.8.7.10._fsv A 127.0.0.2 ; 10.9.9.9 9.9.9.10._fsv A 127.0.0.2 Clients that use block data simply prepend _fsv to the domain and retrieve the TXT record. If none is available, the client may fetch the A record to check whether FSV data is supposed to be present and log an error if so. Once the TXT data is retrieved and parsed, subsequent mail from the same domain can be checked by looking up the incoming IP address in the data already retrieved. Clients MUST obey the TTL of any block data that is cached in an application and discard the data when the record expires. Clients that use factored data construct the appropriate name by reversing the IP address, prepending it to _fsv and the domain name and fetching an A record. If the record exists and contains 127.0.0.2, the IP address is valid. If the record does not exist, the client should fetch the base _fsv record to determine whether the domain publishes FSV data. Clients typically will not cache factored records, but if they do, they MUST obey the TTL of any data retrieved and discard the data when the record expires, 7. Possible Extensions The two high octets in the domain's _fsv could be used to publish flag bits about the domain's mail policy, for example, whether the domain permits roaming users to send mail through Internet Draft Flexible Sender Validation [Page 5] Internet Draft February 4, 2004 other hosts. Other information about the domain's policy could be published in knwon subdomains of _fsv. For example, if it were desirable to publish a mail contact for a domain other than the standard Postmaster address, the e-mail address could be publiblished in a TXT record in contact._fsv.domain. 8. Security Considerations FSV data is only as secure as the DNS. DNS security is debatably inadequate (see [4]), but the fact that we've survived for 20 years suggests that it'll do for now. Should DNSSEC become available, it will apply to FSV data just like it does to the rest of the DNS. If a domain's DNS servers are unavailable, due to local failures or a denial of service attack, SMTP recipients won't be able to validate mail from that domain. If FSV clients ``fail open'' and accept mail in the absence of FSV data, this would allow forged mail to be received. On the other hand, if FSV clients ``fail closed'' and reject mail temporarily or permanently in in the absence of FSV data, this would cause valid mail to be rejected. A possible design would be to return a temporary rejection in the absence of FSV data and hope that the FSV DNS failure would be cured before the message times out. Block FSV data makes it easier to do security probes of a domain's authorized servers. An attacker might portscan all of the hosts in a domain's published FSV range, and if one of those hosts could be compromised, the attacker could then send forged mail with the domain's return address that passed FSV checks. Factored FSV data makes this attack somewhat harder. 9. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 10. Informative References [2] Crocker, D. "Technical Considerations for Spam Control Mechanisms", work in progress, http://brandenburg.com/specifications/draft-crocker-spam- techconsider-02.txt [3] Klensin, J. (Ed) "Simple Mail Transfer Protocol", RFC 2821, April 2001. [4] D. Atkins and R. Austein, "Threat Analysis Of The Domain Name System," Internet Draft internet-drafts/draft-ietf- dnsext-dns-threats-05.txt, Nov 2003. Internet Draft Flexible Sender Validation [Page 6] Internet Draft February 4, 2004 11. Author's Address John R. Levine Taughannock Networks PO Box 727 Trumansburg NY 14886 (607) 330-5711 johnl@taugh.com Internet Draft Flexible Sender Validation [Page 7]