IETF A. Vesely
Internet-Draft July 15, 2013
Intended status: Informational
Expires: January 16, 2014
DNSWL Email Authentication Method Extension
draft-vesely-authmethod-dnswl-00
Abstract
This document describes a method that can be registered within the
Email Authentication Methods IANA registry created by RFC 5451. The
method consists in looking up a DNS whitelist.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 16, 2014.
Copyright Notice
Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Vesely Expires January 16, 2014 [Page 1]
Internet-Draft DNSWL email-auth-method extension July 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Method Results . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
4. Implementation Status . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.1. Normative References . . . . . . . . . . . . . . . . . . . 6
6.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Example . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Vesely Expires January 16, 2014 [Page 2]
Internet-Draft DNSWL email-auth-method extension July 2013
1. Introduction
One of the many checks that mail servers carry out is to query DNS
whitelists (DNSWL, [RFC5782]). The semantics of DNSWL is similar to
that of Vouch By Reference (VBR, [RFC5518]); that is, an external
organization, trusted by the receiving mail transfer agent (MTA),
vouches for the sender.
Differently from VBR, the lookup is based on the IP address. That
allows it to occur very early in an SMTP transaction, and thus it can
be used to counterweight policies that typically occur at those early
stages too, such as the Sender Policy Framework (SPF, [RFC4408]).
Nevertheless, the result of a DNSWL lookup is likely used at later
stages as well; for example, a delivery agent can use it to estimate
the spamminess of an email message. Reusing the previously obtained
result is more consistent than issuing multiple queries, and saves
resources.
2. Method Results
In this document, the acronym DNSWL is used both to refer to a
generic organization that publishes a whitelist, and to indicate the
use of such service, that is the method. The organization defines
the DNS zone and the record type(s) to be queried, as well as the
meaning of the listings and the procedures to maintain them.
Unlike other methods, such as dkim or spf, there is little or no work
to be carried out by the receiving MTA on the values retrieved from
the DNS query. As explained in Section 2.3 of [RFC5782], DNSWLs
encode taxonomical details about the mail sender as bit masks of type
A records. The receiving MTA just needs to work out whether the data
returned is at all applicable. In that case, it uses that data as an
outsourced extension of its local policy. Thus, in a broad sense,
the result of the method is the content returned by the query:
dns.zone: The name of the DNSWL, which defines the meaning of the
result. If the MTA uses a private mirror, this can be
different from the zone actually queried.
policy.ip: The bit mask value. This entry ("propspec" in the
grammar of [I-D.ietf-appsawg-rfc5451bis]) can be repeated
if the DNSWL returns multiple A records.
policy.txt: The TXT record, or the relevant part of it, if any. This
can contain a domain name or an abuse reporting address,
which can be used as described in Section 5.3 of
[RFC6650].
Vesely Expires January 16, 2014 [Page 3]
Internet-Draft DNSWL email-auth-method extension July 2013
In a strict sense, the result of the method states how the query did:
pass: The query successfully returned applicable records.
fail: The query worked, but no applicable record was found.
temperror: There was a transient problem with the query.
permerror: There is a setup problem, the query cannot work.
3. IANA Considerations
There is a registry of Email Authentication Methods created by
RFC5451. The method described in this document is referred by
Table 1, it has three ptype.Property values detailed in Table 2.
[TO BE REMOVED: The registry is currently accessible here:
http://www.iana.org/assignments/email-auth/email-auth.xhtml \
#email-auth-methods ]
+--------+--------------+---------+
| Method | Defined | version |
+--------+--------------+---------+
| dnswl | [this rfc??] | 1 |
+--------+--------------+---------+
Table 1: Method name, definition, and version
+--------+----------+---------------------------+--------+
| ptype | Property | Value | Status |
+--------+----------+---------------------------+--------+
| dns | zone | The origin of the results | active |
| policy | ip | type A result | active |
| policy | txt | type TXT result | active |
+--------+----------+---------------------------+--------+
Table 2: Method values
In addition, this method reuses four of the values already defined in
the Email Authentication Result Names associated registry. They are
listed in Table 3.
[TO BE REMOVED: The registry is currently accessible here:
http://www.iana.org/assignments/email-auth/email-auth.xhtml \
#email-auth-result-names ]
Vesely Expires January 16, 2014 [Page 4]
Internet-Draft DNSWL email-auth-method extension July 2013
+-----------+-----------+--------+
| Code | Meaning | Status |
+-----------+-----------+--------+
| pass | Section 2 | active |
| fail | Section 2 | active |
| temperror | Section 2 | active |
| permerror | Section 2 | active |
+-----------+-----------+--------+
Table 3: Method results
4. Implementation Status
[Note to RFC Editor: please remove this entire section before
publication.]
This section records the status of a known implementation of the
method described in this document at the time of writing, based on a
proposal described in [I-D.sheffer-running-code]. See that document
for further boilerplate.
Courier-MTA is a full-featured, mature mail server, first publicly
released in May 2000. A beta release in February 2013 introduced
Authentication-Results in combination with DNS-based whitelists.
This document is based on that implementation, which made it to
production release 0.71, after one month testing. End-user
documentation of that feature is available online at
http://www.courier-mta.org/couriertcpd.html#idp5867072
In prior releases, only the -block option was present, and the
Authentication-Results header field was handled by add-ons, not by
the core implementation. The -allow option was added so that black
and white lists can be configured using mostly symmetrical syntax.
Finally, an option was added to inhibit SPF reject-on-fail for
whitelisted senders.
It is not possible to know how many installations of Courier-MTA have
enabled these new features. However, no questions have been asked
about them on the mailing list, yet. Despite the amount of spam,
there seems to be little traction for this kind of development.
The only DNSWL known to have been used for this purpose is dnswl.org.
See http://www.dnswl.org/. With nearly 150K entries, it can make the
email messages that get at least one authentication "pass" overreach
a critical mass: It seems that subscribing to that list is easier,
for some mail admins, than implementing other authentication methods.
Vesely Expires January 16, 2014 [Page 5]
Internet-Draft DNSWL email-auth-method extension July 2013
5. Security Considerations
All of the considerations described in Section 8 of
[I-D.ietf-appsawg-rfc5451bis] apply.
In addition, the usual caveats apply about importing text from
external online sources. Although queried DNSWLs are well known,
trusted entities, it is suggested that TXT records be reported only
if, upon inspection, their content is deemed actually actionable. If
they contain non-ASCII characters, they need to be encoded as
appropriate.
6. References
6.1. Normative References
[I-D.ietf-appsawg-rfc5451bis]
Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status",
draft-ietf-appsawg-rfc5451bis-10 (work in progress),
July 2013.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
6.2. Informative References
[I-D.sheffer-running-code]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: the Implementation Status Section",
draft-sheffer-running-code-06 (work in progress),
June 2013.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.
[RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
Reference", RFC 5518, April 2009.
[RFC5782] Levine, J., "DNS Blacklists and Whitelists", RFC 5782,
February 2010.
[RFC6650] Falk, J. and M. Kucherawy, "Creation and Use of Email
Feedback Reports: An Applicability Statement for the Abuse
Reporting Format (ARF)", RFC 6650, June 2012.
Vesely Expires January 16, 2014 [Page 6]
Internet-Draft DNSWL email-auth-method extension July 2013
Authentication-Results: mta.example.com;
dnswl=pass dns.zone=list.dnswl.example
policy.ip=127.0.10.1
policy.txt="example.org http://dnswl.example/s?s=100"
Author's Address
Alessandro Vesely
v. L. Anelli 13
Milano, MI 20122
IT
Email: vesely@tana.it
Vesely Expires January 16, 2014 [Page 7]