[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
Network Working Group                                       S. Moonesamy
Internet Draft                                             May 25,  2009
Intended status: Standards Track
Expires: November 24, 2009

         SMTP Recipient Address Verification Using the Dynamic
                  Delegation Discovery Service (DDDS)
                 draft-moonesamy-smtp-vrfy-ddds-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 November 24, 2009.

   Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before
   November 10, 2008.  The person(s) controlling the copyright in
   some of this material may not have granted the IETF Trust the
   right to allow modifications of such material outside the



S. Moonesamy       Expires November 2009                        [Page 1]


Internet Draft     SMTP verification using DDDS                 May 2009


   IETF Standards Process.  Without obtaining an adequate license
   from the person(s) controlling the copyright in such materials,
   this document may not be modified outside the IETF Standards
   Process, and derivative works of it may not be created outside
   the IETF Standards Process, except to format it for publication
   as an RFC or to translate it into languages other than English.

Abstract

   This memo proposes a mechanism based on the Dynamic Delegation
   Discovery Service (DDDS) which can be used for the verification
   of SMTP recipient addresses.







































S. Moonesamy       Expires November 2009                        [Page 2]


Internet Draft     SMTP verification using DDDS                 May 2009


1. Introduction

   SMTP servers for a domain identified through higher numbered MX
   records are sometimes specifically targetted for mail delivery as
   they do not enforce the same policies for the domain.  This can
   generate backscatter where the message is accepted by a SMTP server
   and bounced because the SMTP recipient address was rejected by a
   SMTP server further down in the delivery path, generally identified
   by a lower numbered MX record, to a mailbox that did not elect to
   receive the non-delivery notification message.

   SMTP provides a VRFY command [RFC5321] to verify a user name.  This
   command is generally disabled in SMTP server implementations for
   security reasons.  Some SMTP clients get around that by doing a
   partial mail transaction without proceeding to the third step
   (DATA command).  This document proposes a mechanism based on the
   Dynamic Delegation Discovery Service (DDDS) [RFC3401][RFC3402]
   [RFC3403][RFC3404] where the local-part of a RFC 5321 [RFC5321]
   address is associated with a Naming Authority Pointer (NAPTR) DNS
   Record Resource [RFC3403].  This mechanism can be used for the
   verification of SMTP recipient addresses.

   Subaddressing is the practice of augmenting the local-part of an
   RFC 5321 address with some "detail" information in order to give
   some extra meaning to that address.  One common way of encoding
   "detail" information into the local-part is to add a "separator
   character sequence", such as "+", to form a boundary between the
   "user" (original local-part) and "detail" sub-parts of the address,
   much like the "@" character forms the boundary between the local-part
   and domain.  The NAPTR Record Resource was chosen as it is a Record
   Resource (RR) that includes a a regular expression.  That can be used
   to support subaddressing.

1.1.  Comments

   Comments and discussions about this draft can be directed to the
   SMTP mailing list, ietf-smtp, maintained at imc.org.
   [RFC Editor: Please remove this subsection]

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

3. VRFY Application

   The VRFY Application uses the NAPTR RR to map the local-part



S. Moonesamy       Expires November 2009                        [Page 3]


Internet Draft     SMTP verification using DDDS                 May 2009


   of a RFC 5321 address to a regular expression.  SMTP servers
   can use the regular expression to verify local-part and "detail"
   of a RFC 5321 address.

   The maximum total length of a user name or other local-part, as
   defined in RFC 5321, is 64 octets.  It is important to note that
   domain labels are limited to 63 characters in length and the
   total length of the resulting string must be 255 octets or
   less [RFC1035].  For the purposes of this specification, the
   local-part of a RFC 5321 address for the VRFY Application
   MUST be not be more than the limit defined for a domain label in
   [RFC1035].

3.1. Application Usage String

   The application unique string is a RFC 5321 address limited to 63
   characters.

3.2. First Well Known Rule

   The first known key is the local-part of the RFC 5321 address.  For
   example, postmaster@example.com would have "postmaster" as its first
   key.

3.3 Expected Output

   The output of the First Well Known Rule for the VRFY Application
   is a regular expression.  The "regexp" field is defined in [RFC3402]
   as consisting of a "delim-character", a POSIX Extended Regular
   Expression, a "delim-character" and a final "delim-character".
   The regular expression MUST match a valid local-part as defined for a
   RFC 5321 address.  For this application the following rules apply:

   The "delim-character" MAY be any valid character as defined in
   section 3.2 of [RFC3402].

   The regular expression MUST NOT contain a substitution expression.

   The "replacement" field MUST be empty.

3.4. Valid Databases

   A DDDS Database is specified for this Application.  The Keys for
   this database are encoded as domain names.  The characters allowed
   to be in a Key are those that are currently defined for DNS domain
   names.

   The string "._vrfy._smtp._tcp." is appended to the output



S. Moonesamy       Expires November 2009                        [Page 4]


Internet Draft     SMTP verification using DDDS                 May 2009


   of the First Well Known Rule.  The domain name part of the RFC 5321
   address is then appended to the end.

3.5. Flags

   The "flags" field MUST contain the character "U".

   The "order" and "preference" fields are to be processed as
   specified in [RFC3403].  If multiple records are returned, the
   one(s) with the lowest "order" value that have a matching
   "service" field MUST be used.  Of those with the lowest order
   value, those with the lowest "preference" SHOULD be used.

3.6. Service Parameters

   The "services" field MUST only contain the string "SMTP+VRFY".

4. Example

   $ORIGIN example.com.
   user._vrfy._smtp._tcp    IN NAPTR  10 1 (  ; order pref
                        "u" "SMTP+VRFY"       ; flags service
                        "!^(user)$!!" .       ; regexp replacement
                        )

   The result of the extraction of the local-part of the RFC 5321
   address, user@example.com, is "user".  The "separator character
   sequence" and "detail" are removed from the extracted string if
   subaddressing is used.  The "user" (original local part) becomes
   the Application Usage String.  The NAPTR RR to lookup is
   "user._vrfy._smtp._tcp.example.com.".  The record returned is in
   the form:

   user._vrfy._smtp._tcp.example.com. IN NAPTR
   ;;  order   pref flags service      regexp             replacement
        10     1     "u"  "SMTP+VRFY"  "!^(user)$!!"        .

   The regular expression in the record is "!^(user)$!!".  The "!"
   character is used to delimit the parts of the substitution
   expression.  The replacement field is empty.  There is a match when
   the regular expression is applied to the local-part and "detail" of
   the RFC 5321 address being verified.

5. Security Considerations

   The SMTP VRFY command [RFC5321] is generally disabled in SMTP
   servers due to security considerations.  It is recommended to
   use transaction level authentication such as Secret Key



S. Moonesamy       Expires November 2009                        [Page 5]


Internet Draft     SMTP verification using DDDS                 May 2009


   Transaction Authentication for DNS (TSIG) [RFC2845] or access
   control mechanisms to restrict access to the DDDS database.  Domain
   Name System Security Extensions (DNSSEC) [RFC4033] can be used to add
   data origin authentication and data integrity.

   The amount of DNS queries generated by implementations can be
   substantial.  Without the appropriate DNS infrastructure, that
   can cause a denial of service.

   Regular expressions should be checked for sanity, not blindly
   passed.

6. Internationalization Considerations

   Non-ASCII characters in domain names are encoded using the
   Internationalizing Domain Names in Applications specification
   [RFC3490].

7. IANA Considerations

   The IANA maintains an Application Service Tag Registry for the
   S-NAPTR DDDS application defined in [RFC3958].  The IANA is advised
   that although the application defined in this document is not a
   S-NAPTR DDDS application, it defines a "SMTP+VRFY" value for the
   "services" field.  That value should not be used in the Application
   Service Tag Registry for other applications.

8. Acknowledgements

   The idea of using DNS for recipient address verification originated
   from David Skoll during a discussion about SMTP in May 2007.

9.  References

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

   [RFC3402]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Two: The Algorithm", RFC 3402, October 2002.

   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Three: The Doman Name System (DNS) Database",
              RFC 3403, October 2002.



S. Moonesamy       Expires November 2009                        [Page 6]


Internet Draft     SMTP verification using DDDS                 May 2009


   [RFC3404]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Four: The Uniform Resource Identifiers (URI)
              Resolution Application", RFC 3404, October 2002.

   [RFC5321] Klensin, J., "Simple Mail Transfer Protocol",
              RFC 5321, October 2008.

9.2.  Informative References

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake, D., and
              B. Wellington, "Secret Key Transaction Authentication for
              DNS (TSIG)", RFC 2845, May 2000.

   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part One: The Algorithm", RFC 3401, October 2002.

   [RFC3490]  Faltstrom, P., Hoffman, P., and A. Costello,
              "Internationalizing Domain Names in Applications (IDNA)",
              RFC 3490, March 2003.

   [RFC3958]  Daigle, L. and A. Newton, "Domain-Based Application
              Service Location Using SRV RRs and the Dynamic Delegation
              Discovery Service (DDDS)", RFC 3958, January 2005.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and
              S. Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

Author's Address

   S. Moonesamy
   76, Ylang Ylang Avenue
   Quatre Bornes
   Mauritius

   Email: sm+ietf@elandsys.com















S. Moonesamy       Expires November 2009                        [Page 7]