Sender Policy Framework: Email Address Internationalization
draft-ellermann-spf-eai-00

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 September 18, 2008.

Abstract

UTF8SMTP is an extension of SMTP (Simple Mail Transfer Protocol) allowing the use of UTF-8 in the SMTP envelope for EAI (Email Address Internationalization) and other purposes. This memo discusses some consequences for SPF (Sender Policy Framework).

Editorial note

This note, the IANA considerations (IANA Considerations), and the document history (Document History) should be removed before publication.

Table of Contents

1.  Introduction
2.  Background
    2.1.  SPF HELO identity
    2.2.  EAI MAIL FROM identity
    2.3.  local parts
3.  Considerations for policy publishers
4.  Acknowledgements
5.  Security Considerations
6.  IANA Considerations
7.  References
    7.1.  Normative References
    7.2.  Informative References
Appendix A.  Document History
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

The keywords "MUST NOT" and "SHOULD" in this memo are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.). UTF-8 is specified in [RFC3629] (Yergeau, F., “UTF-8, a transformation format of ISO 10646,” November 2003.).

Readers should be familiar with SMTP as specified in [I‑D.klensin‑rfc2821bis] (Klensin, J., “Simple Mail Transfer Protocol,” July 2008.) and the SPF terminology in [RFC4408] (Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” April 2006.). An MTA is a Mail Transfer Agent, e.g., an SMTP relay.

Comments and questions can be sent to the SPF-Discuss mailing list http://dir.gmane.org/gmane.mail.spam.spf.discuss.

2.  Background

SMTP as specified in [I‑D.klensin‑rfc2821bis] (Klensin, J., “Simple Mail Transfer Protocol,” July 2008.) supports only ASCII addresses and LDH (letter, digit, hyphen) domain labels. The letters are ASCII letters, LDH-labels are also known as A-labels in the context of IDN (Internationalization of Domain Names).

2.1.  SPF HELO identity

In SMTP sessions after an SMTP EHLO command from the client the server response can indicate supported SMTP extensions. [I‑D.ietf‑eai‑smtpext] (Yao, J. and W. MAO, “SMTP extension for internationalized email address,” July 2008.) specifies the UTF8SMTP extension.

The SMTP client can accept an offered UTF8SMTP extension by using one of the specified features, notably by the use of UTF-8 in mailbox addresses of SMTP commands, by the use of alternative ASCII addresses in these commands, or by the use of UTF-8 in the message header for addresses and other purposes, i.e. by sending a "message/global" instead of a "message/rfc822".

Because UTF8SMTP support is indicated in the response to an EHLO command it cannot be used after HELO, and the SPF HELO identity is not affected by EAI: The domain in a HELO or EHLO command consists of ordinary LDH-labels (A-labels), or it is a domain literal. For an empty reverse path, as it is used in non-delivery reports and other auto-replies, SPF fabricates a MAIL FROM identity based on the HELO identity with a case insensitive local part "postmaster", this scenario is also not affected by EAI.

A domain consisting of LDH-labels including IDN A-labels beginning with "xn--" is an ordinary LDH-domain as far as DNS (Domain Name System), SPF, and UTF8SMTP are concerned. Apart from HELO and EHLO the only relevant SMTP command for SPF is the MAIL FROM command with the reverse path containing the envelope sender address (if it is not empty, see above). Where the derived MAIL FROM identity is an ordinary address SPF can handle it as specified in [RFC4408] (Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” April 2006.).

2.2.  EAI MAIL FROM identity

The interesting UTF8SMTP cases for SPF contain non-ASCII UTF-8 characters in the local part (left hand side) or the domain part (right hand side) of the MAIL FROM identity. Domain labels containing non-ASCII UTF-8 characters are also known as U-labels in IDN.

SPF checks typically make only sense at the border MTA, and ignoring the address fallback in SMTP for the moment this is an MX (Mail eXchanger) of the receiver talking with a sender. An MTA wishing to check the SPF sender policy against the IP of the sender fetches the sender policy for the domain of the HELO or MAIL FROM identity as DNS client of a server for the alleged server. The SPF terminology might be confusing, the MX is the SMTP server, but for the purpose of checking a sender policy it is the SPF (or rather DNS) client of an alleged sender with a known HELO or MAIL FROM identity.

Skipping all ordinary cases as noted above the SPF client confronted with an EAI address in the MAIL FROM identity is typically the SMTP server supporting UTF8SMTP, and in that case it is supposed to know how to transform U-labels into corresponding A-labels, e.g., because it might need to send a non-delivey report to the envelope sender address later.

For agents trying post-SMTP SPF-checks this might be not the case, but arguably that is a broken setup, the border MTA should not offer and accept UTF8SMTP mails if critical parts behind it - not limited to the mailbox of the receiver - cannot handle it. Where this nevertheless happens software could try to use U-labels "as is" in DNS queries, this is a general EAI issue. SPF clients return NONE for domain literals, a domain literal has no sender policy, they also return NONE for invalid, malformed, or non-existent domains as specified in [RFC4408] (Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” April 2006.). This includes U-labels in MAIL FROM identities for SPF clients not supporting UTF8SMTP.

An MTA could "downgrade" EAI MAIL FROM addresses using an optional alternative address given as UTF8SMTP Mail-parameter. Where that happens the resulting new MAIL FROM address is an ordinary [I‑D.klensin‑rfc2821bis] (Klensin, J., “Simple Mail Transfer Protocol,” July 2008.) reverse path and can be handled as usual.

2.3.  local parts

Top down at this point the remaining SPF clients are supposed to know how to transform U-labels into A-labels, and fetch the SPF policy of the alleged sender. SPF implementors and publishers of SPF sender policies should note that only the domain part of the MAIL FROM identity is transformed from U-labels into A-labels. The local part MUST NOT be transformed, it is used "as is" in the construction of a <target-name> by SPF macro expansion involving local part macros.

Please note that [RFC4408] (Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” April 2006.) allows all octets in labels of a <target-name> excluding dots, which are supposed to separate labels. Leading, trailing, or adjacent dots in a <target-name> are expected to cause a PERMERROR, or to explore dark corners of SPF implementations. This is no DNS issue, in theory all octets can be used in a label, it is a limitation caused by baroque SPF features, and this memo is not the place to specify the handling of labels with embedded dots.

[I‑D.klensin‑rfc2821bis] (Klensin, J., “Simple Mail Transfer Protocol,” July 2008.) recommends to avoid quoted strings in local parts of addresses, and a quoted string containing leading, trailing, or adjacent dots in conjunction with rarely used local part macros is the only way to arrive at a problematic <target-name>.

Other octets found in an UTF-8 local part of EAI addresses are no problem for SPF, but note that DNS compares ASCII letters case-insensitively. Domains supporting case-sensitive ASCII characters in local parts cannot expect to use the SPF local part macro feature. Non-ASCII UTF-8 octets are not affected by this DNS limitation.

3.  Considerations for policy publishers

Policy publishers should know that this memo does not update [RFC4408] (Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” April 2006.), in theory EAI is compatible with SPF. It is not possible to use U-labels in sender policies directly, they have to be transformed into the corresponding A-labels. Likewise U-labels in UTF8SMTP MAIL FROM addresses are transformed into A-labels for the purposes of SPF by implementations supporting EAI.

SPF implementations not supporting U-labels in MAIL FROM identities will return NONE instead of the intended result, e.g., PASS or FAIL. UTF8SMTP senders wishing to avoid this problem could transform MAIL FROM U-labels into A-labels on their side. They can also hope that spammers forging MAIL FROM identities will not abuse IDN U-labels in the near future, and that most SPF implementations will be updated before this changes. Unfortunately experience has shown that spammers learn faster than lazy users.

MAIL FROM identities using only A-labels, with or without UTF-8 in the local part, work "as is" for the purposes of SPF. HELO identities consist either of A-labels, are domain literals and irrelevant for SPF, or are syntactically malformed as far as UTF8SMTP and SPF are concerned. SPF does not specify how receivers should handle SMTP HELO syntax errors.

UTF8SMTP allows to specify an optional alternative address in the traditional syntax. Receivers are free to check SPF also or only based on the alternative address. Obviously a sender policy for the alternative address should permit the same sending IPs as the sender policy for the EAI address, and one simple way to achieve this is to use corresponding A-labels in an alternative address yielding one SPF sender policy for both addresses. Please note that this is not required by UTF8SMTP, it permits to use unrelated domains with different policies. Clearly if some IPs permitted for one address fail for the other address, or vice versa, the sender will have problems, if the affected IPs are actually used to send mails.

This memo does not discuss EAI considerations for PRA (Purported Responsible Address) policies specified in [RFC4406] (Lyon, J. and M. Wong, “Sender ID: Authenticating E-Mail,” April 2006.), the PRA is determined by addresses in the message header and not necessarily related to the MAIL FROM identity used by SPF based on UTF8SMTP MAIL FROM or EHLO commands. Publishers of sender policies should know that "spf2.0/pra" introduces a PRA policy. In theory policy records starting with "spf2.0/pra,mfrom" or "spf2.0/mfrom,pra" can be checked using the PRA algorithm or the SPF algorithm, while policy records starting with "spf2.0/mfrom" have to be checked using the SPF algorithm.

In practice all SPF implementations support SPF policies introduced by "v=spf1" as specified in [RFC4408] (Wong, M. and W. Schlitt, “Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1,” April 2006.). The "spf2.0/mfrom" variations can be considered as obsolete, "spf2.0/mfrom" is an alias for "v=spf1". If users wish to publish policies for both PRA and SPF they SHOULD use separate "spf2.0/pra" and "v=spf1" policy records, even if those policy records are otherwise syntactically identical. In any case there are significant semantical differences between SPF and PRA.

4.  Acknowledgements

Various IETF tools by Henrik Levkowetz, Bill Fenner, and others were a great help in the creation of this memo.

5.  Security Considerations

When UTF8SMTP senders use a different domain in the optional alternative MAIL FROM address, and the corresponding sender policy is also different, it is hard to predict which policy will be checked, if any, depending on the route to the receiver and other factors. Different results can be hard to diagnose, e.g., if a mail from the same sender to the same receiver sometimes results in PASS and at other times in FAIL. Various proposals to mitigate this problem are discussed in Section 3 (Considerations for policy publishers)

Using the SPF local part macro in conjunction with EAI is not intuitive, local parts are not transformed to A-labels. This is no new problem, but in conjunction with EAI it is more likely, the details are explained in Section 3 (Considerations for policy publishers).

Unsurprisingly evaluating PRA policies with SPF or vice versa can cause havoc, as the algorithms are semantically different even when the policies are otherwise syntactically identical. This memo deprecates three of five sender policy variants in Section 3 (Considerations for policy publishers) to reduce the confusion.

Not all SPF implementations will already support U-labels as specified in this memo. Senders could transform U-labels in MAIL FROM commands to A-labels on their side where this is a problem.

UTF8SMTP servers can be forced to send non-delivery reports to forged envelope sender addresses, if some receiver mailboxes can handle EAI mails, while others can't, and the server has no way to "downgrade" mails to traditional receivers. Hopefully a future SMTP extension will allow a kind of "selective reject" mechanism. Publishing SPF PASS or FAIL policies, and rejecting FAIL at the border MTA can eliminate this problem. Similarly non-delivery reports after a PASS cannot hit innocent bystanders.

6.  IANA Considerations

Keep up the good work, nothing to do here.

7.  References

7.1. Normative References

7.2. Informative References

Appendix A.  Document History

Initial version

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

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.

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, THE IETF TRUST 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.

Intellectual Property

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.

Acknowledgment

This document was produced using xml2rfc v1.35 (of http://xml.resource.org/) from a source in RFC-2629 XML format.