1961 lines
82 KiB
Plaintext
1961 lines
82 KiB
Plaintext
|
||
|
||
|
||
INTERNET-DRAFT Hadmut Danisch
|
||
Category: Experimental Oct 2003
|
||
Expires: Apr 1, 2004
|
||
|
||
The RMX DNS RR and method for lightweight SMTP sender authorization
|
||
draft-danisch-dns-rr-smtp-03.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 introduces a new authorization scheme for SMTP e-mail
|
||
transport. It is designed to be a simple and robust protection
|
||
against e-mail fraud, spam and worms. It is based solely on
|
||
organisational security mechanisms and does not require but still
|
||
allow use of cryptography. This memo also focuses on security and
|
||
privacy problems and requirements in context of spam defense. In
|
||
contrast to prior versions of the draft a new RR type is not
|
||
required anymore.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 1]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
Table of Contents
|
||
|
||
|
||
1. General Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||
2. Problem and threat description . . . . . . . . . . . . . . . . . 4
|
||
2.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4
|
||
2.1.1 Definition of sender forgery . . . . . . . . . . . 4
|
||
2.1.2 Spam . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
2.1.3 E-Mail Worms . . . . . . . . . . . . . . . . . . . 5
|
||
2.1.4 E-Mail spoofing and fraud . . . . . . . . . . . . . 5
|
||
2.2. Indirect damage caused by forgery . . . . . . . . . . . . 6
|
||
2.3. Technical problem analysis . . . . . . . . . . . . . . . . 6
|
||
2.4. Shortcomings of cryptographical approaches . . . . . . . . 7
|
||
3. A DNS based sender address verification . . . . . . . . . . . . 7
|
||
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||
3.2. Envelope vs. header sender address . . . . . . . . . . . . 9
|
||
3.3. Domain part vs. full sender address . . . . . . . . . . . 9
|
||
4. Mapping of E-Mail addresses to DNS names . . . . . . . . . . . . 10
|
||
4.1. Domain part only . . . . . . . . . . . . . . . . . . . . . 10
|
||
4.2. Full address . . . . . . . . . . . . . . . . . . . . . . . 11
|
||
4.3. Empty address . . . . . . . . . . . . . . . . . . . . . . 11
|
||
5. Mandatory entry types and their syntax . . . . . . . . . . . . . 11
|
||
5.1. Overall structure . . . . . . . . . . . . . . . . . . . . 11
|
||
5.2. Unused . . . . . . . . . . . . . . . . . . . . . . . . . . 12
|
||
5.3. IPv4 and IPv6 address ranges . . . . . . . . . . . . . . . 12
|
||
5.4. DNS Hostname . . . . . . . . . . . . . . . . . . . . . . . 13
|
||
5.4.1 Road warriors and DynDNS entries . . . . . . . . . 13
|
||
5.5. APL Reference . . . . . . . . . . . . . . . . . . . . . . 14
|
||
5.6. Domain Member . . . . . . . . . . . . . . . . . . . . . . 14
|
||
5.7. Full Address Query . . . . . . . . . . . . . . . . . . . . 15
|
||
5.8. DNS mapped authorization . . . . . . . . . . . . . . . . . 15
|
||
5.9. RMX reference . . . . . . . . . . . . . . . . . . . . . . 16
|
||
6. Optional and experimental entry types . . . . . . . . . . . . . 16
|
||
6.1. TLS fingerprint . . . . . . . . . . . . . . . . . . . . . 16
|
||
6.2. TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . . 16
|
||
6.3. PGP or S/MIME signature . . . . . . . . . . . . . . . . . 16
|
||
6.4. Transparent Challenge/Response . . . . . . . . . . . . . . 17
|
||
6.5. SASL Challenge/Response . . . . . . . . . . . . . . . . . 17
|
||
7. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
|
||
7.1. Alternative encoding as TXT records . . . . . . . . . . . 17
|
||
7.2. RMX Records . . . . . . . . . . . . . . . . . . . . . . . 17
|
||
7.2.1 Overall structure . . . . . . . . . . . . . . . . . 18
|
||
7.2.2 Record encoding . . . . . . . . . . . . . . . . . . 18
|
||
7.2.3 Encoding of IPv4 and IPv6 address ranges . . . . . 18
|
||
7.2.4 Encoding of DNS . . . . . . . . . . . . . . . . . . 18
|
||
7.2.5 Encoding of unused and full query . . . . . . . . . 19
|
||
7.2.6 Additional Records . . . . . . . . . . . . . . . . 19
|
||
8. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 19
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 2]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
9. SMTP error messages . . . . . . . . . . . . . . . . . . . . . . 20
|
||
10. Message relaying and forwarding . . . . . . . . . . . . . . . . 20
|
||
10.1. Problem description . . . . . . . . . . . . . . . . . . . 20
|
||
10.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 21
|
||
10.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 21
|
||
11. Security Considerations . . . . . . . . . . . . . . . . . . . . 22
|
||
11.1. Draft specific considerations . . . . . . . . . . . . . . 22
|
||
11.1.1 Authentication strength . . . . . . . . . . . . . 22
|
||
11.1.2 Where Authentication and Authorization end . . . . 22
|
||
11.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 23
|
||
11.1.4 Sneaking RMX attack? . . . . . . . . . . . . . . 25
|
||
11.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 25
|
||
11.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 25
|
||
11.1.7 Reliability of Whois Entries . . . . . . . . . . . 26
|
||
11.1.8 Hazards for Freedom of Speech . . . . . . . . . . 26
|
||
11.2. General Considerations about spam defense . . . . . . . . 27
|
||
11.2.1 Action vs. reaction . . . . . . . . . . . . . . . 27
|
||
11.2.2 Content based Denial of Service attacks . . . . . 27
|
||
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 28
|
||
12.1. Draft specific considerations . . . . . . . . . . . . . . 28
|
||
12.1.1 No content leaking . . . . . . . . . . . . . . . . 28
|
||
12.1.2 Message reception and sender domain . . . . . . . 28
|
||
12.1.3 Network structure . . . . . . . . . . . . . . . . 29
|
||
12.1.4 Owner information distribution . . . . . . . . . . 29
|
||
12.2. General Considerations about spam defense . . . . . . . . 29
|
||
12.2.1 Content leaking of content filters . . . . . . . . 29
|
||
12.2.2 Black- and Whitelists . . . . . . . . . . . . . . 30
|
||
13. Deployment Considerations . . . . . . . . . . . . . . . . . . . 30
|
||
13.1. Compatibility . . . . . . . . . . . . . . . . . . . . . . 30
|
||
13.1.1 Compatibility with old mail receivers . . . . . . 30
|
||
13.1.2 Compatibility with old mail senders . . . . . . . 30
|
||
13.1.3 Compatibility with old DNS clients . . . . . . . . 30
|
||
13.1.4 Compatibility with old DNS servers . . . . . . . . 30
|
||
13.2. Enforcement policy . . . . . . . . . . . . . . . . . . . 31
|
||
14. General considerations about fighting spam . . . . . . . . . . 31
|
||
14.1. The economical problem . . . . . . . . . . . . . . . . . 31
|
||
14.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 32
|
||
14.3. The network structure problem . . . . . . . . . . . . . . 33
|
||
14.4. The mentality problem . . . . . . . . . . . . . . . . . . 33
|
||
14.5. The identity problem . . . . . . . . . . . . . . . . . . 33
|
||
14.6. The multi-legislation problem . . . . . . . . . . . . . . 34
|
||
Implementation and further Information . . . . . . . . . . . . . . . 34
|
||
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
|
||
Draft History . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
|
||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 35
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 3]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
1. General Issues
|
||
|
||
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. Problem and threat description
|
||
|
||
2.1. Mail sender forgery
|
||
|
||
The amount of e-mails with forged sender addresses has dramatically
|
||
increased. As a consequence, damages and annoyances 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.
|
||
|
||
2.1.1. Definition of sender forgery
|
||
|
||
As discussions, comments to prior versions of this draft, and
|
||
different approaches to stop forgery showed, different perceptions
|
||
of "mail forgery" exist. For example, there are mechanisms to
|
||
verify e-mail addresses for mailing lists, web servers, or to stop
|
||
spam, which do send a message with a random number to the given
|
||
address and expect the user to send a reply. Here, someone is
|
||
considered to be allowed to use a particular e-mail address, if and
|
||
only if he is able to receive informations sent to this address,
|
||
and is able to reply to such a message. While this definition
|
||
appears to be quite plausible and natural, it can't be used for a
|
||
simple technical solution. Sending back a challenge and expecting a
|
||
reply is simply too much overhead and time delay, and not every
|
||
authorized sender is able or willing to reply (e.g. because he went
|
||
offline or is not a human).
|
||
|
||
Within the scope of this memo, sender forgery means that the
|
||
initiator of an e-mail transfer (which is the original sender in
|
||
contrast to relays) uses a sender address which he was not
|
||
authorized to use. Being authorized to use an address means that
|
||
the owner (administrator) of the internet domain has given
|
||
permission, i.e. agrees with the use of the address by that
|
||
particular sender. This memo will cover both the permission of the
|
||
full e-mail address and the domain part only for simplicity.
|
||
|
||
Within context of Internet and SMTP, the sender address usually
|
||
occurs twice, once as the envelope sender address in SMTP, and once
|
||
as the address given in the RFC822 mail header. While the following
|
||
considerations apply to both addresses in principle, it is
|
||
important to stress that both addresses have distinct semantics and
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 4]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
are not neccessarily the same. The envelope address identifies the
|
||
initiator of the transport, while the header identifies the author
|
||
of the message content. Since this memo deals with the message
|
||
transport only and completely ignores the message content, the
|
||
method should naturally be applied to the envelope sender address.
|
||
|
||
2.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.
|
||
|
||
Unfortunately, there is no accurate definition of spam availabe
|
||
yet, and neither are the concise technical criterions to filter or
|
||
block spam with technical mechanisms. There are efforts to design
|
||
content based filters, but these filters are expensive in
|
||
calculation time (and sometimes money), and they do not reliably
|
||
provide predictable results. Usually they give false positives
|
||
and/or require user interaction. Content filters in general suffer
|
||
from a design problem described later in this memo. Therefore,
|
||
this proposal does not use the content based approach to block
|
||
spam.
|
||
|
||
As analysis of spam messages showed, most of spam messages were
|
||
sent with forged envelope sender addresses. This has mainly three
|
||
reasons. The first reason is, that spam senders usually do not
|
||
want to be contacted by e-mail. The second reason is, that they do
|
||
not want to be blacklisted easily. The third reason is, that spam
|
||
is or is going to be unlawful in many countries, and the sender
|
||
does not want to reveal his identity. Therefore, spam is considered
|
||
to be a special case of sender forgery.
|
||
|
||
2.1.3. E-Mail Worms
|
||
|
||
Another example of sender forgery is the reproduction of e-mail
|
||
worms. Most worms do choose random sender addresses, e.g. using
|
||
the addresses found in mailboxes on the infected system. In most
|
||
cases analyzed by the author, the e-mails sent by the reproduction
|
||
process can also be categorized as forged, since the infected
|
||
system would under normal circumstances not be authorized to send
|
||
e-mails with such e-mail addresses. So forgery does not require a
|
||
malicious human to be directly involved. This memo covers any kind
|
||
of e-mail sender address forgery, included those generated by
|
||
malicious software.
|
||
|
||
2.1.4. E-Mail spoofing and fraud
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 5]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
Forging e-mail sender addresses for fraud or other kinds of
|
||
deception ("human engineering") has also dramatically increased.
|
||
There are many known cases where single or mass e-mails were sent
|
||
with wrong sender addresses, pretending to come from service
|
||
provider, software manufacturers etc., and asking the receiver to
|
||
install any software or patches, or to reply with any confidential
|
||
information. The Internet is becoming more and more a scene of
|
||
crime, and so are it's services, including e-mail. It is obvious
|
||
that crime based on e-mail is eased by the fact that SMTP allows
|
||
arbitrary sender address spoofing.
|
||
|
||
2.2. Indirect damage caused by forgery
|
||
|
||
As observed by the author, mass mails and worms with forged sender
|
||
addresses can cause a severe damage for the real owner of the
|
||
abused sender addresses. If a sender A is sending an e-mail to the
|
||
receiver B, pretending to be C by using a sender address of C's
|
||
domain, then C has currently no chance to prevent this, since C's
|
||
machines and software are not involved in any way in the delivery
|
||
process between A and B. B will nevertheless send any error
|
||
messages (virus/spam alert, "no such user", etc.) to C, erroneously
|
||
assuming that the message was sent by C. The author found several
|
||
cases where this flood of error messages caused a severe denial of
|
||
service or a dramatic increase of costs, e.g. when C was
|
||
downloading the e-mail through expensive or low bandwidth
|
||
connections (e.g. modem or mobile phones), or where disk space was
|
||
limited. The author examined mass mailings, where several tens or
|
||
hundreds of thousands of messages were sent to several addresses
|
||
around the world, where these messages caused only annoyance. But
|
||
since several thousands of these addresses were invalid or didn't
|
||
accept the message, the owner of the DNS domain which was abused by
|
||
the spammer to forge sender addresses was flooded for several
|
||
months with thousands of error messages, jamming the e-mail system
|
||
and causing severe costs and damages.
|
||
|
||
As a consequence, when A sends a message to B, pretending to be C,
|
||
there must be any mechanism to allow C to inform B about the fact,
|
||
that A is not authorized to use C as a sender address. This is what
|
||
this memo is about.
|
||
|
||
2.3. Technical problem analysis
|
||
|
||
Why does e-mail forgery actually exist? Because of the lack of the
|
||
Simple Mail Transfer Protocol SMTP[2] to provide any kind of sender
|
||
authentication, authorisation, or verification. This protocol was
|
||
designed at a time where security was not an issue. Efforts have
|
||
been made to block forged e-mails by requiring the sender address
|
||
domain part to be resolvable. This method provides protection from
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 6]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
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.
|
||
|
||
2.4. Shortcomings of cryptographical approaches
|
||
|
||
At a first glance, the problem of sender address forgery might
|
||
appear to be solvable with cryptographic methods such as challenge
|
||
response authentications or digital signatures. A deeper analysis
|
||
shows that only a small, closed user group could be covered with
|
||
cryptographical methods. Any method used to stop spam forgery must
|
||
be suitable to detect forgery not only for a small number of
|
||
particular addresses, but for all addresses on the world. An
|
||
attacker does not need to know the secrets belonging to a
|
||
particular address. It is sufficient to be able to forge any
|
||
address and thus to know any secret key. Since there are several
|
||
hundreds of millions of users, there will always be a large amount
|
||
of compromised keys, thus spoiling any common cryptographic method.
|
||
Furthermore, cryptography has proven to be far too complicated and
|
||
error prone to be commonly administered and reliably implemented.
|
||
Many e-mail and DNS administrators do not have the knowledge
|
||
required to deal with cryptographic mechanisms. Many legislations
|
||
do not allow the general deployment of cryptography and a directory
|
||
service with public keys. For these reasons, cryptography is
|
||
applicable only to a small and closed group of users, but not to
|
||
all participants of the e-mail service.
|
||
|
||
3. A DNS based sender address verification
|
||
|
||
3.1. Overview
|
||
|
||
To gain improvement in e-mail authenticity while keeping as much
|
||
SMTP compatibility as possible, a method is suggested which doesn't
|
||
change SMTP at all.
|
||
|
||
The idea is to store informations about how to verify who is
|
||
authorized to transmit e-mails through SMTP with a particular
|
||
sender address (either full address or - for simplicity - only the
|
||
domain part of the address) in a directory service, which is
|
||
currently the DNS. To be precise, the verification consists of two
|
||
steps, the classical pair of authentication and authorization:
|
||
|
||
The first step is the authentication. While several methods are
|
||
possible to perform authentication (see below), the most important
|
||
and robust method is the verification of the sender's IP address.
|
||
This is done implicitely by TCP/IP and the TCP sequence number. The
|
||
authenticated identity is the IP address. It has to be stressed
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 7]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
that this TCP/IP "authentication" is a weak authentication and
|
||
vulnerable to several attacks. It is nevertheless sufficient for
|
||
this purpose, especially for blocking spam. It doesn't take any
|
||
implementation and it doesn't cost: It is already there, it is a
|
||
functionality of TCP/IP. An incoming SMTP connection based on
|
||
TCP/IP already carries the sender's IP address without any
|
||
modification of SMTP. See below (section Entry types) for more
|
||
details about authentication methods.
|
||
|
||
The second step is the authorization. It is based on the identity
|
||
given by the previous authentication step, e.g. the IP address of
|
||
the originator of the incoming SMTP connection, and on the
|
||
envelope sender address. The mechanism proposed in this memo
|
||
answers the question "Is that particular sender (IP address,...)
|
||
allowed to send with that sender address" by querying and
|
||
processing informations stored in a directory service, which is
|
||
DNS.
|
||
|
||
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 who - this means for example which IP
|
||
address - is authorized to use an address or a domain as a part of
|
||
it. After receiving the "MAIL FROM:" SMTP command, the receiving
|
||
MTA can verify, whether e. g. the IP address of the sending MTA is
|
||
authorized to send mails with this domain name. Therefore, a list
|
||
of entries with authorized IP addresses or other informations is
|
||
provided by the authoritative DNS server of that domain. The entry
|
||
types are described in the subsequent chapters. Some of these
|
||
methods are
|
||
|
||
- An IPv4 or IPv6 network address and mask
|
||
- A fully qualified domain name referring to an A record
|
||
- A fully qualified domain name referring to an APL record
|
||
|
||
RMX records of these types would look like this:
|
||
|
||
somedomain.de. IN RMX ipv4:10.0.0.0/8
|
||
rmxtest.de. IN RMX host:relay.provider.com
|
||
danisch.de. IN RMX apl:relays.rackland.de
|
||
relays.rackland.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
|
||
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
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 8]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
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. In the example given above, the domain
|
||
danisch.de and several other domains are hosted by the service
|
||
provider Rackland. So if the relay structure of Rackland is
|
||
modified, only the zone of rackland.de needs to be modified. The
|
||
domain owners don't need to care about such details.
|
||
|
||
3.2. Envelope vs. header sender address
|
||
|
||
Questions were raised why the proposed mechanism is based on the
|
||
envelope sender address, and not on the sender address given in the
|
||
message header. Technically, both can be used. Actually, it makes
|
||
sense to use the envelope address.
|
||
|
||
In common, the header sender address identifies the author of the
|
||
content, while the envelope sender tells who caused the
|
||
transmission. The approach proposed in this memo is transmission
|
||
based, not content based. We can not authorize the author of a
|
||
message if we don't have contact with him, if the message does not
|
||
already contain a signature. In contrast, the sending MTA is linked
|
||
to an IP address which can be used for authentication. This
|
||
mechanism might not be very strong, but it is available and
|
||
sufficient to solve today's e-mail security problems.
|
||
|
||
Some people argued that it is the header address and not the sender
|
||
address, which is displayed in common mail readers (MUAs), and
|
||
where the receiver believes the mail comes from. That's true, but
|
||
it doesn't help. There are many cases where the header sender
|
||
differs from the envelope sender for good reasons (see below in the
|
||
consequences chapter for the discussion about relaying). Relaying,
|
||
mailing lists etc. require to replace the sender address used for
|
||
RMX. If this were the header address, the message header would have
|
||
to be modified. This is undesirable.
|
||
|
||
3.3. Domain part vs. full sender address
|
||
|
||
Former versions of this draft were limited to the domain part of
|
||
the sender address. The first reason is that it is common and MX-
|
||
like, to lookup only the domain part of an e-mail address in DNS.
|
||
The second reason is, that it was left to the private business of
|
||
the domain administration to handle details of user verification.
|
||
The idea was that the domain administration takes care to verify
|
||
the left part of an e-mail address with an arbitrary method of
|
||
their individual taste. RMX was originally designed to ignore the
|
||
left part of the address and to expect the domain administration to
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 9]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
take over responsibility for enforcing their policy. If, e.g., a
|
||
spam message arrived and passed the RMX mechanism, it is known to
|
||
be authorized by the domain administration and they can be blamed,
|
||
no matter what is on the left side of the sender address - it's
|
||
their private problem what happens on the left side of the @. By
|
||
far the most of the comments to prior versions of this draft agreed
|
||
with that. A few comments asked for a finer granularity.
|
||
|
||
And indeed, there is no technical reason against a finer
|
||
granularity. All it takes is a mapping from a given envelope
|
||
sender address to a DNS name, and the RMX lookup for that
|
||
particular e-mail address could be done instead of a lookup for the
|
||
domain part only. However, to my knowledge, most domain
|
||
administrators would not like to provide an RMX entry for every
|
||
single e-mail address. In many cases, this would also overload DNS
|
||
servers.
|
||
|
||
It is to be discussed how to cover both views. One method could be
|
||
to query the full address, and if no RMX records were found to
|
||
query the domain part only. A different approach would be to query
|
||
the domain part only, and if it's RMX record contain a special
|
||
entry, then a new query for the full address is triggered. A third
|
||
way would be to always query the full address and to leave the
|
||
problem to the wildcard mechanism of DNS. This still has to be
|
||
discussed and will be described in future versions of this draft.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
4. Mapping of E-Mail addresses to DNS names
|
||
|
||
To perform the RMX query, a mapping is needed from E-Mail addresses
|
||
to DNS fully qualified domain names.
|
||
|
||
This chapter is under development and just a first approach.
|
||
|
||
4.1. Domain part only
|
||
|
||
Mapping of the domain part is trivial, since the domain part of an
|
||
e-mail address itself is a valid DNS name and does not need
|
||
translation. It might be nevertheless desirable to distinguish the
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 10]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
RMX entries from other entries, depending of the encoding of the
|
||
records. If the RMX entries are encoded in TXT record types, they
|
||
might collide with other uses of TXT records. It might be
|
||
necessary to prepend the domain part with a special prefix, e.g.
|
||
_rmx. So the e-mail address some.user@example.com could be mapped
|
||
to example.com or _rmx.example.com.
|
||
|
||
4.2. Full address
|
||
|
||
Mapping a full address is slightly more difficult. The @ sign must
|
||
be unambiguously translated, and therefore can not be simply
|
||
translated into a dot. The e-mail addresses some.user@example.com
|
||
and some@user.example.com must have different mappings. Therefore,
|
||
the @ sign could be translated into _rmx, implicitely assuming that
|
||
this is not an allowed domain name component of normal domain
|
||
names. Then the rightmost _rmx in the mapped DNS name always
|
||
corresponds to the @ sign. some.user@example.com would e translated
|
||
into some.user._rmx.example.com and can be covered by a wildcard
|
||
entry like *._rmx.example.com.
|
||
|
||
Character encoding and character sets are still to be discussed.
|
||
|
||
4.3. Empty address
|
||
|
||
Unfortunately, SMTP allows empty envelope sender addresses to be
|
||
used for error messages. Empty sender addresses can therefore not
|
||
be prohibited. As observed, a significant amount of spam was sent
|
||
with such an empty sender address. To solve this problem, the host
|
||
name given in the HELO or EHLO command is taken to lookup the RMX
|
||
records instead. This makes sense, since such messages were
|
||
generated by the machine, not a human.
|
||
|
||
|
||
|
||
|
||
5. Mandatory entry types and their syntax
|
||
|
||
The entry types described in this section MUST be supported by any
|
||
implementation of this draft.
|
||
|
||
5.1. Overall structure
|
||
|
||
Similar to APL, an RMX record is just a concatenation of zero or
|
||
more RMX entries. The entries within one record form an ordered
|
||
rule base as commonly usual in packet filtes and firewall rulesets,
|
||
i. e. they are processed one ofter another until the first entry
|
||
matches. This entry determines the result of the query. Once a
|
||
matching entry is found, the RMX processing is finished.
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 11]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
For any domain name there should not exist more than a single RMX
|
||
record. Due to the structure of DNS, it is nevertheless possible to
|
||
have more than a single RMX record. Multiple RMX records are
|
||
treated as a single record consisting of the concatenation of all
|
||
records. While the entries in a record are ordered, the records are
|
||
not ordered and may be processed in arbitrary order. If the order
|
||
of the entries matters, it is the zone maintainer's responsibility
|
||
to keep those entries in a single record. For example, there are
|
||
negative entries, which exclude IP addresses from authorization.
|
||
It is important that these entries are processed before positive
|
||
entries giving permission to a wider address range. Since order is
|
||
guaranteed only within a record, corresponding negative and
|
||
positive entries must be put in the same record.
|
||
|
||
An RMX record may consist of one or more entries, where the entries
|
||
are separated by whitespace. An entry must not contain white space.
|
||
Each entry consists of an optional exclamation sign, a tag, a
|
||
colon, and the entry data:
|
||
|
||
[!] TAG : ENTRY-SPECIFIC-DATA
|
||
|
||
If the entry starts with an exclamation sign, the entry is negated.
|
||
See the entry type description below for details.
|
||
|
||
The TAG is the mnemonic type identifier or the decimal number of
|
||
the entry. The TAG is case-insensitive. It is immediately followed
|
||
by a colon.
|
||
|
||
The syntax and semantics of ENTRY-SPECIFIC-DATA depends of the the
|
||
entry type. See description below.
|
||
|
||
Example:
|
||
|
||
danisch.de. IN RMX apl:relays.rackland.de !ipv4:1.2.3.5
|
||
ipv4:1.2.3.0/24
|
||
|
||
5.2. Unused
|
||
|
||
This is a primitive entry which just says that this sender address
|
||
will never be used as a sender address under any circumstances.
|
||
Example:
|
||
|
||
testdomain.danisch.de IN RMX unused:
|
||
|
||
5.3. IPv4 and IPv6 address ranges
|
||
|
||
These entry types contain a bit sequence representing a CIDR
|
||
address part. If that bit sequence matches the given IP address,
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 12]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
authorization is granted or denied, depending on the negation flag.
|
||
|
||
The entry is prepended with the tag "IPv4" or "IPv6". The colon is
|
||
followed with an IPv4 or IPv6 address in standard notation,
|
||
optionally followed by a slash and a mask length. If the negation
|
||
flag is set, then the given address range is excluded. Examples:
|
||
|
||
danisch.de IN RMX ipv4:213.133.101.23 ipv6:fe00::0
|
||
IN RMX ipv4:10.0.0.0/8 ipv6:fec0::0/16
|
||
IN RMX !ipv4:1.2.3.4
|
||
|
||
(Please note that it does not make much sense to use
|
||
RFC1918-Addresses in RMX records, this is just to give a syntax
|
||
example.)
|
||
|
||
|
||
5.4. DNS Hostname
|
||
|
||
This entry type simply contains a regular DNS name, which is to be
|
||
resolved as a host name (fetch the A record or IPv6 equivalent). If
|
||
the given IP address matches the result, authorization is granted
|
||
or denied, depending on the negation flag. It is still to be
|
||
defined how to treat unresolvable entries.
|
||
|
||
The entry is prepended with the tag "host", followed by a colon and
|
||
the hostname. Examples:
|
||
|
||
danisch.de IN RMX host:relay.provider.de
|
||
IN RMX !host:badmachine.domain.de apl:relays.domain.de
|
||
|
||
5.4.1. Road warriors and DynDNS entries
|
||
|
||
Several people argued against RMX that it would break their
|
||
existing installation which delivers e-mail from dynamically
|
||
assigned IP addresses, because their IP providers didn't assign a
|
||
static address, or because they are a road warrior, plugging their
|
||
notebook in any hotel room on the world.
|
||
|
||
RMX provides a simple solution. If such a machine has a dynamically
|
||
updated DNS entry (e.g. DynDNS), all it takes is an RMX entry of
|
||
the hostname type pointing to this dynamic DNS entry.
|
||
|
||
The cleaner solution would be to deliver mail the same way as it is
|
||
received: If downloaded by POP from a central relay with a static
|
||
address, where the MX points to, then it would be a good idea to
|
||
deliver e-mail the same way in reverse direction. Unfortunately,
|
||
plain POP does not support uploading yet.
|
||
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 13]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
5.5. APL Reference
|
||
|
||
This entry type simply contains a regular DNS name, which is to be
|
||
resolved as an APL record index (fetch the APL record). If the
|
||
given IP address positively matches the APL, authorization is
|
||
granted. Details of the semantic (espially when the negation bit is
|
||
set) are still to be defined. It is still to be defined how to
|
||
treat unresolvable entries.
|
||
|
||
The entry is prepended with the tag "host", followed by a colon and
|
||
the hostname. Example:
|
||
|
||
danisch.de IN RMX apl:relays.rackland.de
|
||
|
||
5.6. Domain Member
|
||
|
||
In many cases it is desirable to cover all hosts of a given domain
|
||
with an RMX record without the need to duplicate the list of these
|
||
hosts. This entry type does it (thanks to Eric A. Hall for pointing
|
||
out this entry type). It contains a regular DNS name.
|
||
|
||
If this entry type is given, a reverse DNS query for the IP address
|
||
of the sending MTA is performed to find its official fully
|
||
qualified domain name. To prevent spoofing, this domain name is
|
||
accepted only if a subsequent address query to the given domain
|
||
name points to exactly the IP address of the sending MTA (the usual
|
||
procedure to verify PTR records).
|
||
|
||
The entry matches if the fully qualified domain name of the sending
|
||
MTA ends in the given domain. The negation flag works as usual.
|
||
|
||
The tag for this entry type is "domain". After the colon the domain
|
||
name is given, but might be empty, thus pointing to itself.
|
||
Example:
|
||
|
||
somedomain.org IN RMX domain:somedomain.org domain:provider.com
|
||
|
||
would authorize all machines which's hostname can be verified
|
||
through an PTR and A query, and which ends in "somedomain.org" or
|
||
"provider.com".
|
||
|
||
With such an entry, large companies with different networks can
|
||
easily be covered with just a single and simple RMX entry.
|
||
Obviously, it requires proper PTR records.
|
||
|
||
As a special shortcut, the DNS name may be empty. In this case the
|
||
domain name of the zone itself is taken. Thus, with a very simple
|
||
entry of the type
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 14]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
somecompany.com IN RMX domain:
|
||
|
||
a company could authorize all machines which's IP addresses map to
|
||
DNS names end in somecompany.com, which applies in the majority of
|
||
companies.
|
||
|
||
|
||
|
||
|
||
5.7. Full Address Query
|
||
|
||
As described above, RMX records will in most cases apply to the
|
||
domain part of the sender address. In special cases it might be
|
||
desirable to query the RMX record for a particular address. An RMX
|
||
entry of the Full Address Query type may occur in a domain RMX
|
||
record only. It signals that the RMX record for the full address is
|
||
to be fetched and processed.
|
||
|
||
This entry type does not take arguments. The negation flag is not
|
||
supported. The tag is "full".
|
||
|
||
If such a full address query is to be performed, the mail address
|
||
must be mapped to a valid and non-ambiguos DNS name. This mapping
|
||
is still to be defined. It is not sufficient to simply replace the
|
||
@ with a dot, because of case sensitivity, character sets, etc. The
|
||
e-mail addresses
|
||
|
||
john.doe@example.org
|
||
John.Doe@example.org
|
||
john@doe.example.org
|
||
|
||
must all be mapped to different DNS entries. This entry type might
|
||
vanish in future versions of the draft, depending on the discussion
|
||
about whether to query the domain name part only or the full
|
||
address.
|
||
|
||
5.8. DNS mapped authorization
|
||
|
||
As I learned from comments to prior versions of the draft and from
|
||
alternative proposals, many users wish to have a DNS mapped
|
||
authorization table, i. e. the client queries a DNS entry of the
|
||
form a.b.c.d.domain, where a.b.c.d is the sender's IP address.
|
||
Since people wish to have this, RMX will now include such a mapping
|
||
entry. The entry has a parameter giving the DNS domain name where
|
||
to look at. If the parameter is empty, then the same domain is
|
||
taken as for the RMX lookup.
|
||
|
||
As this is currently under construction and discussion in an IETF
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 15]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
group, details will be published in future versions of this draft.
|
||
|
||
5.9. RMX reference
|
||
|
||
This entry type has no parameters. It means that all those machines
|
||
are authorized, which are pointed to by an MX record.
|
||
|
||
6. Optional and experimental entry types
|
||
|
||
The following subsections roughly describe further entry types
|
||
which might not be supported by all implementations and might not
|
||
be allowed in all legislations. These methods might vanish in
|
||
future versions of the draft and are just considerations about what
|
||
to include in RMX and what to not include. The main purpose of this
|
||
section is to start discussion about such entry types.
|
||
|
||
The disadvantage of the following methods is that they violate the
|
||
basic idea of RMX, i. e. to be simple, robust, easy to implement
|
||
and easy to administer. I personally do not believe that it is a
|
||
good idea or even feasible to implement cryptography for a world
|
||
wide e-mail transfer network. Keep in mind that cryptographic keys
|
||
can be copied. If only <0.1% of cryptographic keys were revealed,
|
||
this completely compromises and spoils RMX. Cryptography is simply
|
||
the wrong tool for the problem RMX is intended to solve. I
|
||
nevertheless like to discuss these methods.
|
||
|
||
6.1. TLS fingerprint
|
||
|
||
The sender is considered to be authorized if the message was
|
||
transmitted through SMTP and TLS, and the sender used a certificate
|
||
matching the fingerprint given in the RMX record.
|
||
|
||
6.2. TLS and LDAP
|
||
|
||
This means that the receiver should perform an LDAP query for the
|
||
sender address (through the LDAP SRV record or given in the RMX
|
||
record), fetch the X.509 certificate for the sender. The sender is
|
||
considered to be authorized when the message was transmitted
|
||
through SMTP and TLS using this certificate.
|
||
|
||
6.3. PGP or S/MIME signature
|
||
|
||
It would be possible to accept a message only if it was signed with
|
||
PGP or S/MIME with a key which's fingerprint is given in the RMX
|
||
record or to be fetched from LDAP or any PGP database. This is
|
||
just for discussion, since it violates the idea of RMX to focus on
|
||
the transport, not on the content. It would also allow replay
|
||
attacks and not cover the envelope sender address or message
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 16]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
header.
|
||
|
||
6.4. Transparent Challenge/Response
|
||
|
||
It would also be possible to implement a challenge-response
|
||
mechanism without modifying the syntax of SMTP. For example, the
|
||
receiving MTA could issue a challenge with it's very first greeting
|
||
message, the sending MTA could hide the response in the HELO
|
||
parameter and when the receiving MTA later learns the sender
|
||
envelope address, it could verify the response based on
|
||
informations in the RMX record.
|
||
|
||
6.5. SASL Challenge/Response
|
||
|
||
Modern SMTP implementations already include a SASL mechanisms,
|
||
which easily allows to plugin new authentication mechanisms. While
|
||
common SASL mechanisms require to use a previously shared password,
|
||
a new mechanism could perform a challenge response authentication
|
||
as a SASL method.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
7. Encoding
|
||
|
||
7.1. Alternative encoding as TXT records
|
||
|
||
The main objection against the prior versions of this draft was
|
||
that it requires a new RR entry type and upgrading all DNS servers.
|
||
|
||
Therefore and alternative encoding is proposed. Instead of using a
|
||
new RR type, the TXT record type is used to contain the RMX record.
|
||
The records would simply look as described in the entry type
|
||
chapters above, e.g.
|
||
|
||
_rmx.danisch.de. IN TXT "apl:relays.rackland.de"
|
||
|
||
To allow smooth introduction of RMX without the need to immediately
|
||
upgrade all DNS servers, all clients (which have to be newly
|
||
installed anyway) MUST support both the TXT and the RMX records. A
|
||
client has to perform an ANY or a TXT and a RMX query. Servers/zone
|
||
tables may currently use TXT entries but SHOULD use RMX entries in
|
||
future.
|
||
|
||
7.2. RMX Records
|
||
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 17]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
7.2.1. Overall structure
|
||
|
||
Each entry starts with an octet containting the entry type and the
|
||
negation flag:
|
||
|
||
+---+---+---+---+---+---+---+---+------
|
||
| N | Entry Type Code | Parameters...
|
||
+---+---+---+---+---+---+---+---+------
|
||
|
||
N If this bit (MSB) is set, an IP address
|
||
matching this entry is not authorized,
|
||
but explicitely rejected. See entry
|
||
type descriptions for details.
|
||
|
||
Entry Type A 7bit number simply determining the entry
|
||
type.
|
||
|
||
|
||
Currently, entries do not have an explicit length field, the entry
|
||
length is determined implicitely by the entry type. Applications
|
||
are required to abort if an unknown entry type is found, instead of
|
||
skipping unknown entries.
|
||
|
||
7.2.2. Record encoding
|
||
|
||
A RMX record is simply a concatenation of RMX entries.
|
||
|
||
7.2.3. Encoding of IPv4 and IPv6 address ranges
|
||
|
||
After the entry type tag as described above, one octet follows
|
||
giving the length L of the bit sequence. Then a sequence of exactly
|
||
as many octets follows as needed to carry L bits of information (=
|
||
trunc((L+7)/8) ).
|
||
|
||
+---+---+---+---+---+---+---+---+
|
||
| N | Entry Type Code (1 or 2) |
|
||
+---+---+---+---+---+---+---+---+
|
||
| Length Field L |
|
||
+---+---+---+---+---+---+---+---+
|
||
| Bit Field |
|
||
/ ((L+7)/8) Octets /
|
||
+---+---+---+---+---+---+---+---+
|
||
|
||
|
||
7.2.4. Encoding of DNS
|
||
|
||
After the entry type tag immediately follows a DNS encoded and
|
||
compressed [3] domain name.
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 18]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
+---+---+---+---+---+---+---+---+
|
||
| N | Entry Type Code (3..5) |
|
||
+---+---+---+---+---+---+---+---+
|
||
| Length Field L |
|
||
+---+---+---+---+---+---+---+---+
|
||
| Encoded DNS |
|
||
/ Name as described in RFC1035 /
|
||
+---+---+---+---+---+---+---+---+
|
||
|
||
In contrast to earlier versions of this draft, the DNS name cannot
|
||
be compressed, since this would cause decompression errors when a
|
||
DNS server is part of the query chain which does not know this
|
||
particular RR type.
|
||
|
||
7.2.5. Encoding of unused and full query
|
||
|
||
These entries do not contain parameters and does not allow the
|
||
negation flag. So the encoding is quite simple:
|
||
|
||
+---+---+---+---+---+---+---+---+
|
||
| 0 | Entry Type Code (6 or 7)|
|
||
+---+---+---+---+---+---+---+---+
|
||
|
||
|
||
|
||
7.2.6. Additional Records
|
||
|
||
In order to avoid the need of a second query to resolve the given
|
||
host name, a DNS server should enclose the A record for that domain
|
||
name in the additional section of the additional section of the DNS
|
||
reply, if the server happens to be authoritative.
|
||
|
||
In order to avoid the need of a second query to resolve the given
|
||
host name, a DNS server should enclose the APL record for that
|
||
domain name in the additional section of the additional section of
|
||
the DNS reply, if the server happens to be authoritative.
|
||
|
||
|
||
|
||
8. Message Headers
|
||
|
||
An RMX query must be followed by any kind of action depending on
|
||
the RMX result. One action might be to reject the message. Another
|
||
action might be to add a header line to the message body, thus
|
||
allowing MUAs and delivery programs to filter or sort messages.
|
||
|
||
In future, the RMX result might be melted into the Received: header
|
||
line.
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 19]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
The details of such entries are to be discussed. As a proposal the
|
||
following form is suggested:
|
||
|
||
X-RMX: RESULT addr ADDRESS by HOST on DATE mechanism MECHANISM
|
||
|
||
where
|
||
|
||
RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX",
|
||
"TempFail", "BadData", "Trusted".
|
||
|
||
ADDRESS is the IP address of the sending machine
|
||
|
||
HOST is the name of the machine performing the RMX query.
|
||
|
||
DATE is the date of the query.
|
||
|
||
MECHANISM is the RMX method used to authorize the sender.
|
||
|
||
|
||
|
||
9. SMTP error messages
|
||
|
||
If a message is rejected because of RMX records, an error message
|
||
should be issued which explains the details. It is to be discussed
|
||
whether new SMTP error codes are to be defined.
|
||
|
||
|
||
10. Message relaying and forwarding
|
||
|
||
10.1. Problem description
|
||
|
||
Message forwarding and relaying means that an MTA which received an
|
||
e-mail by SMTP does not deliver it locally, but resends the message
|
||
- usually unchanged except for an additional Received header line
|
||
and maybe the recipient's address rewritten - to the next SMTP MTA.
|
||
Message forwarding is an essential functionality of e-mail
|
||
transport services, for example:
|
||
|
||
- Message transport from outer MX relay to the intranet
|
||
- Message forwarding and Cc-ing by .forward or .procmail-alike
|
||
mechanisms
|
||
- Mailing list processing
|
||
- Message reception by mail relays with low MX priority,
|
||
usually provided by third parties as a stand-by service
|
||
in case of relay failure or maintenance
|
||
- "Forwarding" and "Bouncing" as a MUA functionality
|
||
|
||
In all these cases a message is sent by SMTP from a host which is
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 20]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
not covered by the original sender domain's RMX records. While the
|
||
RMX records would forbid accepting this message, it still must be
|
||
accepted. The following subsections explain how to cope with
|
||
relaying.
|
||
|
||
10.2. Trusted relaying/forwarding
|
||
|
||
In some cases the receiving MTA trusts the sending MTA to not fake
|
||
messages and to already have checked the RMX records at message
|
||
reception. As a typical example, a company might have an outer mail
|
||
relay which receives messages from the Internet and checks the RMX
|
||
records. This relay then forwards the messages to the different
|
||
department's mail servers. It does not make sense for these
|
||
department mail servers to check the RMX record, since the RMX
|
||
records have already been checked and - since the message was
|
||
relayed by the outer relay - always would deny the message. In this
|
||
case there is a trust relationship between the department relays
|
||
and the outer relay. So RMX checking is turned off for trusted
|
||
relays. In this example, the department relays would not check
|
||
messages from the outer relay (but for intranet security, they
|
||
could still check RMX records of the other departments sub-domains
|
||
to avoid internal forgery between departments).
|
||
|
||
Another common example are the low-priority MX relays, which
|
||
receive and cache e-mails when the high-priority relays are down.
|
||
In this case, the high-priority relay would trust the low-priority
|
||
relay to have verified the sender authorization and would not
|
||
perform another RMX verification (which would obviously fail).
|
||
|
||
When a relay forwards a message to a trusting machine, the envelope
|
||
sender address should remain unchanged.
|
||
|
||
10.3. Untrusted relaying/forwarding
|
||
|
||
If the receiving MTA does not trust the forwarding MTA, then there
|
||
is no chance to leave the sender envelope address unchanged. At a
|
||
first glance this might appear impracticable, but this is
|
||
absolutely necessary. If an untrusted MTA could claim to have
|
||
forwarded a message from a foreign sender address, it could have
|
||
forged the message as well. Spammers and forgers would just have to
|
||
act as such a relay.
|
||
|
||
Therefore, it is required that, when performing untrusted
|
||
forwarding, the envelope sender address has to be replaced by the
|
||
sender address of someone responsible for the relaying mechanism,
|
||
e.g. the owner of the mailing list or the mail address of the user
|
||
who's .forward caused the transmission. It is important to stress
|
||
that untrusted relaying/forwarding means taking over responsibility
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 21]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
for the message. It is the idea of RMX records to tie
|
||
responsibility to message transmission. Untrusted relaying without
|
||
replacing the sender address would mean to transmit without taking
|
||
responsibility.
|
||
|
||
The disadvantage is that the original sender address is lost.
|
||
Therefore, whenever a sender address replacement happens, the
|
||
Received-Line must contain the old address. Many of today's MTAs
|
||
already insert the envelope recipient address, but not the sender
|
||
address into the Received header line. It seems reasonable to
|
||
require every Received line to include both the sender and
|
||
recipient address of the incoming SMTP connection.
|
||
|
||
|
||
11. Security Considerations
|
||
|
||
11.1. Draft specific considerations
|
||
|
||
11.1.1. Authentication strength
|
||
|
||
It is important to stress, that the suggested method does not
|
||
provide high level security and does not completely prevent forged
|
||
e-mails or spam under any circumstances. It is a robust, but not
|
||
highly reliable and completely secure security mechanism. Keep in
|
||
mind that it is based on DNS, and DNS is not secure today.
|
||
Authorization is based on the IP address. The very same machine
|
||
with the very same IP address could be authorized to send e-mail
|
||
with a given sender address and sending spam at the same time.
|
||
Maybe because several users are logged in. Or because several
|
||
customers use the same relay of the same ISP, where one customer
|
||
could use the sender address of a different customer. It is up to
|
||
the ISP to prevent this or not. Machines can still be hijacked.
|
||
Spammers are also domain owners. They can simply use their own
|
||
domain and authorize themselves. You will always find people on the
|
||
world who do not care about security and open their relays and RMX
|
||
records for others to abuse them. RMX is to be considered as a
|
||
very cheap and simple light weight mechanism, which can
|
||
nevertheless provide a significant improvement in mail security
|
||
against a certain class of attacks, until a successor of SMTP has
|
||
been defined and commonly accepted.
|
||
|
||
11.1.2. Where Authentication and Authorization end
|
||
|
||
Previous versions of RMX records did not cover the local part of
|
||
the e-mail address, i.e. what's on the left side of the @ sign.
|
||
This is still to be discussed. Authentication and authorization are
|
||
limited to the sending MTA's IP address. The authentication is
|
||
limited to the TCP functionality, which is sufficient for light
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 22]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
weight authentication. The RMX records authorize the IP address of
|
||
the sending host only, not the particular sender of the message. So
|
||
if a machine is authorized to use sender addresses of more than a
|
||
single domain, the authentication scheme does not prevent that any
|
||
user on this machine can send with any of these domains. RMX is not
|
||
a substitute for the host security of the involved machines.
|
||
|
||
The proposed authentication scheme can be seen as a "half way
|
||
authentication": It does not track back an e-mail to the effective
|
||
sender. It tracks only half of the way, i. e. it tracks back to the
|
||
domain and it's DNS administrators who authorized that particular
|
||
sender IP address to use it for sending e-mail. How the party
|
||
responsible for that domain performs user authentication, whom it
|
||
grants access to, how it helds people responsible for abuse, is
|
||
completely left as the private business of those who are in charge
|
||
of that domain. So this draft does not interfere with the domain's
|
||
individual security policy or any legislation about such policies.
|
||
On the other hand, the proposed authentication scheme does not give
|
||
any statement about the nature and quality of the domain's security
|
||
policy. This is an essential feature of the proposal: E-mail
|
||
authentication must be deployed world wide, otherwise it won't do
|
||
the job. Any security scheme interfering with the local
|
||
legislations or the domain's security policy will not be accepted
|
||
and can't effectively deployed. Therefore, the security policy must
|
||
remain the domain's private business, no matter how lousy the
|
||
policy might be.
|
||
|
||
In order to achieve this and to make use of the only existing world
|
||
wide Internet directory scheme (DNS), the approach of this proposal
|
||
is to just ignore the local part of the sender address (i.e. what's
|
||
left of the @ part) and limit view to the domain part. After all,
|
||
that's what we do anyway when delivering to a given address with
|
||
SMTP.
|
||
|
||
11.1.3. Vulnerability of DNS
|
||
|
||
DNS is an essential part of the proposed authentication scheme,
|
||
since it requires any directory service, and DNS is currently the
|
||
only one available. Unfortunately, DNS is vulnerable and can be
|
||
spoofed and poisoned. This flaw is commonly known and weakens many
|
||
network services, but for reasons beyond that draft DNS has not
|
||
been significantly improved yet. After the first version of this
|
||
draft, I received several comments who asked me not to use DNS
|
||
because of its lack of security. I took this into consideration,
|
||
but came to the conclusion that this is unfeasible: Any
|
||
authentication scheme linked to some kind of symbolic identity (in
|
||
this case the domain name) needs some kind of infrastructure and
|
||
trusted assignment. There are basically two ways to do it: Do it
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 23]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
yourself and trust nobody else, or let someone else do it. There
|
||
are methods to do it the former way, e.g. to give someone some kind
|
||
of authentication information after a first successful e-mail
|
||
exchange, e.g. some kind of cookie or special e-mail address. This
|
||
is certainly interesting and powerful, but it does not solve the
|
||
problem on a world wide scale and is far to complicated and error
|
||
prone for the average user, i. e. 99% of the users.
|
||
|
||
The latter method to let someone else do the symbolic name
|
||
assignment and create the authentication framework is well known.
|
||
It context of public key cryptography, this is called a Public Key
|
||
Infrastructure (PKI). On of the best known facts about PKIs is
|
||
that, until now, we don't have any covering a significant part of
|
||
the Internet. And we won't have any in near future. The complexity
|
||
is far too high, it is too expensive, and it involves cooperation
|
||
of every single user, which is simply unrealistic and extremely
|
||
error prone. So what do we have we can use? All we have is the DNS
|
||
and the Whois database. And we have countries who don't allow
|
||
cryptography. So the proposal was designed to use DNS without
|
||
cryptography. It does not avoid DNS because of its vulnerability,
|
||
it asks for a better DNS, but accepts the DNS as it is for the
|
||
moment. Currently there are two main threats caused by the DNS
|
||
weakness:
|
||
|
||
- A spammer/forger could spoof DNS in order to gain false
|
||
authorization to send fake e-mails.
|
||
|
||
- An attacker could spoof DNS in order to block delivery from
|
||
authorized machines, i. e. perform a Denial of Service attack.
|
||
|
||
The first one is rather unrealistic, because it would require an
|
||
average spammer to poison a significant part of the DNS servers of
|
||
its victims. A spammer sending messages to one million receipients
|
||
would need to poison at least 1-10% which is 10,000 to 100,000
|
||
receipient's DNS servers. This should be unfeasible in most cases.
|
||
|
||
In contrast, the second threat is a severe one. If an attacker
|
||
wanted to block messages from one company to another, he just needs
|
||
to poison the recipients DNS server with a wrong RMX record in
|
||
order to make the recipient's SMTP machine reject all messages. And
|
||
this is feasible since the attacker needs to poison only a single
|
||
DNS server. But does this make SMTP more vulnerable? No. Because
|
||
the attacker can already do even more without RMX. By poisoning the
|
||
sender's DNS server with wrong MX records, the attacker can also
|
||
block message delivery or even redirect the messages to the
|
||
attacker's machine, thus preventing any delivery error messages and
|
||
furthermore getting access to the messages.
|
||
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 24]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
As a consequence, e-mail delivery by SMTP requires a better DNS
|
||
anyway. The requirements are not significantly expanded by RMX.
|
||
|
||
11.1.4. Sneaking RMX attack?
|
||
|
||
While writing a test implementation, a certain kind of attack came
|
||
into my mind. I'm still not sure, whether this attack is possible
|
||
on any DNS server, but I believe it should be mentioned:
|
||
|
||
Imagine an unauthorized sender is sending a forged mail (e.g.
|
||
spam). At connection time, before querying the RMX record, the
|
||
receiving MTA usually performs a PTR query for the IP address of
|
||
the sending MTA. If the sender has control over the authoritative
|
||
name server for that particular IP address, the sender could give a
|
||
normal PTR answer, but could append a wrong RMX, APL, or A record
|
||
in the additional section of the query. A subsequent RMX query
|
||
could receive wrong DNS data if the DNS server used by the
|
||
receiving MTA accepted those forged records.
|
||
|
||
11.1.5. Open SMTP relays
|
||
|
||
Open SMTP relays (i.e. machines who accept any e-mail message from
|
||
anyone and deliver to the world) abused by spammers are a one of
|
||
the main problems of spam defense and sender backtracking. In most
|
||
cases this problem just vanishes because foreign open relay
|
||
machines will not be covered by the RMX records of the forged
|
||
sender address. But there are two special cases:
|
||
|
||
If the spammer knows about a domain which authorizes this
|
||
particular machine, that domain can be used for forgery. But in
|
||
this case, the IP address of the relay machine and the RMX records
|
||
of the domain track back to the persons responsible. Both can be
|
||
demanded to fix the relay or remove the RMX record for this
|
||
machine. An open relay is a security flaw like leaving the machine
|
||
open for everybody to login and send random mails from inside. Once
|
||
the administrative persons refuse to solve the problem, they can be
|
||
identified as spammers and held responsible.
|
||
|
||
The second special case is when a domain authorizes all IP
|
||
addresses by having the network 0.0.0.0/0 in the RMX/APL record. In
|
||
this case, open relays don't make things worse. It's up to the
|
||
recipient's MTA to reject mails from domains with loose security
|
||
policies.
|
||
|
||
11.1.6. Unforged Spam
|
||
|
||
This proposal does not prevent spam (which is, by the way, not yet
|
||
exactly defined), it prevents forgery. Since spam is against law
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 25]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
and violates the recipients rights, spam depends on untracability
|
||
of the sender. In practice the sender forges the sender address
|
||
(other cases see below). This proposal is designed to detect such
|
||
forgeries.
|
||
|
||
However, the RMX approach is rendered ineffective, if the sender
|
||
doesn't forge. If the sender uses just a normal address of it's own
|
||
domain, this is just a plain, normal e-mail, which needs to be let
|
||
through. Since it is up to the human's taste whether this is spam
|
||
or not, there's no technical way to reliably identify this as spam.
|
||
But since the sender domain is known, this domain can be
|
||
blacklisted or legal steps can be gone into.
|
||
|
||
11.1.7. Reliability of Whois Entries
|
||
|
||
Once the RMX infrastructure gets deployed, what's the security
|
||
gain? It allows to determine the domain which's DNS zone
|
||
authorized the sending machine. What's that good for? There are
|
||
some immediate uses of the domain name, e.g. in black- and
|
||
whitelisting. But in most cases this is just the starting point of
|
||
further investigations, either performed automatically before
|
||
message acceptance, or manually after spam has been received and
|
||
complainted about.
|
||
|
||
The next step after determining the domain is determining the
|
||
people responsible for this domain. This can sometimes be achieved
|
||
by querying the Whois databases. Unfortunately, many whois entries
|
||
are useless because they are incomplete, wrong, obsolete, or in
|
||
uncommon languages. Furthermore, there are several formats of
|
||
address informations which make it difficult to automatically
|
||
extract the address. Sometimes the whois entry identifies the
|
||
provider and not the owner of the domain. Whois servers are not
|
||
built for high availability and sometimes unreachable.
|
||
|
||
Therefore, a mandatory standard is required about the contents and
|
||
the format of whois entries, and the availability of the servers.
|
||
After receiving the MAIL FROM SMTP command with the sender envelope
|
||
address, the receiving MTA could check the RMX record and Whois
|
||
entry. If it doesn't point to a real human, the message could be
|
||
rejected and an error message like "Ask your provider to fix your
|
||
Whois entry" could be issued. Obviously, domain providers must be
|
||
held responsible for wrong entries. It might still be acceptable to
|
||
allow anonymous domains, i. e. domains which don't point to a
|
||
responsible human. But it is the receivers choice to accept e-mails
|
||
from such domains or not.
|
||
|
||
11.1.8. Hazards for Freedom of Speech
|
||
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 26]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
Currently, some governments try to enforce limitations of internet
|
||
traffic in order to cut unwanted content providers from the
|
||
network. Some of these governments try to hide a whole country
|
||
behind firewalls, others try to force Internet providers to poison
|
||
DNS servers with wrong A records for web servers, e.g. one county
|
||
administration in Germany tries to do so. If message reception
|
||
depends on DNS entries, the same governments will try to block not
|
||
only HTTP, but SMTP also.
|
||
|
||
However, since most MTAs already reject messages from unresolvable
|
||
domain names this is not a new threat.
|
||
|
||
11.2. General Considerations about spam defense
|
||
|
||
After discussing security requirements of the proposal, now the
|
||
security advantages of the RMX approach over content based filters
|
||
will be explained. Basically, there are three kinds of content
|
||
filters:
|
||
|
||
- Those who upload the message or some digest to an external
|
||
third party and ask "Is this spam"?
|
||
|
||
- Those who download a set of patterns and rules from a third
|
||
party and apply this set to incoming messages in order to
|
||
determine whether it is spam.
|
||
|
||
- Those who are independent and don't contact any third party,
|
||
but try to learn themselves what is spam and what isn't.
|
||
|
||
|
||
The message filters provided by some e-mail service providers are
|
||
usually not a kind of their own, but a combination of the first two
|
||
kinds.
|
||
|
||
11.2.1. Action vs. reaction
|
||
|
||
Content filters suffer from a fundamental design problem: They are
|
||
late. They need to see some content of the same kind before in
|
||
order to learn and to block further distribution.
|
||
|
||
This works for viruses and worms, which redistribute. This doesn't
|
||
work for spam, since spam is usually not redistributed after the
|
||
first delivery. When the filters have learned or downloaded new
|
||
pattern sets, it's too late.
|
||
|
||
This proposal does not have this problem.
|
||
|
||
11.2.2. Content based Denial of Service attacks
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 27]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
All three kinds of content filters, but especially the second and
|
||
the third kind are vulnerable to content based Denial of Service
|
||
attacks.
|
||
|
||
If some kind of third party (e.g. non-democratic government,
|
||
intellectual property warriors, religious groups, military, secret
|
||
services, patriots, public relation agents, etc.) wants certain
|
||
contents not to be distributed, they could either poison the
|
||
pattern/rule databases or feed wrong sets to particular receivers.
|
||
|
||
Such pattern/rule sets are the perfect tool for censoring e-mail
|
||
traffic and denial of service attacks by governments and other
|
||
parties, and a similar threat are virus filters. E. g. the content
|
||
industry could demand to teach all virus and spam filters to delete
|
||
all e-mails containing the URL of an MP3 web server outside the
|
||
legislations. Software manufacturers could try to block all e-mails
|
||
containing software license keys, thus trying to make unallowed
|
||
distribution more difficult. Governments could try to block
|
||
distribution of unwanted informations.
|
||
|
||
This proposal does not have this problem.
|
||
|
||
|
||
12. Privacy Considerations
|
||
|
||
(It was proposed on the 56th IETF meeting to have a privacy section
|
||
in drafts and RFCs.)
|
||
|
||
12.1. Draft specific considerations
|
||
|
||
12.1.1. No content leaking
|
||
|
||
Since the RMX approach doesn't touch the contents of a message in
|
||
any way, there is obviously no way of leaking out any information
|
||
about the content of the message. RMX is based solely on the
|
||
envelope recipient address. However, methods to fix problems not
|
||
covered by RMX might allow content leaking, e.g. if the acceptance
|
||
of a message with an empty sender address requires the reference to
|
||
the message id of an e-mail recently sent, this allows an attacker
|
||
to verify whether a certain message was delivered from there.
|
||
|
||
12.1.2. Message reception and sender domain
|
||
|
||
Message delivery triggers RMX and APL requests by the recipient.
|
||
Thus, the admin of the DNS server or an eavesdropper could learn
|
||
that the given machine has just received a message with a sender
|
||
from this address, even if the SMTP traffic itself had been
|
||
encrypted.
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 28]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
However, most of today's MTAs do query the MX and A records of the
|
||
domain after the MAIL FROM command, so this is not a real new
|
||
threat.
|
||
|
||
12.1.3. Network structure
|
||
|
||
Since RMX and its associated APL records provide a complete list of
|
||
all IP addresses of hosts authorized to send messages from this
|
||
address, they do reveal informations about the network structure
|
||
and maybe the lifestyle of the domain owner, since a growing number
|
||
of domains are owned by single persons or families. E.g. the RMX
|
||
records could reveal where someone has his job or spends his time
|
||
at weekends.
|
||
|
||
If such informations are to be kept secret, it is the user's job to
|
||
not sent e-mails from there and to relay them from non-compromising
|
||
IP addresses.
|
||
|
||
12.1.4. Owner information distribution
|
||
|
||
As described above, RMX depends partly on the reliability of the
|
||
whois database entries. It does not make anonymous domains
|
||
impossible, but it requires to keep the database entries "true", i.
|
||
e. if a whois entry does not contain informations about the
|
||
responsible person, this must be unambigously labeled as anonymous.
|
||
It must not contain fake names and addresses to pretend a non-
|
||
existing person. However, since most Internet users on the world
|
||
feel extremely annoyed by spam, they will urge their MTA admin to
|
||
reject messages from anonymous domains. The domain owner will have
|
||
the choice to either remain anonymous but be not able to send e-
|
||
mail to everyone in the world, or to be able but to reveal his
|
||
identity to everyone on the world.
|
||
|
||
It would be possible to provide whois-like services only to
|
||
recipients of recent messages, but this would make things too
|
||
complicated to be commonly adopted.
|
||
|
||
12.2. General Considerations about spam defense
|
||
|
||
12.2.1. Content leaking of content filters
|
||
|
||
As described above in the Security chapter, there are spam filters
|
||
which inherently allow leakage of the message body. Those filters
|
||
upload either the message body, or in most cases just some kind of
|
||
checksum to a third party, which replies whether this is to be seen
|
||
as spam or not. The idea is to keep a databases of all digests of
|
||
all messages. If a message is sent more often than some threshold,
|
||
it is to be considered as a mass mail and therefore tagged as spam.
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 29]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
While the digest itself does not reveal the content of the message,
|
||
it perfectly reveals where a particular message has been delivered
|
||
to. If a government finds just a single unwanted message, if a
|
||
software manufacturer finds a single message with a stolen product
|
||
license key, if someone finds a message with unpatriotic content,
|
||
it takes just a single database lookup to get a list of all people
|
||
who received this particular message. Content filters with digest
|
||
upload are the perfect "Big Brother".
|
||
|
||
12.2.2. Black- and Whitelists
|
||
|
||
Some proposals against spam are based on a central database of
|
||
white- or blacklisted IP addresses, Sender names, Message IDs or
|
||
whatever. Again, there is a central database which learns who has
|
||
received which e-mail or from which sender with every query. This
|
||
allows tracking relations between persons, which is also a breach
|
||
of privacy.
|
||
|
||
|
||
|
||
13. Deployment Considerations
|
||
|
||
13.1. Compatibility
|
||
|
||
13.1.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.
|
||
|
||
13.1.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.
|
||
|
||
13.1.3. Compatibility with old DNS clients
|
||
|
||
Since the RMX is a new RR, the existing DNS protocol and zone
|
||
informations remain completely untouched.
|
||
|
||
If RMX is provided as a TXT record instead, it must be ensured that
|
||
no other software is misinterpreting this entry.
|
||
|
||
13.1.4. Compatibility with old DNS servers
|
||
|
||
Full compatibility: If the server does not support RMX records, RMX
|
||
in TXT records can be used.
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 30]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
13.2. 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.
|
||
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.
|
||
|
||
|
||
|
||
14. General considerations about fighting spam
|
||
|
||
Is there a concise technical solution against spam? Yes.
|
||
|
||
Will it be deployed? Certainly not.
|
||
|
||
Why not? Because of the strong non-technical interests of several
|
||
parties against a solution to the problem, as described below.
|
||
Since these are non-technical reasons, they might be beyond the
|
||
scope of such a draft. But since they are the main problems that
|
||
prevent fighting spam, it is unavoidable to address them. This
|
||
chapter exists temporarily only and should support the discussion
|
||
of solutions. It is not supposed to be included in a later RFC.
|
||
|
||
14.1. The economical problem
|
||
|
||
As has been recently illustrated in the initial session of the
|
||
IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting,
|
||
sending spam is a business with significant revenues.
|
||
|
||
But a much bigger business is selling Anti-Spam software. This is a
|
||
billion dollar market, and it is rapidly growing. Any simple and
|
||
effective solution against spam would defeat revenues and drive
|
||
several companies into bankrupt, would make consultants jobless.
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 31]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
Therefore, spam is essential for the Anti-Spam business. If there
|
||
is no spam, then no Anti-Spam software can be sold, similar to the
|
||
Anti-Virus business. There are extremely strong efforts to keep
|
||
this market growing. Viruses, Worms, and now spam are just perfect
|
||
to keep this market alive: It is not sufficient to just buy a
|
||
software. Databases need to be updated continuously, thus making
|
||
the cash flow continuously. Have a single, simple, and permanent
|
||
solution to the problem and - boom - this billion dollar market is
|
||
dead.
|
||
|
||
That's one of the reasons why people are expected to live with
|
||
spam. They have to live with it to make them buy Anti-Spam
|
||
software. Content filters are perfect products to keep this market
|
||
alive.
|
||
|
||
14.2. The POP problem
|
||
|
||
Another problem is the history of mail delivery. Once upon a time,
|
||
there used to be very few SMTP relays which handled the e-mail
|
||
traffic of all the world, and everybody was happy with that. Then
|
||
odd things like Personal Computers, which are sometimes switched
|
||
off, portable computers, dynamicly assigned IP addresses, IP access
|
||
from hotel rooms, etc. was invented, and people became unhappy,
|
||
because SMTP does not support delivery to such machines. To make
|
||
them happy again, the Post Office Protocol[4] was invented, which
|
||
turned the last part of message delivery from SMTP's push style
|
||
into a pull style, thus making virtually every computer on the
|
||
world with any random IP address a potential receiver of mails for
|
||
random domains. Unfortunately, only receiving e-mail was covered,
|
||
but sending e-mail was left to SMTP.
|
||
|
||
The result is that today we have only very few SMTP relays pointed
|
||
to by MX records, but an extreme number of hosts sending e-mail
|
||
with SMTP from any IP address with sender addresses from any
|
||
domain. Mail delivery has become very asymmetric. Insecurity,
|
||
especially forgeability, has become an essential part of mail
|
||
transport.
|
||
|
||
That problem could easily be fixed: Use protocols which allow
|
||
uploading of messages to be delivered. If a host doesn't receive
|
||
messages by SMTP, it shouldn't deliver by SMTP. Mail delivery
|
||
should go the same way back that incoming mail went in. This is
|
||
not a limitation to those people on the road who plug their
|
||
portable computer in any hotel room's phone plug and use any
|
||
provider. If there is a POP server granting download access from
|
||
anywhere, then the same server should be ready to accept uploading
|
||
of outgoing messages.
|
||
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 32]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
But as I saw from the comments on the first version of this draft,
|
||
people religiously insist on sending e-mail with their domain from
|
||
any computer with any IP address in the world, e.g. when visiting a
|
||
friend using her computer. It appears to be impossible to convince
|
||
people that stopping mail forgery requires every one of them to
|
||
give up forging.
|
||
|
||
14.3. The network structure problem
|
||
|
||
A subsequent problem is that many organisations failed to implement
|
||
a proper mail delivery structure and heavily based their network on
|
||
this asymmetry. I received harsh comments from Universities who
|
||
were unable to give their network a good structure. While they do
|
||
have a central mail relay for incoming mail to the universities
|
||
domain, they developed a structure where every member of the
|
||
University randomly sends e-mails with that University's domain as
|
||
a sender address from home or everywhere in the world with any
|
||
dynamically assigned IP address from any provider. So this domain
|
||
is to be used from every possible IP address on earth, and they are
|
||
unable to operate any authentication scheme. Furthermore, they were
|
||
unable to understand that such a policy heavily supports spam and
|
||
that they have to expect that people don't accept such e-mails
|
||
anymore once they become blacklisted.
|
||
|
||
As long as organisations insist on having such policies, spammers
|
||
will have a perfect playground.
|
||
|
||
14.4. The mentality problem
|
||
|
||
Another problem is the mentality of many internet users of certain
|
||
countries. I received harsh comments from people who strongly
|
||
insisted on the freedom to send any e-mail with any sender address
|
||
from anywhere, and who heavily refused any kind of authentication
|
||
step or any limitation, because they claimed that this would
|
||
infringe their constitutional "Freedom of speech". They are
|
||
undeviatingly convinced that "Freedom of speech" guarantees their
|
||
right to talk to everybody with any sender address, and that is has
|
||
to be kept the recipient's own problem to sort out what he doesn't
|
||
want to read - on the recipient's expense.
|
||
|
||
It requires a clear statement that the constitutional "Freedom of
|
||
Speech" does not cover molesting people with unsolicited e-mail
|
||
with forged sender address.
|
||
|
||
14.5. The identity problem
|
||
|
||
How does one fight against mail forgery? With authentication. What
|
||
is authentication? In simple words: Making sure that the sender's
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 33]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
real identity meets the recipients idea of who is the sender, based
|
||
on the sender address which came with the message.
|
||
|
||
What is identity? It is the main problem. Several countries have
|
||
different ideas of "identity", which turn out to be somehow
|
||
incompatible. In some countries people have identity cards and
|
||
never change their name and birthday. Identities are created by
|
||
human birth, not by identity changes. Other countries do not have
|
||
such a tight idea about identity. People's temporary identity is
|
||
based on nothing more than a driving license and a social security
|
||
number. With this background, it is virtually impossible to create
|
||
a trustworthy PKI covering all Internet users. I learned that it is
|
||
extremely difficult to convince some people to give up random e-
|
||
mail sending.
|
||
|
||
14.6. The multi-legislation problem
|
||
|
||
Many proposals about fighting spam are feasible under certain
|
||
legislations only, and are inacceptable under some of the
|
||
legislations. But a world wide applicable method is required.
|
||
That's why the approach to ask everone on the world to sign
|
||
messages with cryptographic keys is not feasible.
|
||
|
||
|
||
Implementation and further Information
|
||
|
||
Further informations and a test implementation are available at
|
||
|
||
http://www.danisch.de/work/security/antispam.html
|
||
http://www.danisch.de/software/rmx/
|
||
|
||
|
||
Additional informations and a technology overview are also
|
||
available at
|
||
|
||
http://www.mikerubel.org/computers/rmx_records/
|
||
|
||
|
||
References
|
||
|
||
|
||
|
||
1. S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev-
|
||
els," RFC 2119 (March 1997).
|
||
|
||
2. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).
|
||
|
||
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 34]
|
||
|
||
INTERNET-DRAFT DNS RMX RR Oct 2003
|
||
|
||
|
||
3. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION,"
|
||
RFC 1035 (November 1987).
|
||
|
||
4. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939
|
||
(May 1996).
|
||
|
||
|
||
Draft History
|
||
|
||
00 Dec 2002
|
||
01 Apr 2003
|
||
02 Jun 2003
|
||
03 Oct 2003
|
||
|
||
Author's Address
|
||
|
||
Hadmut Danisch
|
||
|
||
Tennesseeallee 58
|
||
76149 Karlsruhe
|
||
Germany
|
||
|
||
Phone: ++49-721-843004 or ++49-351-4850477
|
||
E-Mail: rfc@danisch.de
|
||
|
||
Comments
|
||
|
||
Please send comments to rfc@danisch.de.
|
||
|
||
Expiry
|
||
|
||
This drafts expires on Apr 1, 2004.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Hadmut Danisch Experimental [Page 35]
|
||
|