draft-danisch-dns-rr-smtp-03.txt

bind 9.3结合mysql数据库

   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 [e-mail] 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 [e-mail]
   and [e-mail] 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. [e-mail] 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.