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

非常好的dns解析软件

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