One document matched: draft-danisch-dns-rr-smtp-00.txt
INTERNET-DRAFT Hadmut Danisch
Category: Experimental Dec 2002
Expires: Jun 3, 2003
A DNS RR for simple SMTP sender authentication
draft-danisch-dns-rr-smtp-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
This memo suggests a new DNS RR type to provide a very simple
scheme of domain name authentication for SMTP mails based on sender
IP address authorization.
Danisch Experimental [Page 1]
INTERNET-DRAFT DNS RMX RR Dec 2002
Table of Contents
1. Threat description . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 3
1.2. SPAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem analysis . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Shortcomings of strong authentication mechanisms . . . . . . . . 3
4. DNS based sender address verification . . . . . . . . . . . . . 4
4.1. Suggested method . . . . . . . . . . . . . . . . . . . . . 4
4.2. Simple approach . . . . . . . . . . . . . . . . . . . . . 4
4.3. APL RR based approach . . . . . . . . . . . . . . . . . . 4
5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Compatibility with old mail receivers . . . . . . . . . . 5
5.2. Compatibility with old mail senders . . . . . . . . . . . 5
5.3. Compatibility with old DNS clients . . . . . . . . . . . . 5
5.4. Compatibility with old DNS servers . . . . . . . . . . . . 5
6. Enforcement policy . . . . . . . . . . . . . . . . . . . . . . . 5
Security Considerations . . . . . . . . . . . . . . . . . . . . . . 6
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Danisch Experimental [Page 2]
INTERNET-DRAFT DNS RMX RR Dec 2002
1. Threat description
1.1. Mail sender forgery
Security surveillances found a significant increase in the number
of e-mails with forged sender addresses. As a consequence, damage
caused by such e-mails increased as well. In the majority of
examined e-mails the domain name of the envelope sender address was
forged, and the e-mail was sent from an IP address which does not
belong to a network used by the actual owner of the domain.
1.2. SPAM
A common and well known problem is the dramatic increase of
unsolicited e-mail, commonly called "SPAM". Again, the majority of
examined e-mails had forged sender addresses. The abused domains
were mainly those of common webmailers as hotmail or yahoo, or
well-known companies.
2. Problem analysis
The real cause for forged e-mail is the lack of the Simple Mail
Transfer Protocol SMTP[1] to provide any kind of sender
authentication, authorisation, or verification. Efforts have been
made to block such e-mails by requiring the sender address domain
part to be resolvable (e.g. latest sendmail configurations). This
method provides protection from e-mails with non-existing sender
domains, and indeed, for some time it blocked most SPAM e-mails.
However, since attackers and SPAM senders began to abuse existing
domain names, this method was rendered ineffective.
3. Shortcomings of strong authentication mechanisms
Without any doubt, SMTP needs to be improved and reengineered in
the future in order to resist against these kinds of threat.
Cryptographical or organisational security mechanisms have to be
designed an implemented for some sort of SMTPng.
Unfortunately, it is impossible to seamlessly switch to a new
protocol, since most of the SMTP servers and client programs can't
be replaced or updated easily and quickly. Any kind of security
mechanism has to be simple and backward compatible in order to be
accepted. That's why extensions like SMTP with TLS are not widely
spread.
Danisch Experimental [Page 3]
INTERNET-DRAFT DNS RMX RR Dec 2002
4. DNS based sender address verification
4.1. Suggested method
To gain at least some improvement in e-mail authenticity while
keeping as much SMTP compatibility as possible, a method is
suggested which doesn't change SMTP at all.
When the sender has issued the "MAIL FROM:" SMTP command, the
receiving mail transfer agent (MTA) can - and modern MTAs do -
perform some authorization checks, e.g. run a local rule database
or check whether the sender domain is resolvable.
The suggested method is to let the DNS server for the sender domain
provide informations about which IP addresses are authorized to use
the domain within a sender's address. After receiving the "MAIL
FROM:" SMTP command, the receiving MTA can verify, whether the IP
address of the sending MTA is authorized to send mails with this
domain name. Therefore, a list of authorized IP addresses is
provided by the authoritative DNS server of that domain.
This is some kind of "reverse MX record", therefore it is
temporarily called "RMX", until a better name is found.
4.2. Simple approach
The RMX records for a domain could simply contain a list of network
addresses and masks to define IP address ranges, which are allowed
to use that domain, e.g.
@ IN RMX 213.133.101.23/32
@ IN RMX 1.2.3.0/24
4.3. APL RR based approach
The simple approach described above explains the method, but ends
up in reinventing what already has been invented. Keeping address
lists in DNS records was already defined in RFC 3123 [2] Therefore,
instead of reinventing address ranges, we should use APL records.
Here, an RMX record would contain a list of DNS names, which
finally resolve to APL records. Mail is accepted if the sender IP
address belongs to one of the listed networks. A configuration
could look like this:
danisch.de. IN RMX ( relays.danisch.de )
relays.danisch.de. IN APL ( 1:213.133.101.23/32 1:1.2.3.0/24 )
where the machine with the example address 213.133.101.23 and the
Danisch Experimental [Page 4]
INTERNET-DRAFT DNS RMX RR Dec 2002
machines in the example subnet 1.2.3.0/24 are the only machines
allowed to send e-mails with an envelope sender address of domain
danisch.de. Since the APL records do not necessarily belong to the
same domain or zone table as the RMX records, this easily allows to
refer to APL records defined by someone else, e.g. the internet
access or server hosting provider, thus reducing administrative
overhead to a minimum.
5. Compatibility
5.1. Compatibility with old mail receivers
Since the suggested extension doesn't change the SMTP protocol at
all, it is fully compatible with old mail receivers. They simply
don't ask for the RMX records and don't perform the check.
5.2. Compatibility with old mail senders
Since the SMTP protocol is unchanged and the SMTP sender is not
involved in the check, the method is fully compatible with old mail
senders.
5.3. Compatibility with old DNS clients
Since the RMX is a new RR, the existing DNS protocol and zone
informations remain completely untouched.
5.4. Compatibility with old DNS servers
If a server can't provide RMX records or a zone doesn't contain
them, the check can't be performed, while compatibility is still
guaranteed.
6. Enforcement policy
Obviously, for reasons of backward compatibility and smooth
introduction of this scheme, RMX records can't be required
immediately. Domains without RMX records must temporarily be
treated the same way as they are treated right now, i.e. e-mail
must be accepted from anywhere. But once the scheme becomes
sufficiently widespread, mail relays can start to refuse e-mails
with sender addresses from domains without RMX records, thus
forcing the owner of the domain to include a statement of
authorization into the domain's zone table. Domain owners will
still be free to have an RMX record with a network and mask
0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere.
On the other hand, mail receivers will be free to refuse mails from
domains without RMX records or RMX records which are too loose.
Danisch Experimental [Page 5]
INTERNET-DRAFT DNS RMX RR Dec 2002
Advanced MTAs might have a configuration option to set the maximum
number of IP addresses authorized to use a domain. E-mails from a
domain, which's RMX records exceed this limit, would be rejected.
For example, a relay could reject e-mails from domains which
authorize more than 8 IP addresses. That allows to accept e-mails
only from domains with a reasonable security policy.
Security Considerations
It is important to stress, that the suggested method does not
provide high level security and does not completely block forged e-
mails or SPAM. It is not a reliable and completely secure security
mechanism. It is to be considered as a very cheap and simple
lightweight mechanism, which can provide at least some improvement
in mail security against a certain class of attacks, until a
successor of SMTP has been defined and commonly accepted.
References
1. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).
2. P. Koch, "A DNS RR Type for Lists of Address Prefixes (APL RR),"
RFC 3123 (June 2001).
Author's Address
Hadmut Danisch
Tennesseeallee 58
76149 Karlsruhe
Germany
Phone: ++49-721-843004
E-Mail: rfc@danisch.de
Comments
Please send comments to rfc@danisch.de.
Expiry
This drafts expires on Jun 3, 2003
Danisch Experimental [Page 6]
| PAFTECH AB 2003-2026 | 2026-04-23 20:17:38 |