MARID                                                            D. Otis
Internet-Draft                              Mail Abuse Prevention System
Expires: February 8, 2005                                August 10, 2004


                       Mail Policy Records (MPR)
                        draft-otis-marid-mpr-00

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   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 February 8, 2005.

Copyright Notice

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

Abstract

   For domains sending or receiving mail, there is often a desire to
   publish policies indicating types of mail sent or accepted, and to
   specify the collateral Mail Channel to assist in these policies.  The
   challenge is to allow the recipient a deterministic means for
   obtaining this information, while not creating additional burdens for
   normal mail use.

   Need for a domain based mail policy facility has become pronounced as
   many institutions find their mailboxes forged to usurp and thus
   damage their trust relationships.  For these exigent situations, it



Otis                    Expires February 8, 2005                [Page 1]

Internet-Draft                  Mail-PR                      August 2004


   could be advantageous, as example, to request refusal of mail where
   the [RFC2822] From of Mailbox Domain does not indicate being from the
   prescribed Mail Channel.  These policies may include other
   prescriptions, such as all outbound mail is digitally signed.

Table of Contents

   1.   Overview . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.   Background . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.   Policy Records . . . . . . . . . . . . . . . . . . . . . . .   4
   5.   Mail Policy Resource Record  . . . . . . . . . . . . . . . .   6
   6.   Mail Channel Name List . . . . . . . . . . . . . . . . . . .   7
   7.   Mail Channel Address List  . . . . . . . . . . . . . . . . .   7
   8.   Domain administrator advice  . . . . . . . . . . . . . . . .   7
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .   8
   10.  References . . . . . . . . . . . . . . . . . . . . . . . . .   8
   10.1   Normative References . . . . . . . . . . . . . . . . . . .   8
   10.2   Informative References . . . . . . . . . . . . . . . . . .   9
        Author's Address . . . . . . . . . . . . . . . . . . . . . .  10
   A.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  10
        Intellectual Property and Copyright Statements . . . . . . .  11





























Otis                    Expires February 8, 2005                [Page 2]

Internet-Draft                  Mail-PR                      August 2004


1.  Overview

   Terminology:  Terminology conforms to [ID-mail-arch].

   Terms used in the context of this document:
      Mail Channel- a prescribed set of Mail Transfer Agents identified
      by either a list of HELO/EHLO domains or IP addresses in CIDR
      notation.

      Mailbox Domain- the portion of the mailbox address on the right
      hand side of the "@" symbol.

   Discussion:  The venue for discussing this proposal is the IETF MARID
      working group.  [1]


2.  Introduction

   With the DNS records proposed, domains MAY publish a Mail Policy
   Record (MPR) indicating policies for the use of that domain name, and
   possibly prescribing the Mail Channel Name List (MCNL) or the Mail
   Channel Address List (MCAL) records, for lists of associated HELO/
   EHLO names or client IP addresses to assist assessments by the mail
   recipient.  Mail Channel prescriptions for Mailbox Domain assessments
   assume administrative control over shared access for such assertions
   to produce a desirable result.  As such, Mail Channel prescriptions
   are limited to situations where access to the Mail Channel can be
   assured as a means to protect a trust relationship with the sending
   domain and the recipients.  Prescribing the Mail Channel for Mailbox
   Domains is not appropriate with many configurations and uses, as it
   could invite the problem a Mail Channel prescription attempts to
   curtail.

   Domains wishing to assert limited use of their Mailbox Domain, to
   assist recipients detect nonconforming mail, express this by
   publishing a DNS Mail Policy record.  There is a DNS resource record
   used to indicate mail polices, and two types of records to prescribe
   the Mail Channel either by HELO/EHLO names or IP addresses.  The Mail
   Policy Record (MPR) indicates the sending and receiving policies.
   The Mail Channel Address List (MCAL) enables an exception or
   white-listing that may be applied when processing forwarded mail.
   The Mail Channel Name List (MCNL) may be applied to assert the
   limited use of [RFC2821] or [RFC2822] Mailbox Domains.

3.  Background

   A concise means to prescribe the Mail Channel is needed to establish
   a determinate burden for the recipient.  This method should also



Otis                    Expires February 8, 2005                [Page 3]

Internet-Draft                  Mail-PR                      August 2004


   naturally delegate to other domains without requiring follow-on
   queries.  When considering possible schemes available, there are two
   related methodologies which enable such a solution.  These two
   methods are defined within Client SMTP Validation (CSV)
   [ID-Marid-CSV] and Bounce Address Tag Validation [ID-BATV].  By
   listing authenticated and authorized HELO/EHLO domains to prescribe
   the Mail Channel, there is no need to resolve to an address.  In the
   case of a message being forwarded, verifying the signature of the
   local-part of the [RFC2821] MAIL FROM as provided by Bounce Address
   Tag Validation [ID-BATV] removes the need to decipher the proximal
   [RFC2822] header.  As an alternative to signature checking, the
   forwarding domain may publish its white-list using a CIDR based
   record list.

   An important aspect found combining these methods, is that
   information is obtained from a deterministic single query for each
   instance.  The overhead for such is then confined to this single DNS
   lookup and found within a single DNS answer.  This becomes important
   when considering the impact on the DNS cache and the relative amount
   of UDP traffic imposed upon the network.  These deterministic aspects
   become attractive from the aspect of relative cost, security and
   network integrity.  It should also be noted [RFC2822] headers are
   often spoofed and can not safely determine the message's origin.
   There is no means to determine the integrity of the Mail Channel and
   generally should be assumed insecure.

4.  Policy Records

   There are three DNS records defined by this document.  Each of these
   records are obtained by prepending the "_mp._smtp." sub-domains to
   the Mailbox Domain reference.  The Mail Policy record types delineate
   their content.  Rather than using a TXT RR with notations defined by
   Augmented BNF for Syntax Specifications (ABNF) [RFC2234] for later
   processing with a requisite parser, the Mail Policy Record (MPR) is
   defined as a single encoded IPv4 address record, the list of HELO/
   EHLO domain names (MCNL) is defined using PTR records, and the
   address list of the Mail Channel (MCAL) is defined using APL records
   defined in A DNS RR Type for Lists of Address Prefixes [RFC3123].

   If there is a Mail Channel for the [RFC2822] From Mailbox Domain,
   then forwarding by the recipient may be allowed to then rely upon
   [RFC2821] MAIL FROM local part signatures as defined in Bounce
   Address Tag Validation [ID-BATV] or upon specific forwarding domains
   having been white-listed by the receiving MTA of the forwarded mail.

   There are two fields that may reference specific policies, the
   [RFC2821] MAIL FROM, and the first Mailbox Domain in the [RFC2822]
   From.  The process of deciding on the policies indicated by these two



Otis                    Expires February 8, 2005                [Page 4]

Internet-Draft                  Mail-PR                      August 2004


   fields requires performing a series of conceptually discrete steps:

   Mailbox Domain Policy:
      What are the requested policies for the Mailbox Domain in
      question?

      This is obtained by performing an MPR, an IPv4 address record,
      lookup and analyzing the lower 24 bits of the returned address.



   Permitted Mailbox Domain Channel:
      Should mail be accepted, if the Mailbox Domain restricts allowable
      HELO/EHLO domain names? Acceptance is then determined by
      performing a MCNL PTR record lookup and finding a match with the
      current CSV HELO/EHLO domain name.  Domain names within the MCNL
      are treated as being wildcarded to allow matches with all
      sub-domains.  If the mail is not accepted and no exceptions are
      possible, then MTAs performing the Mail Channel check as part of
      receiving a message SHOULD reject that message with either "550
      MAIL FROM Channel Failure." or "550 From Channel Failure."
      depending upon the field causing the rejection.

      There may be exceptions made with forwarded mail.  Alternative
      rules may apply when restrictions are placed upon the Mailbox
      Domain and the Mail Channel fail in the case where the mail has
      been forwarded.

   Permitted Channel Failure:
      Should the mail be accepted, if the Mailbox Domain restricts
      allowable HELO/EHLO domain names, but the name does not match?
      Acceptance is then determined by the use of BATV and Return Path
      Validation when permitted by Mailbox Domain policy.  If the BATV
      Return Path Validation is attempted but fails, " BATV check
      unsuccessful." should be appended to the error message sent upon
      rejection.



   Return Path Validation and Permitted Channel Failture:
      Should the mail be accepted, if the Mailbox Domain restricts
      allowable HELO/EHLO domain names, but the name does not match, and
      there is no Return Path Validation? Acceptance may also be
      determined by a rule established by the domain administrator of
      the receiving MTA that then allows preforming an MCAL APL lookup
      for predefined domains.  Should the current IP address of the
      remote client then be included within the list, the mail is
      accepted.  In other words, is the sender white-listed? The rule of



Otis                    Expires February 8, 2005                [Page 5]

Internet-Draft                  Mail-PR                      August 2004


      allowable Mailbox Domains may be categorized based upon the mail
      recipient.


5.  Mail Policy Resource Record

   The Mail Policy RR is an encoded A record with bit values used to
   indicate policy requests.

   _mp._smtp.domain IN A 127.<version>.<send>.<req>

   The address octets are treated independently.  The most significant
   octet is always the value of 127 decimal; see [RFC3330].  The Version
   octet defines the revision level of this mechanism starting at 1.
   The Send and Request octets comprise a summation of values used to
   provide various indications.

   +--------------+----------------------------------------------------+
   |   Send Bit   | Meaning                                            |
   |     Value    |                                                    |
   +--------------+----------------------------------------------------+
   |       1      | BATV: This domain uses public key BATV for all     |
   |              | sent messages.                                     |
   |       2      | Signed: This domain uses public key digital        |
   |              | signatures for all sent messages.                  |
   |       4      | WhiteList: This domain provides a comprehensive    |
   |              | MCAL list of all outbound SMTP clients.            |
   |       -      | Other bit values are reserved for expansion and    |
   |              | must be set to zero.                               |
   +--------------+----------------------------------------------------+

   +--------------+----------------------------------------------------+
   |    Req Bit   | Meaning                                            |
   |     Value    |                                                    |
   +--------------+----------------------------------------------------+
   |       1      | MailFrom: The Mail Channel prescribed in the MCNL  |
   |              | RR should be the exclusive source of this MailBox  |
   |              | Domain for the MAIL FROM parameter.                |
   |       2      | From: The Mail Channel prescribed in MCNL RR       |
   |              | should be the exclusive source of this MailBox     |
   |              | Domain for the From header.                        |
   |       4      | Ignore BATV: Return Path Validation by BATV should |
   |              | not be used for acceptance when a Mail Channel     |
   |              | check fails.                                       |
   |       -      | Other bit values are reserved for expansion and    |
   |              | must be set to zero.                               |
   +--------------+----------------------------------------------------+




Otis                    Expires February 8, 2005                [Page 6]

Internet-Draft                  Mail-PR                      August 2004


6.  Mail Channel Name List

   The Mail Channel Name List RR is comprised of a series of PTR
   records.  As example:

   _mp.smtp.domain.  IN PTR our-domain.com
   _mp.smtp.domain.  IN PTR our-access-provider.com

   The target of the PTR record should be treated as a wildcarded record
   when doing a comparison with the HELO/EHLO domain presented by the
   CSV process.  Taking the example our-domain.com would then match with
   the HELO/EHLO domain mx01.sjc.our-domain.com.

7.  Mail Channel Address List

   The Mail Channel Address List RR is comprised of a series of APL
   records.  As example:

   _mp.smtp.domain.  IN APL 1:192.168.32.0/21 !1:192.168.38.0/28

   The use of the address negation "!" is to exclude a range of
   addresses from a larger list.  These lists of CIDR blocks are used to
   enable the white-listing of this domain for the purposes of
   selectively enabling this domain to forward mail.  If the WhiteList
   value is present in the Mail Policy record, then it can be assumed to
   be representative of all mail sent by this domain with respect to any
   channel restrictions.

8.  Domain administrator advice

   The use of the MCAL as a white-listing tool may be extended to other
   uses.  The lack of a WhiteList value in the Send field of the MPR is
   intended to indicate the list is not comprehensive and only suitable
   for qualifying forwarded mail.  In this case, other types of mail may
   be sent from servers not included in this list when the WhiteList
   value is not asserted.

   Currently the DNS structures within the UDP packet has a limit of 512
   octets.  Replies requiring more than 512 octets may create UDP
   fragmentation and, depending upon the connection and handling, in
   addition to a higher rate of packet loss, may also cause truncated or
   partial replies.  Furthermore, delivery and resolver handling of
   truncated and partial responses varies, leading to additional delays
   and queries.  Domain administrators are strongly advised to keep DNS
   replies below 512 octets for these reasons.

   With a complete response to an MCAL or MCNL query, SMTP server is
   able to implement the policies being requested.  To help ensure



Otis                    Expires February 8, 2005                [Page 7]

Internet-Draft                  Mail-PR                      August 2004


   complete and coherent answers are obtained from cached records, TTL
   values of the MPR, MCAL and MCNL records should be the same.  Beware
   some DNS server implementation consider the SOA TTL as a default
   rather than a minimum.

9.  Security Considerations

   The HELO/EHLO domain contained in the most recently added [RFC2822]
   Received headers should be visible to the user of the MUA to guard
   against address spoofing.  Successful CSV authentication should
   append an "*" following the HELO/EHLO domain name in the Received
   header.  A message being within the prescribed Mail Channel should
   also be visible to the user of the MUA to help guard against the use
   of sub-domains.  If a domain applies mail policies to a domain, then
   all sub-domains used for mail must also implement mail policies.

   The nature of the security requirements for Mail Policies are
   significantly different from typical, "strong" methods required for
   most Internet security functions.

   The proposal also relies on security of the underlying IP network and
   on the integrity of DNS data.  It performs a basic authentication of
   the mail, based on domain name registration of the client IP Address.

   There is no way a site can keep its hosts from being referenced as
   servers.  This could lead to denial of service.

   DNS spoofers can supply false addresses.  To decrease the success
   rate for this type of attack, the source port for DNS queries
   appearing on the Internet should be from random ports.  Because this
   vulnerability exists already with names and addresses, this is not a
   new vulnerability, merely a slightly extended one.  However, as Mail
   Policy records are used in an authorization context, the DNS servers
   can be protected by DNSSEC [RFC3008] should this vulnerability become
   intractable.

   The proposal relies on the integrity and authenticity of DNS data.

10.  References

10.1  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
              1981.

   [RFC0821]  Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC
              821, August 1982.




Otis                    Expires February 8, 2005                [Page 8]

Internet-Draft                  Mail-PR                      August 2004


   [RFC0822]  Crocker, D., "Standard for the format of ARPA Internet
              text messages", STD 11, RFC 822, August 1982.

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

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC2234]  Crocker, D., "Augmented BNF for Syntax Specifications",
              RFC 2234, November 1997.

   [RFC2554]  Myers, J., "SMTP Service Extension for Authentication",
              RFC 2554, March 1999.

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

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

   [RFC3008]  Wellington, B., "Domain Name System Security (DNSSEC)
              Signing Authority", RFC 3008, November 2000.

   [RFC3123]  Koch, P., "A DNS RR Type for Lists of Address Prefixes",
              RFC 3123, June 2001.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, February 2002.

   [RFC3330]  "Special-Use IPv4 Addresses", RFC 3330, September 2002.

10.2  Informative References

   [ID-BATV]  Crocker, D., "Bounce Address Tag Validation (BATV)",
              August 2004.

   [ID-CSVCSA]
              Otis, D., Crocker, D. and J. Leslie, "sending SMTP client
              Authorization (CSA)", June 2004.

   [ID-Marid-CSV]
              Crocker, D., Otis, D. and J. Leslie, "Client SMTP
              Validation (CSV)", July 2004.



Otis                    Expires February 8, 2005                [Page 9]

Internet-Draft                  Mail-PR                      August 2004


   [ID-Marid-CSVDNA]
              Leslie, J., Crocker, D. and D. Otis, "Domain Name
              Accreditation (DNA)", July 2004.

   [ID-mail-arch]
              Crocker, D., "Internet Mail Architecture", May 2004.

URIs

   [1]  <http://ietf.org/html.charters/marid-charter.html>


Author's Address

   Douglas Otis
   Mail Abuse Prevention System
   1737 North First Street, Suite 680
   San Jose, CA  94043
   USA

   Phone: +1.408.453.6277
   EMail: dotis@mail-abuse.org

Appendix A.  Acknowledgements

   John Leslie provided helpful editorial comments.

























Otis                    Expires February 8, 2005               [Page 10]

Internet-Draft                  Mail-PR                      August 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

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




Otis                    Expires February 8, 2005               [Page 11]