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

非常好的dns解析软件

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

      [e-mail]
      [e-mail]
      [e-mail]

   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