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

bind 9.3结合mysql数据库

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