| TOC |
|
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 October 31, 2005.
Copyright (C) The Internet Society (2005). All Rights Reserved.
In contrast to other more extensive approaches to deal with unsolicited email, commonly called "spam", this memo discusses a very simple authentication scheme. It uses marking of hosts in reverse DNS (IN-ADDR.ARPA and IP6.ARPA zones) to allow the receiving mail transfer agents to decide whether the connecting (sending) host is a designated mail transfer agent (MTA) or not.
Despite being a weaker scheme than most of the other proposals currently discussed, it can reduce the amount of spam and viruses/worms significantly and has the advantage that it can be implemented based on existing and well-established Internet technology like DNS without any changes to that technology.
This document is part of the LMAP work of the Anti-Spam Research Group (ASRG) of the IRTF.
1.
INTRODUCTION
1.1
Motivation
1.1.1
Reverse Zone vs. Forward Zone
1.2
Terminology
2.
PROPOSAL
2.1
Defining A Well Known Subdomain for the Reverse DNS Tree
2.2
Service Specific Resource Records
2.2.1
Terms and Definitions
2.2.2
Hints for Implementors
2.3
Contact Information
2.3.1
Terms and Definitions
2.3.2
Hints for Implementors
2.4
Example Records
3.
EFFECTS ON EXISTING MAIL INFRASTRUCTURE
3.1
Deployment
3.2
Unmarked Addresses
3.3
Local Mail Clients
3.4
Roaming Users
3.5
IPv6 Compatibility
3.6
RFC2317 Style Delegation
4.
EXPANDING THIS PROPOSAL
4.1
Extensibility
4.2
Blacklists, Whitelists and Accreditation Systems
5.
WHY NOT A NEW DNS RR
6.
IANA CONSIDERATIONS
7.
SECURITY CONSIDERATIONS
§.
References
§
Authors' Addresses
A.
Acknowledgements
§
Intellectual Property and Copyright Statements
| TOC |
The problem with spam and viruses/worms has increased and changed a lot during the last years. In the beginning, distributing unsolicited email was accomplished by abusing relay open mail servers [RFC2505]Lindberg, G., Anti-Spam Recommendations for SMTP MTAs, February 1999.. Spread of viruses needed humans passing on infected data. The situation today shows worms coming packed with their own SMTP modules, utilizing address books and scanning documents for new addresses and therefore victims. A lot of worms install backdoors and (enable) proxy servers. These infected hosts are afterwards abused by spammers to send unsolicited email.
With the growing adoption of broadband technology, a significant part of the Internet hosts shifted to poorly maintained workstations in homes. Permanently connected to the Internet, these hosts form an easy and "paying" prey for worms and abusers. Not only in homes, also in companies the number of poorly maintained hosts is growing.
History and viruses like VBS/LoveLet class or worms like CodeRed and Nimda and the zillions of open proxy servers show, we cannot count on users or administrators to get the problems fixed.
However, what the administrators can decide proactively is whether a certain host, represented by its IP address, is meant to be a MTA that should have the ability to talk to other MTAs across the Internet. Most - if not all - of the proxy servers or workstations do not need to have this ability.
We suggest a mechanism to enable the administrator to mark IP addresses in the Domain Name System [RFC1034]Mockapetris, P., Domain names - concepts and facilities, November 1987., [RFC1035]Mockapetris, P., Domain names - implementation and specification, November 1987. with labels meaning
and therefore give receiving MTAs a hint as whether to accept messages from the sending MTA or not.
This document describes such a mechanism that
While this document specializes on SMTP the technique used in this proposal is not limited to SMTP, but can be adopted by any service and is easily extensible.
One of the big advantages of using the reverse DNS tree instead of the forward tree is that it is much harder for spammers to get accreditation records into the reverse tree than to add them to the forward domain, which is completely under their control.
The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC2119 [RFC2119]Bradner, S., Key words for use in RFCs to Indicate Requirement Levels, March 1997..
| TOC |
Storing arbitrary string attributes in the Domain Name System [RFC1464]Rosenbaum, R., Using the Domain Name System To Store Arbitrary String Attributes, May 1993. is a technique described and used at least since 1993. One solution that we took into consideration has been to store string attributes like "MTA=1" or "MTA=0" at the same level as PTR records.
However this method does not support specific queries and has a high overhead for parsing the responses, is prone to naming collisions and will trigger errors and problems in old implementations of DNS servers with the 512 byte size limit.
Thus we propose expanding the reverse DNS tree with a subdomain with the well known name
_srv
This subdomain MAY be inserted at any level in the DNS tree for IPv4 IN-ADDR.ARPA reverse zones. For IPv6, to limit the number of DNS queries, _srv is only queried at the /128 (host), /64 (subnet) and /32 (site) level. That way it can either provide information for a specific IP address or for a whole network block. More specific information takes precedence over information found closer to the top of the tree.
Within the above "_srv" subdomain there will be another subdomain named after the service for which the specific records will be defined. For SMTP the name of the subdomain will be
_smtp
The symbolic name of the desired service is the same as defined in Assigned Numbers [RFC3232]Reynolds, J., Assigned Numbers: RFC 1700 is Replaced by an On-line Database, January 2002. or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature. The service name is case insensitive. Readers familiar with RFC2782 [RFC2782]Gulbrandsen, A., Vixie, P. and L. Esibov, A DNS RR for specifying the location of services (DNS SRV), February 2000. are already accustomed to that naming scheme.
Whether SMTP message transmissions should be accepted from that host is specified by a TXT record within the service subdomain for the entry
_send
The name "_send" is case insensitive.
The value of the TXT record will be either "1" or "0":
- 1 -
- (MTA=yes) indicates that the connection is originating from an IP address that is intended to be a MTA talking to other MTAs across the public Internet and that the message SHOULD be accepted.
- 0 -
- (MTA=no) indicates that the IP address of the sending communication partner is NOT meant to be an accredited sending MTA and that messages SHOULD NOT be accepted from that connection, unless successful authentification via other methods (e.g. ODMR [RFC2645]Gellens, R., ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses, August 1999.) advise the contrary.
The contact information provides automatic notification of administrators, if hosts within their responsibility get abused or infected by viruses.
Currently there is no easy way to get information about contacts for a given IP address. There are a lot of different sources, where the best are probably the whois databases of the various (Regional Internet Registries (RIR) like ARIN, RIPE, APNIC or LACNIC. However, there is no common agreed upon format for abuse contacts, and for some allocations, referrals have to be followed to other registries like BRNIC or KRNIC, that again use different record formats.
An easy way to specify contact information for a given IP address is to use the Responsible Person (RP) resource record as defined in RFC 1183 [RFC1183]Everhart, C., Mamakos, L., Ullmann, R. and P. Mockapetris, New DNS RR Definitions, October 1990..
Another use of an email address provided with the contact information is the possibility for a MTA to customize the error message [RFC2821]Klensin, J., Simple Mail Transfer Protocol, April 2001., [RFC1893]Vaudreuil, G., Enhanced Mail System Status Codes, January 1996. like in
550-5.7.1 Message rejected. Sender is not labeled a sending MTA.
550 5.7.1 Please contact <abuse@example.com>.
where "abuse@example.com" is derived from the information stored in the RP records.
The RP resource records SHOULD be inserted into the IN-ADDR.ARPA and IP6.ARPA zone at the same level as the "_srv" records.
However, there MAY be more than one contact address for various services involved, so service specific contact information MAY also be provided at the service subdomain level.
Some examples, how records might look like in BIND syntax:
$ORIGIN 0.0.10.IN-ADDR.ARPA.
1 IN PTR mail.example.com.
_send._smtp._srv.1 IN TXT "1"
_smtp._srv.1 IN RP abuse.example.com. .
2 IN PTR www.example.com.
2 IN RP abuse.example.com. .
_send._smtp._srv.2 IN TXT "0"
_smtp._srv.2 IN RP spam.example.com. .
| TOC |
One of the main goals of this proposal has been to limit the impact on existing Internet infrastructure as much as possible.
Putting this proposal in effect will not break existing infrastructure or widely used mechanisms like gatewaying, forwarding and (authenticated) relaying of emails
Deployment of this method is easy and cheap, even in costs of DNS records needed. Unlike other methods like SPF (Sender Policy Framework) or Caller-Id it does not require records to be added for each and every node in a domain, but only one record per mailserver.
An analysis done by Peter Koch in June 2004 has shown that for the DE TLD all DNS MX records of the about 7.6 million second level domains pointed to about 140000 unique IP addresses. About 75% of those had a working reverse mapping.
Each receiving MTA is free to decide how to classify connections from IP addresses without the marks as defined in this document.
However, as a general guideline, we propose a grace period of six months after publication of this document, where missing marks are to be treated with a default of "MTA=yes" and after the grace period missing marks are to be treated as "MTA=no".
Implementors are asked to provide a mechanism for the administrator to easily specify a default behavior for unmarked IP addresses.
MTAs implementing the policy defined in this document should take care to provide mechanisms for the administrators to easily specify a list of "local addresses" which use the receiving MTA as an outgoing relay. The MTA will accept messages from those IP addresses despite them being marked as "MTA=no".
Typically, roaming users or local users from dialin/dynamic IP addresses have "MTA=no" set on the connection to the receiving MTA. The ODMR [RFC2645]Gellens, R., ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses, August 1999. extension to SMTP [RFC2821]Klensin, J., Simple Mail Transfer Protocol, April 2001. specifies a way for roaming users to authenticate themselves to the receiving MTA and validate the connection.
Connections MUST NOT be rejected solely based on a "MTA=no" label before the initiator of the connection had the chance to authenticate.
This proposal is fully compatible with IPv6. The same TXT and RP RRs and lookup mechanisms can be applied to the "IP6.ARPA" zone as well.
Classless IN-ADDR.ARPA delegation [RFC2317]Eidnes, H., de Groot, G. and P. Vixie, Classless IN-ADDR.ARPA delegation, March 1998. SHOULD be implemented using DNAMEs. As DNAME is not currently supported by all the nameservers a parallel set of CNAME records SHOULD be generated.
| TOC |
This proposal concentrates on labeling SMTP servers. However the principle is generic and can be used for other services, too.
Other entries in the service subdomain like e.g. "_key" can be used to store the public key the MTA at that IP address uses for authentication or signing of messages.
While this document specifies the mechanisms for the reverse DNS tree the same labeling scheme can also be used within other domains. Accreditation systems can use this technique to store multiple information for an IP address or a network block within one (sub-)domain.
| TOC |
The problem with a new DNS RR (and one reason why we try to avoid it) is the resulting need to modify all kinds of DNS software. DNS servers, DNS resolvers and - probably the strongest argument against - ISP management software. Internet Service Providers do not edit zone files with an editor. They have a database and a GUI of some sort that is capable handling all kinds of "well known" RRs.
We had quick, easy and cheap adoption in mind and if all ISP management software has to be changed to make use of the new RR, it will either take a long time or will never happen. TXT and RP records are well understood for years.
| TOC |
The IANA already maintains the registry for service names [RFC3232]Reynolds, J., Assigned Numbers: RFC 1700 is Replaced by an On-line Database, January 2002. that are used to name the service subdomain proposed. No other IANA services are required by this document.
| TOC |
The authors believe that this specification does not cause any new security problems.
The same security issues apply as to other DNS based services.
Probably the worst case scenario is hijacking of a part of the reverse DNS zone and modification of the special TXT record defined in this document to "MTA=no" to block email sending capabilities for hosts with that IP addresses.
| TOC |
| TOC |
| Markus Stumpf | |
| SpaceNet AG | |
| Joseph-Dollinger-Bogen 14 | |
| Muenchen, 80807 | |
| DE | |
| Phone: | +49 89 32356-0 |
| Fax: | +49 89 32356-299 |
| EMail: | maex-rfc@space.net |
| URI: | http://www.space.net/ |
| Steff Hoehne | |
| SpaceNet AG | |
| Joseph-Dollinger-Bogen 14 | |
| Muenchen, 80807 | |
| DE | |
| Phone: | +49 89 32356-0 |
| Fax: | +49 89 32356-299 |
| EMail: | steff-rfc@space.net |
| URI: | http://www.space.net/ |
| TOC |
The authors gratefully acknowledge the contributions of: Christian Brunner, Gert Doering and Sebastian von Bomhard, Elmar Bartel also for some good hints that should plate our English, Mark Andrews, Arnt Gulbrandsen, Peter Koch, Scott Nelson, and all the members of the RIPE Antispam list, the IRTF ASRG and a lot of our net.friends for their comments and input.
Our sincere thanks go to Yakov Shafranovich, one of the chairs of the IRTF ASRG, who always was willing to help. His dedication formed the IRTF ASRG into a productive group and set the stage for successfully addressing the spam problem.
A big 'Thank You' goes also to Marshall T. Rose for the wonderful xml2rfc.
| TOC |
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.
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 (C) The Internet Society (2005). 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.
Funding for the RFC Editor function is currently provided by the Internet Society.