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]