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

bind 9.3结合mysql数据库

   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