Subject: [Asrg] 6 - Designated Relays Inquiry Protocol (DRIP)

From: Raymond S Brand <[email-masked]>
Date: Fri, 27 Jun 2003 22:51:04 -0400

This proposal is designed to deal with the problem of malware
afflicted sending/relaying mail to internet hosts directly.

Unlike the DMP/SPF proposals, it does not modify the envelope or
require changes to SMTP.

I missed the June 23 cut off for internet-drafts submission, so the
actual submission of this document will happen on or after July 18.

Raymond S Brand

Network Working Group                                        R. S. Brand
Internet-Draft                                                L. Sherzer
Expires: December 23, 2003                                 June 24, 2003

               Designated Relays Inquiry Protocol (DRIP)
                        draft-brand-drip-00.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   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/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 23, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract

   The Designated Relays Inquiry Protocol, DRIP, is a method for domain
   name owners to specify the IP addresses that are authorized to relay
   mail as a domain name. The protocol provides a method for server MTAs
   to reject SMTP connections from IP addresses not authorized to use a
   domain name.

Brand & Sherzer        Expires December 23, 2003                [Page 1]

Internet-Draft                    DRIP                         June 2003

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  3
   1.2 Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4

   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  Designating Relays . . . . . . . . . . . . . . . . . . . . . .  6
   3.1 Designation Record Template  . . . . . . . . . . . . . . . . .  6
   3.2 Default Designation Records  . . . . . . . . . . . . . . . . .  7
   3.3 IPv4 Designation Records . . . . . . . . . . . . . . . . . . .  7
   3.4 IPv6 Designation Records . . . . . . . . . . . . . . . . . . .  8
   3.5 Designation Examples . . . . . . . . . . . . . . . . . . . . .  9

   4.  MTA Operation  . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.1 DRIP Authorization Retrieval . . . . . . . . . . . . . . . . . 10
   4.2 DRIP Status Determination  . . . . . . . . . . . . . . . . . . 10
   4.3 DRIP Status Meanings . . . . . . . . . . . . . . . . . . . . . 11
   4.4 MTA Operation Examples . . . . . . . . . . . . . . . . . . . . 12

   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14

       Normative References . . . . . . . . . . . . . . . . . . . . . 15

       Informative References . . . . . . . . . . . . . . . . . . . . 16

       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16

   A.  Dictatorial Powers . . . . . . . . . . . . . . . . . . . . . . 17

   B.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18

       Intellectual Property and Copyright Statements . . . . . . . . 19

Brand & Sherzer        Expires December 23, 2003                [Page 2]

Internet-Draft                    DRIP                         June 2003

1. Introduction

   The Designated Relays Inquiry Protocol, DRIP, is a method for domain
   name owners to specify the IP addresses that are authorized to relay
   mail as a domain name in the SMTP HELO and EHLO commands. The
   protocol provides a method for server MTAs to reject SMTP connections
   from IP addresses not authorized to use the domain name given in the
   SMTP HELO and EHLO commands.

1.1 Motivation

   Source verification information transmitted as part of a mail
   message, such as digital signatures, can permit MTAs, MDAs, and MUAs
   to verify that a messages is associated with a sender or gateway.
   However, those methods do not prevent malware authors from:

   o  Embedding a verifiable (signed) message in the malware.

   o  Embedding a verifier generator (private key) in the malware.

   Either technique permits malware afflicted machines to send
   verifiable messages.

   DRIP is designed to force malware authors to send the malware
   generated mail through the relays the afflicted systems are already
   configured and authorized use. Operators of those relays are very
   likely to have an existing relationship with the operators of the
   afflicted systems and can act to limit the damage to the internet
   caused by the malware.

Brand & Sherzer        Expires December 23, 2003                [Page 3]

Internet-Draft                    DRIP                         June 2003

1.2 Terminology

   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 [RFC2119].

   DNS
      Domain Name System. See [RFC1034] and [RFC1035].

   IPv4
      Internet Protocol version 4.

   IPv6
      Internet Protocol version 6.

   ISP
      Internet Service Provider.

   Malware
      Malicious software. See [RFC2828].

   MDA
      Mail Delivery Agent.

   Mail Relay
      See MTA.

   MTA
      Mail Transfer Agent.

   MUA
      Mail User Agent.

   Relay
      See MTA.

   SMTP
      Simple Mail Transfer Protocol. See [RFC2821]

   Standardese
      A peculiar dialect employed by authors of standards.

Brand & Sherzer        Expires December 23, 2003                [Page 4]

Internet-Draft                    DRIP                         June 2003

2. Overview

   Domain name owners identify and record the IP addresses that are
   authorized to relay mail as their domain name. How the IP addresses
   are identified is beyond the scope of this document, but will likely
   involve consultation with the postmaster for the domain name. The IP
   address authorization records are recorded in DNS as described in
   Section 3.

   Server MTAs verify the domain name the client MTA submitted as
   identification, by querying for the IP address authorization records
   recorded by the domain name owner. Based on the result of the query,
   the server MTA can determine if the domain name is a DRIP
   participant. If the domain name is a DRIP participant, the result of
   the query will also indicate if the IP address of the client is
   authorized to use the domain name to relay mail. Section 4 specifies
   the operation of server MTAs following this protocol.

Brand & Sherzer        Expires December 23, 2003                [Page 5]

Internet-Draft                    DRIP                         June 2003

3. Designating Relays

   Domain name owners record the designated relays by adding a
   specifically formatted DNS record for each IP address that is
   authorized to use a domain name in the SMTP HELO or EHLO commands.
   Default records are also added to indicate DRIP participation by the
   domain name, and that the IP address used in the query is NOT
   authorized to use the domain name to relay mail.

3.1 Designation Record Template

   The template for the DNS records is:

      ${IPS}.${IPV}.relays._email_.${DOMAIN}.   IN   ${TYPE}   ${IP}

   With:

   ${IPS}
      The textual representation of the IP address.

   ${IPV}
      The textual representation of the IP protocol version used.

   ${DOMAIN}
      The domain name used in the SMTP HELO or EHLO commands.

   ${TYPE}
      The DNS record type corresponding to the IP protocol version of
      the IP address.

   ${IP}
      The IP address.

   See [RFC2782] for a discussion of the need for the underscores.

Brand & Sherzer        Expires December 23, 2003                [Page 6]

Internet-Draft                    DRIP                         June 2003

3.2 Default Designation Records

   The following default or "wildcard" records are added for each domain
   name and defined IP protocol version. These records, when returned as
   a result of a DRIP query, indicate DRIP participation by the domain
   name and that IP address used in the query is NOT authorized to use
   the domain name in the SMTP HELO or EHLO commands.

      *.${IPV}.relays._email_.${DOMAIN}.   IN   ${TYPE}   ${IPZ}

   Where ${IPZ} depends on the IP protocol version.

   A default record returned as the result of a DRIP query is identified
   by the value of the record, ${IPZ}, which is defined for each IP
   protocol version and corresponds to the "unspecified address".

   Both IPv4 and IPv6 default designation records SHOULD be added for
   each domain name.

3.3 IPv4 Designation Records

   For IP version 4 addresses, the following applies:

   ${IPS}
      Textual representation of the IPv4 address of the Designated Relay
      in "dotted quad", also known as "dotted decimal", notation. This
      textual representation was chosen to be easy for both the wetware
      components and the software components to implement the protocol.

      The textual representation of the IPv4 loopback address,
      127.0.0.1, is

         127.0.0.1

   ${IPV}
      "IPv4".

   ${TYPE}
      "A".

   ${IP}
      The IP address of the the Designated Relay.

   ${IPZ}
      "0.0.0.0", the IPv4 "unspecified address". Chosen because it can
      not be a valid client IP address when used with TCP.

Brand & Sherzer        Expires December 23, 2003                [Page 7]

Internet-Draft                    DRIP                         June 2003

3.4 IPv6 Designation Records

   For IP version 6 addresses, the following applies:

   ${IPS}
      Textual representation of the IPv6 address of the Designated Relay
      formatted as a sequence of 8 16bit words separated by dots. Each
      word is represented by 4 hexadecimal digits. The words and the
      hexadecimal digits of a word are in network byte order. This IPv6
      address representation is similar to the representation in
      [RFC3513] except that the colons have been replaced with dots, and
      that leading zeros MUST be included. This textual representation
      was chosen to be easy for both the wetware components and the
      software components to implement the protocol.

      The textual representation of the IPv6 loopback address, ::1, is:

         0000.0000.0000.0000.0000.0000.0000.0001

      The textual representation of the IPv6 address 2002:c000:201::1234
      is:

         2002.c000.0201.0000.0000.0000.0000.1234

   ${IPV}
      "IPv6".

   ${TYPE}
      "AAAA".

   ${IP}
      The IP address of the the Designated Relay.

   ${IPZ}
      "::", the IPv6 "unspecified address". Chosen because it can not be
      a valid client IP address when used with TCP.

   MTAs with IPv4-compatible IPv6 addresses [RFC3513] SHOULD also have
   an IPv4 DRIP record for the IPv4 part of each IPv4-compatible IPv6
   address.

Brand & Sherzer        Expires December 23, 2003                [Page 8]

Internet-Draft                    DRIP                         June 2003

3.5 Designation Examples

3.5.1 Designation Example 1

   The owner of the domain name EXAMPLE.COM would add the following DNS
   records to the EXAMPLE.COM zone to indicate that the domain name
   EXAMPLE.COM is NOT valid for use in the SMTP HELO and EHLO commands.

      Default Designation Records:

         *.IPv4.relays._email_.EXAMPLE.COM.     IN    A      0.0.0.0

         *.IPv6.relays._email_.EXAMPLE.COM.     IN    AAAA   ::

      IPv4 Designation Records:

         None.

      IPv6 Designation Records:

         None.

3.5.2 Designation Example 2

   The owner of the domain name M.EXAMPLE.COM would add the following
   DNS records to the M.EXAMPLE.COM zone to indicate that ONLY the IPv4
   addresses 192.0.2.10, 192.0.2.11, and 127.0.0.1 are authorized to use
   the domain name in the SMTP HELO and EHLO commands.

      Default Designation Records:

         *.IPv4.relays._email_.M.EXAMPLE.COM.    IN    A      0.0.0.0

         *.IPv6.relays._email_.M.EXAMPLE.COM.    IN    AAAA   ::

      IPv4 Designation Records:

         192.0.2.10.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.10

         192.0.2.11.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.11

         127.0.0.1.IPv4.relays._email_.M.EXAMPLE.COM.   IN A  127.0.0.1

      IPv6 Designation Records:

         None.

Brand & Sherzer        Expires December 23, 2003                [Page 9]

Internet-Draft                    DRIP                         June 2003

4. MTA Operation

   Server MTAs use the IP address of the client MTA from the SMTP
   connection and the domain name, which the client submitted as
   identification in the SMTP HELO or EHLO command, to verify that the
   IP address is authorized to use the domain name to relay mail. The
   process for doing this is:

   1.  Attempt to retrieve the DRIP authorization record for the IP
       address and the domain name via DNS.

   2.  Examine the result of the DNS retrieval attempt to determine the
       DRIP status.

   3.  Continue or terminate the SMTP transaction based on the DRIP
       status.

   DRIP authorization checks may be deferred until the MAIL command in
   the SMTP transaction or not be performed at all for SMTP transactions
   where relay authorization schemes are used. Examples of relay
   authorization schemes are, an ISP's use of the client's IP address to
   allow only the ISP's customers to relay; or a corporate server MTA
   using SMTP AUTH to allow roaming senders to relay.

4.1 DRIP Authorization Retrieval

   The DRIP authorization record to retrieve is the DNS record, as
   described in Section 3.1, corresponding to the IP address and domain
   name that the client MTA identified itself as.

   IPv6 server MTAs MUST perform the DRIP authorization retrieval using
   the IPv4 address of the "IPv4-mapped IPv6 address" [RFC3513] when
   clients connect from IPv4-mapped IPv6 addresses.

4.2 DRIP Status Determination

   A successful retrieval of a single record of the appropriate type
   with the IP address in the record matching the IP address of the
   client has a DRIP status of DRIP_OK. The requirement that the IP
   address in the authorization record be the IP address of the client,
   is to prevent malware authors from easily designating the entire IP
   address space as authorized to relay as a given domain name.

   A successful retrieval of a single record of the appropriate type
   with the IP address in the record not matching the IP address of the
   client has a DRIP status of DRIP_NOT_OK.

Brand & Sherzer        Expires December 23, 2003               [Page 10]

Internet-Draft                    DRIP                         June 2003

   Any type of temporary DNS retrieval or network failure has a DRIP
   status of DRIP_TEMP_FAIL.

   Any other type of DNS result, such as a permanent error, multiple
   records retrieved, retrieved record not of the correct record type,
   etc., has a DRIP status of DRIP_UNKNOWN.

4.3 DRIP Status Meanings

   The DRIP statuses have the following meanings:

   DRIP_OK
      This indicates that the IP address of the client is one of the
      authorized IP addresses for the domain name to use to relay mail.
      The SMTP transaction may continue.

   DRIP_NOT_OK
      This indicates that the IP address of the client is not one of the
      authorized IP addresses for the given domain name to use to relay
      mail. The SMTP transaction SHOULD be terminated with a permanent
      failure, 5XX, reply code.

   DRIP_TEMP_FAIL
      This indicates that the lookup could not be completed at this
      time. The SMTP transaction SHOULD be terminated with a temporary
      failure, 4XX, reply code.

   DRIP_UNKNOWN
      This indicates that the given domain name is not a DRIP
      participant. Local policy of the server MTA determines if the SMTP
      transaction should continue or not.

      A RECOMMENDED local policy is for the server MTA to, iteratively,
      use the parent domain names to perform more DRIP authorization
      retrievals. If any of those retrievals result in either a DRIP_OK
      status or a DRIP_NOT_OK status, the server MTA SHOULD assume that
      the client is NOT authorized to relay mail as the given domain
      name.

Brand & Sherzer        Expires December 23, 2003               [Page 11]

Internet-Draft                    DRIP                         June 2003

4.4 MTA Operation Examples

   The following examples assume that the DNS records described in
   Section 3.5 exist and that no other DRIP related DNS records exist
   for the domain names used.

4.4.1 MTA Operation Example 1

   A server MTA accepts an SMTP connection from IP address 192.0.2.10
   and the client identifies itself as M.EXAMPLE.COM.

   1.  The server attempts to retrieve the DRIP authorization record

       192.0.2.10.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.10

       via a DNS lookup.

   2.  The DNS lookup retrieves a single A record with the IP address
       192.0.2.10.

   3.  Since only a single record was retrieved, it was of the correct
       type, and IP address in the record is the IP address of the
       client, the DRIP status is DRIP_OK.

   4.  The SMTP transaction continues.

4.4.2 MTA Operation Example 2

   A server MTA accepts an SMTP connection from IP address 192.0.2.99
   and the client identifies itself as S.EXAMPLE.COM.

   1.  The server attempts to retrieve the DRIP authorization record

       192.0.2.99.IPv4.relays._email_.S.EXAMPLE.COM.  IN A  192.0.2.99

       via a DNS lookup.

   2.  The DNS lookup results in a "Name Error", indicating that the
       record does not exist.

   3.  Since the DNS lookup resulted in a permanent lookup error, the
       the DRIP status is DRIP_UNKNOWN and the server uses local policy
       to determine if the SMTP transaction should continue or not.

Brand & Sherzer        Expires December 23, 2003               [Page 12]

Internet-Draft                    DRIP                         June 2003

   4.  If the server follows the RECOMMENDED local policy of performing
       DRIP authorization retrievals using parent domain names when a
       DRIP status of DRIP_UNKNOWN is encountered, the server attempts
       to retrieve the DRIP authorization record

       192.0.2.99.IPv4.relays._email_.EXAMPLE.COM.  IN A  192.0.2.99

       via a DNS lookup.

   5.  The DNS lookup retrieves a single A record with the IP address
       0.0.0.0.

   6.  Since only a single record was retrieved, and the record was of
       the correct type, and the IP address in the record is not the IP
       address of the client, the DRIP status is DRIP_NOT_OK.

   7.  Because this was a DRIP authorization retrieval of a parent
       domain and the status is of this retrieval is DRIP_OK or
       DRIP_NOT_OK, the server SHOULD assume that the client is NOT
       authorized to relay mail as the given domain name.

   8.  The server terminates the SMTP transaction with a permanent
       failure, 5XX, reply code.

4.4.3 MTA Operation Example 3

   A server MTA accepts an SMTP connection from IP address
   ::FFFF:C000:263 and the client identifies itself as S.EXAMPLE.COM.

   Because the IP address of the client is the IPv4-mapped IPv6 address
   of 192.0.2.99, the server MUST perform the same operations as in
   Section 4.4.2.

Brand & Sherzer        Expires December 23, 2003               [Page 13]

Internet-Draft                    DRIP                         June 2003

5. Security Considerations

   This method relies on DNS to verify relay authorization and as such
   is vulnerable to the security issues of DNS. However, this is no
   different than mail, in general, being vulnerable to DNS security
   issues. Sites concerned about this should investigate implementing
   [RFC2401] and/or [RFC2535].

   A likely, and intended, response of malware authors to wide spread
   adoption of DRIP is to search afflicted systems for MUA settings and
   use the configured gateways, and possibly identities and credentials,
   to mail their payloads. It is hoped that the gateway operators will
   notice the undesirable traffic and be able to do something about it.
   The gateway operators already have a relationship with the
   operator(s) of the afflicted systems and are in a much better
   position, than the internet at large, to be able to correct the
   problem.

   DRIP is intended and designed to help protect your systems from the
   malware afflicted systems of others. Not to protect your systems from
   your own malware afflicted systems. Sites concerned about this should
   investigate the use of malware detectors on their systems.

   While not a security consideration, DRIP does not provide any
   assurances to the server MTA that the mail being relayed from the
   client is not SPAM; only that the IP address of the client MTA is
   authorized to relay mail as the domain name, the client identified
   itself as, in the SMTP EHLO or HELO command.

Brand & Sherzer        Expires December 23, 2003               [Page 14]

Internet-Draft                    DRIP                         June 2003

Normative References

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2782]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC2821]  Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
              April 2001.

   [RFC3513]  Hinden, R. and S. Deering, "Internet Protocol Version 6
              (IPv6) Addressing Architecture", RFC 3513, April 2003.

Brand & Sherzer        Expires December 23, 2003               [Page 15]

Internet-Draft                    DRIP                         June 2003

Informative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1886]  Thomson, S. and C. Huitema, "DNS Extensions to support IP
              version 6", RFC 1886, December 1995.

   [RFC1925]  Callon, R., "The Twelve Networking Truths", RFC 1925,
              April 1996.

   [RFC1983]  Malkin, G., "Internet Users' Glossary", RFC 1983, August
              1996.

   [RFC2401]  Kent, S. and R. Atkinson, "Security Architecture for the
              Internet Protocol", RFC 2401, November 1998.

   [RFC2535]  Eastlake, D., "Domain Name System Security Extensions",
              RFC 2535, March 1999.

   [RFC2822]  Resnick, P., "Internet Message Format", RFC 2822, April
              2001.

   [RFC2828]  Shirey, R., "Internet Security Glossary", RFC 2828, May
              2000.

Authors' Addresses

   Raymond S Brand
   P.O. Box 100486
   Ft. Lauderdale, FL  33310
   US

   EMail: [email-masked]
   URI:   http://www.RSBX.com/

   Laurence Sherzer
   P.O. Box 5072
   Deerfield Beach, FL  33442
   US

   EMail: [email-masked]
   URI:   http://www.sherzer.net/

Brand & Sherzer        Expires December 23, 2003               [Page 16]

Internet-Draft                    DRIP                         June 2003

Appendix A. Dictatorial Powers

   Any measure to control SPAM, if it is to be effective, must create or
   enhance the power of one or more entities involved in moving email
   from the source to the destination(s).

   The method described in this document enhances the ability of the
   domain name owner to control which MTAs may identify themselves as a
   domain name.

Brand & Sherzer        Expires December 23, 2003               [Page 17]

Internet-Draft                    DRIP                         June 2003

Appendix B. Acknowledgments

   The authors gratefully acknowledges the contributions of: Robert M.
   Bownes III, and Richard Rognlie.

Brand & Sherzer        Expires December 23, 2003               [Page 18]

Internet-Draft                    DRIP                         June 2003

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2003). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION

Brand & Sherzer        Expires December 23, 2003               [Page 19]

Internet-Draft                    DRIP                         June 2003

   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Brand & Sherzer        Expires December 23, 2003               [Page 20]

---

From: Raymond S Brand <[email-masked]>
Date: Sat, 28 Jun 2003 13:21:53 -0400

The June 24 DRIP document has a problem with the use of DNS
wildcard records. Attached is an updated DRIP document and
a diff of the important changes between the two documents.

Raymond S Brand

Network Working Group                                        R. S. Brand
Internet-Draft                                                L. Sherzer
Expires: December 27, 2003                                 June 28, 2003

Status of this Memo

   This Internet-Draft will expire on December 27, 2003.

Copyright Notice

Abstract

Brand & Sherzer        Expires December 27, 2003                [Page 1]


Table of Contents

Brand & Sherzer        Expires December 27, 2003                [Page 2]


1. Introduction

1.1 Motivation

Brand & Sherzer        Expires December 27, 2003                [Page 3]


1.2 Terminology

   DNS

   IPv4

   IPv6

   ISP

   Malware

   MDA
      Mail Delivery Agent.

   Mail Relay
      See MTA.

   MTA
      Mail Transfer Agent.

   MUA
      Mail User Agent.

   Relay
      See MTA.

   SMTP

   Standardese

Brand & Sherzer        Expires December 27, 2003                [Page 4]


2. Overview

Brand & Sherzer        Expires December 27, 2003                [Page 5]


3. Designating Relays

   With:

   ${IPS}

   ${IPV}

   ${DOMAIN}

   ${TYPE}

   ${IP}
      The IP address.

Brand & Sherzer        Expires December 27, 2003                [Page 6]


   ${IPS}
      Textual representation of the IPv4 address of the Designated Relay
      in "dotted quad", also known as "dotted decimal", notation but
      with the dots replaced by underscores.  This textual
      representation was chosen to be easy for both the wetware
      components and the software components to implement the protocol.

         127_0_0_1

   ${IPV}
      "IPv4".

   ${TYPE}
      "A".

   ${IP}

   ${IPZ}

Brand & Sherzer        Expires December 27, 2003                [Page 7]


   ${IPS}
      Textual representation of the IPv6 address of the Designated Relay
      formatted as a sequence of 8 16bit words separated by underscores.
      Each word is represented by 4 hexadecimal digits. The words and
      the hexadecimal digits of a word are in network byte order. This
      IPv6 address representation is similar to the representation in
      [RFC3513] except that the colons have been replaced with
      underscores, and that leading zeros MUST be included.  This
      textual representation was chosen to be easy for both the wetware
      components and the software components to implement the protocol.

         0000_0000_0000_0000_0000_0000_0000_0001

         2002_c000_0201_0000_0000_0000_0000_1234

   ${IPV}
      "IPv6".

   ${TYPE}
      "AAAA".

   ${IP}

   ${IPZ}

Brand & Sherzer        Expires December 27, 2003                [Page 8]


3.5 Designation Examples

         None.

         None.

         192_0_2_10.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.10

         192_0_2_11.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.11

         127_0_0_1.IPv4.relays._email_.M.EXAMPLE.COM.   IN A  127.0.0.1

         None.

Brand & Sherzer        Expires December 27, 2003                [Page 9]


4. MTA Operation

Brand & Sherzer        Expires December 27, 2003               [Page 10]


4.3 DRIP Status Meanings

   DRIP_OK

   DRIP_NOT_OK

   DRIP_TEMP_FAIL

   DRIP_UNKNOWN

Brand & Sherzer        Expires December 27, 2003               [Page 11]


       192_0_2_10.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.10

       via a DNS lookup.

       192_0_2_99.IPv4.relays._email_.S.EXAMPLE.COM.  IN A  192.0.2.99

       via a DNS lookup.

Brand & Sherzer        Expires December 27, 2003               [Page 12]


       192_0_2_99.IPv4.relays._email_.EXAMPLE.COM.  IN A  192.0.2.99

       via a DNS lookup.

Brand & Sherzer        Expires December 27, 2003               [Page 13]


Brand & Sherzer        Expires December 27, 2003               [Page 14]


Normative References

Brand & Sherzer        Expires December 27, 2003               [Page 15]


Informative References

Authors' Addresses

   Raymond S Brand
   P.O. Box 100486
   Ft. Lauderdale, FL  33310
   US

   EMail: [email-masked]

   Laurence Sherzer
   P.O. Box 5072

Brand & Sherzer        Expires December 27, 2003               [Page 16]


Brand & Sherzer        Expires December 27, 2003               [Page 17]


Brand & Sherzer        Expires December 27, 2003               [Page 18]


Full Copyright Statement

Brand & Sherzer        Expires December 27, 2003               [Page 19]


Acknowledgement

Brand & Sherzer        Expires December 27, 2003               [Page 20]

--- draft-brand-drip-00.txt	Tue Jun 24 12:18:23 2003
+++ draft-brand-drip-00.txt	Sat Jun 28 11:11:16 2003
@@ -362,14 +362,15 @@
 
    ${IPS}
       Textual representation of the IPv4 address of the Designated Relay
-      in "dotted quad", also known as "dotted decimal", notation. This
-      textual representation was chosen to be easy for both the wetware
-      components and the software components to implement the protocol.
+      in "dotted quad", also known as "dotted decimal", notation but
+      with the dots replaced by underscores. This textual representation
+      was chosen to be easy for both the wetware components and the
+      software components to implement the protocol.

-         127.0.0.1
+         127_0_0_1
 
    ${IPV}
       "IPv4".
@@ -387,7 +388,6 @@

-
 
@@ -399,23 +399,23 @@
 
    ${IPS}
       Textual representation of the IPv6 address of the Designated Relay
-      formatted as a sequence of 8 16bit words separated by dots. Each
-      word is represented by 4 hexadecimal digits. The words and the
-      hexadecimal digits of a word are in network byte order. This IPv6
-      address representation is similar to the representation in
-      [RFC3513] except that the colons have been replaced with dots, and
-      that leading zeros MUST be included. This textual representation
-      was chosen to be easy for both the wetware components and the
-      software components to implement the protocol.
+      formatted as a sequence of 8 16bit words separated by underscores.
+      Each word is represented by 4 hexadecimal digits. The words and
+      the hexadecimal digits of a word are in network byte order. This
+      IPv6 address representation is similar to the representation in
+      [RFC3513] except that the colons have been replaced with
+      underscores, and that leading zeros MUST be included. This textual
+      representation was chosen to be easy for both the wetware
+      components and the software components to implement the protocol.

-         0000.0000.0000.0000.0000.0000.0000.0001
+         0000_0000_0000_0000_0000_0000_0000_0001

-         2002.c000.0201.0000.0000.0000.0000.1234
+         2002_c000_0201_0000_0000_0000_0000_1234
 
    ${IPV}
       "IPv6".
@@ -487,11 +487,11 @@

-         192.0.2.10.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.10
+         192_0_2_10.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.10
 
-         192.0.2.11.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.11
+         192_0_2_11.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.11
 
-         127.0.0.1.IPv4.relays._email_.M.EXAMPLE.COM.   IN A  127.0.0.1
+         127_0_0_1.IPv4.relays._email_.M.EXAMPLE.COM.   IN A  127.0.0.1

@@ -630,7 +630,7 @@

-       192.0.2.10.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.10
+       192_0_2_10.IPv4.relays._email_.M.EXAMPLE.COM.  IN A  192.0.2.10
 
        via a DNS lookup.
 
@@ -651,7 +651,7 @@

-       192.0.2.99.IPv4.relays._email_.S.EXAMPLE.COM.  IN A  192.0.2.99
+       192_0_2_99.IPv4.relays._email_.S.EXAMPLE.COM.  IN A  192.0.2.99
 
        via a DNS lookup.
 
@@ -678,7 +678,7 @@
 
-       192.0.2.99.IPv4.relays._email_.EXAMPLE.COM.  IN A  192.0.2.99
+       192_0_2_99.IPv4.relays._email_.EXAMPLE.COM.  IN A  192.0.2.99
 
        via a DNS lookup.

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 29 Jun 2003 14:55:33 -0400

At 01:21 PM 6/28/2003 -0400, Raymond S Brand wrote:

>[..]
>[..]

How is this proposal different from RMX proposal by Hadmut Danisch 
(http://www.ietf.org/internet-drafts/draft-danisch-dns-rr-smtp-02.txt) and 
the various other rDNS proposals (see Mike Rubel's page at 
http://www.mikerubel.org/computers/rmx_records/).

Yakov 

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Richard Rognlie <[email-masked]>
Date: Sun, 29 Jun 2003 11:11:31 -0400

> http://www.mikerubel.org/computers/rmx_records/).

RMX (et al) deal with the envelope from address.  This proposal has
nothing to do with the envelope.  It is an attempt to sanitize the
hostname specified as the HELO/EHLO when connecting to a remote 
MTA.

IOW,  If I connect to a remote MTA and my MTA sends the greeting
EHLO play.gamerz.net.  That MTA can do a lookup of
my_ip_ad_dr._relays_._email_.play.gamerz.net and see immediately
that if it gets my.ip.ad.dr as the response, that, indeed, I am
a DRIP subscribed host.  If any other host attempts to connect
and claim to be play.gamerz.net, the IPs will not match (or there
will be no record at all).

If the IPs do not match, it is a host forging my hostname.  Drop
the connection like a hot potato[e].  If no record is returned at all
I can't glean anything (yet).  The RECOMMENDED behaviour is to 
stop dropping hostname parts...
    my_ip_ad_dr._relays_._email_.gamerz.net 
    my_ip_ad_dr._relays_._email_.net 

If either of those return a value, I can say "gamerz.net" does claim
to support DRIP records.  but since play.gamerz.net was not found
that host is not authorized to send mail OUT...  It should have sent
mail via the designated gamerz.net relay.  And as such, I should 
drop this connection.

If no records of any kind are found (even when searching the parents)
I know this domain does not subscribe to the DRIP idea.  I can't
assume anything.  But long(ish) term, if enough domains adopt DRIP,
MTAs might adopt a "if I can't get your DRIP records I won't talk to 
you"  (much like the current "if I can't resolve your reverse DNS,
I won't talk to you")

Richard "who should be working on the DRIP milter, but its too nice
outside, so is going to the pool" Rognlie

-- 
 /  \__  | Richard Rognlie / Oracle Prophet / Gamerz.NET Lackey
 \__/  \ | http://www.gamerz.net/rrognlie/    <[email-masked]>
 /  \__/ | The past is the future
 \__/    |                  Nobody expects the spammish inquisition

---

From: Richard Rognlie <[email-masked]>
Date: Sun, 29 Jun 2003 11:17:26 -0400

> the connection like a hot potato[e].  If no record is returned at all

D'oh!  I forgot to mention.  We don't actually drop the connection here.
We can't.  It might be a host that is doing the EHLO in preparation
for an SMTP AUTH session for a true "local" user, who happens to be
roaming.   We don't start rejections until later (during the env-from
when I can check the status of the SMTP AUTH flags [in the milter
implementation, anyway.  other MTA implementations methodologies may
vary])

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 29 Jun 2003 15:18:48 -0400

>implementation, anyway.  other MTA implementations methodologies may

Very good point. We can probably drop the connection after MAIL FROM or 
RCPT TO.

Yakov

---

From: Richard Rognlie <[email-masked]>
Date: Sun, 29 Jun 2003 11:21:42 -0400

On Sun, Jun 29, 2003 at 03:15:26PM -0400, Yakov Shafranovich wrote:
> At 11:11 AM 6/29/2003 -0400, Richard Rognlie wrote:
> 
> Dealing with the return envelope has its own problems (DSN messages with 
> empty MAIL FROM <>) so it seems that dealing with the HELO/EHLO is better. 
> BUT, the bottom line is that both proposals are DNS based and propose 
> additional DNS records. Whether the filtering is done on HELO/EHLO level or 
> return envelope is something to be left to the implementators. Both 
> proposals are basically the same - they are mandating DNS records.

Just additional records.  Not any additional record types.
And as such, we are not at the mercy of waiting for any particular
flavor of BIND to work its way out into the mainstream.

FWIW, this is part 1 of 2 proposals.    Ray (and his hearty band of cohorts)
will be working on the 2nd part [formalizing it] soon.   It will be
working on the validity of the headers (not the env-from, but the
*whole* bunch of headers).  but I'll leave it's discussion to him.  

It's *verra nice...*

---

From: Yakov Shafranovich <[email-masked]>
Date: Sun, 29 Jun 2003 15:23:30 -0400

>flavor of BIND to work its way out into the mainstream.

Would it be logical to combine all the RMX/RDNS/etc proposals into one 
cohesive document?

>*whole* bunch of headers).  but I'll leave it's discussion to him.

Thanks for the information.

---

From: Richard Rognlie <[email-masked]>
Date: Sun, 29 Jun 2003 11:41:23 -0400

> Would it be logical to combine all the RMX/RDNS/etc proposals into one 

Perhaps eventually.  But for now, we're searching for ideas that 
can be cobbled together which we can use separately to incrementally
start beating spam into submission...

Someday, it may make sense to combine them all into a unified best
practices RFC which can be used to rule the galaxy^W^W^Wmake the 
internet a nicer place for everyone.  But not be soo draconian
that individuals can't see over the bar.

---

From: [email-masked]
Date: Sun, 29 Jun 2003 10:10:35 -0700 (PDT)

> will be no record at all).

You can already do this by setting proper reverse dns ip for the record
and reverse dns does allow for multipe names for the ip. So this is a
a proposal that indends to allow equvalent of reverse dns check for
when company running mail server does not have access to set reverse
dns as it wishes. 

As such I'm a lot more afraid of this being used by spammers themselve 
when they are hijacking ip space, using proxies, dialup, etc. Many 
spammers do have domains they have no problem letting everybody else know 
about as part of EHLO, in the envelope from, etc - domains are cheap 
and entering bogus data there is easy - so they can afford to register 
one new domain for each dozen million emails sent (i.e. one or more new 
domain every day...).

Long ago I also mentioned that good dns check/security model should 
not be tying authorization to direct dns alone but to direct dns AND 
reverse dns as well (so that we have two separate distinct authenticion
paths and two sets of authorities to confirm your identity in a way
- this will also stop spammers from being able to so easily get and use 
new virtual identites/domains. And yes, I know  many do not like this 
because they run their mail servers on dsl, but in reality even for dsl, 
you should be able to get reverse dns set properly to your mail server 
even if you only have one ip ip (as long as its not dynamic). 

And going futher on this, I'v thought about it for a while actually and 
came to conclusion that reverse dns records should be used to authenticate
servers (like now) but stronger authentication methhods should be used, 
I'd favor SSL certificates, self-signed and tied to special reverse dns
record. And for those who can not control reverse dns a workaround can be 
provided by having well known certificate authority also sell similar 
certificates. I'll provide details on this and number of my other proposals
some time in the future, when I think through research group is a little 
better organized...

---
William Leibzon
Elan Communications Inc. 
[email-masked]

---

From: Raymond S Brand <[email-masked]>
Date: Mon, 30 Jun 2003 12:44:01 -0400

Please do NOT copy me when sending to the ASRG list.

The big difference is what is verified. DRIP verifies that
the DOMAIN used in the HELO/EHLO command is permitted from
the client  IP address; RMX verifies that the DOMAIN used in
the envelope is permitted from the client IP address.

DRIP is more about reducing the amount of spewed payload from
virus infected systems than anything else.

DRIP and RMX compatible in that both can be used together.

Raymond S Brand

---

From: Raymond S Brand <[email-masked]>
Date: Mon, 30 Jun 2003 13:00:19 -0400

Please do NOT copy me on mail sent to the ASRG list.

> > At 11:11 AM 6/29/2003 -0400, Richard Rognlie wrote:
...
> flavor of BIND to work its way out into the mainstream.

In comparison to RMX, the records required by DRIP are in the zones that
the domain name owners administrate (or pay someone to administrate);
whereas, the records required by RMX are in the in-addr.arpa, or IPv6
equivalent, which is usually administered by some other entity. RMX
query result can be huge; DRIP query results are small (singe A record).

> *whole* bunch of headers).  but I'll leave it's discussion to him.

Actually, it validates the envelope from also.

BTW, Richard is one of the cohorts.

Raymond S Brand