Internet DRAFT - draft-macquigg-authent-declare
draft-macquigg-authent-declare
Internet Draft D. MacQuigg
Document: draft-macquigg-authent-declare-00
Expires: November 2005 25 May 2005
Email Sender's Declaration of Identity
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/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright (C) The Internet Society (2005)
Abstract
A key item that must be standardized to allow interoperation of
different email authentication methods is the ID declaration.
Current authentication methods assume that one or another of the
existing fields in a mail transfer can be used as the Identity to be
verified. Since there is no way to tell which field, if any, the
sender is prepared to authenticate, extra DNS queries must be made,
in the worst-case, testing all possibilities just to find no
authentication is offered at all. This draft proposes a neutral
syntax that can be used by all methods.
MacQuigg Expires - November 2005 [Page 1]
Conventions used in this document
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 [RFC-2119].
Table of Contents
1. The Need for an Email Identity Declaration.....................3
2. A Possible Compromise..........................................3
3. Levels of Compliance...........................................5
4. Relations with Existing and Proposed Standards or Practice.....5
5. Example Using the ID...........................................6
6. Formal Syntax..................................................7
Security Considerations...........................................7
IANA Considerations...............................................7
Normative References..............................................8
Informative References............................................8
Author's Addresses................................................8
Legal Statements..................................................8
Acknowledgments...................................................9
Changes
5/16 SMTP Service Extension - Added statement in section 4 and
example in IANA Considerations section.
5/18 Clarifying the relationship between the declared ID and the
IDs assumed by various methods - section 4.
5/18 Added example to clarify how a standard ID declaration avoids
DNS "hunting" - New section 5.
5/22 Added SRS example at end of section 4 and explanations as to
why neither SUBMITTER nor SRS are suitable as a universal ID.
5/22 Added paragraphs to section 1, clarifying the need for a
standard.
5/22 Added paragraph to section 2 stating the semantics of the new
ID name.
5/23 Moved fundamental requirements from section 4 to section 2.
5/24 Added ABNF syntax in section 6.
5/24 Updated IANA Considerations.
5/25 Clarify limitations of alternative IDs (SUBMITTER and SRS).
The current working copy of this draft and a summary of mailing-list
discussions can be found at http://purl.net/macquigg/email
MacQuigg Expires - November 2005 [Page 2]
Email Sender's Declaration of Identity May 2005
1. The Need for an Email Identity Declaration
A fundamental requirement for all email authentication methods is
that the sender must declare, or at least reveal, its Identity to the
receiver. Unfortunately, there is no agreement on how this should be
done. Some believe firmly that it should be done in the EHLO command
at the start of each session, others insist that it should be done in
the MAIL FROM command with each email. Still others think the true
Identity should be extracted from one or another of the email headers
that the recipient actually sees. Adding to the confusion is the
fact that each of these identities may legitimately differ from the
Identity that is to be authenticated, and may differ in having extra
"subdomain" labels that are not easily separated from the Identity to
be checked.
The fundamental problem with the use of existing identities is that
none of them were intended for the purpose of email authentication.
Changing current standards and practice is difficult. Adding new
syntax, as done by [SUBMITTER] and [SRS] avoids this problem, but
each of these proposals addresses only the needs of one method. We
need a standard that will work with all methods.
Each of the methods is now going its own way, with no thought as to
how one will communicate with another as an email is forwarded across
the Internet. A receiver must try all possible methods, by "hunting"
for DNS records at various locations. The most costly DNS hunts will
be for the typical randomly-generated spammer name that offers no
authentication.
We need a clear and simple standard that will allow any receiver to
know exactly what Identity is authorizing a transfer, regardless of
which authentication method is used, and to treat with suspicion any
sender that does not offer a reputable ID.
We need a clear and simple standard that will allow any sender to
declare, regardless of what other identities may be found in an
email, "I am <ID>, and I take responsibility for this transfer." We
need to change the culture of irresponsibility in the current
operations of Public Mail Servers. An email ID should become the
equivalent of a "broadcast license", and owners of those IDs should
not tolerate their abuse. Standardizing an ID declaration will help
achieve this change.
2. A Possible Compromise
The proposed ID Declaration syntax is designed to fit in with a
future Inter-Operability Protocol for all methods. See [draft-
macquigg-authent-IOP] for one such protocol. The relevant
fundamental requirements from that protocol are:
MacQuigg Expires - November 2005 [Page 3]
Email Sender's Declaration of Identity May 2005
1) This protocol must not favor any one authentication method over
another. It must allow an arbitrary number of Forwarders using
different methods to work together in the same authenticated
transfer.
2) Each Sending Mail Transfer Agent (MTA) in an IP-authenticated
transfer must declare, in the SMTP session, the Identity responsible
for the transfer.
One way to standardize the Identity declaration is to use a new
field, independent of existing fields, and not constrained by any
pre-existing semantics.
EHLO mailserver7.bigforwarder.com
ID bigforwarder.com
MAIL FROM:<bob@sales.some-company.com>
The ID command provides a domain name independent of other names in
the envelope and headers. It should be a short, memorable name to
enhance its value as a Public Mail Server identity. There are three
semantics associated with this new name.
1) It may be used for accreditation and reputation.
2) It may be used to specify the location for authentication records.
3) It may be used, after authentication, as a bounce address for
complaints and challenges relating to spam.
One advantage of this syntax is that the sender's ID is explicitly
declared, not just assumed from existing information. Not only will
this remove the current uncertainty as to which ID the sender intends
to use, but false information here is evidence of a serious problem,
not just a forgivable error in passing on existing information (a
long-standing problem with email). This will greatly reduce the
administrative burden in deciding whether to trust a sender. It will
also allow an immediate reject when a declared ID has no
authentication record.
Another advantage is that there is no "hunting" for DNS records at
various locations and multiple levels of a deep subdomain tree. The
ID should provide the exact location where at least the first
authentication record will be found. The first record should specify
what methods are used, and thereby avoid the hunt. See the example in
section 5.
Most reputable Public Mail Servers will chose their top domain name
as their ID, but it can be any name under DNS control. This could be
a domain set up specifically to authorize mail servers, or it could
be some other organization's ID. The latter should be allowed but
MacQuigg Expires - November 2005 [Page 4]
Email Sender's Declaration of Identity May 2005
discouraged, since any miscommunication over the use of someone
else's ID could result in authentication failures, suspicion of
forgery, and loss of reputation by the owner of the ID.
Although the ID command may be repeated, to provide a different ID
with every message, senders should organize their messages so that
only one ID command is issued for many subsequent MAIL commands.
This will minimize the number of DNS queries made by the receiving
MTA.
Senders with a large organization, and a desire to decentralize their
mail system management, should still consider putting their
authorization records under their topmost domain name. Consolidating
the records for ten busy subdomains should reduce DNS queries by a
factor of ten.
3. Levels of Compliance
During the early days of email authentication, it may be useful to
rate Public Mail Servers as to their level of compliance with
authentication standards. This will encourage all servers to provide
at least minimum security, and allow mail receivers to put special
trust in servers that provide the highest levels. One possible
scheme having three levels is described in [draft-macquigg-authent-
IOP]. The proposed ID syntax will satisfy level one, and this is all
that is needed for domains that do not forward emails from other
domains.
Level 1) Servers that will declare their ID, and provide a DNS
record for that ID to authorize that server.
4. Relations with Existing and Proposed Standards or Practice
The proposed syntax will require an SMTP service extension for a new
ID command. See section 7, IANA Considerations and [RFC-2821].
MTA software will need to be enhanced and deployed at sites that
provide email authentication. To minimize upgrade efforts these
changes should be bundled with the upgrade to enable authentication.
Each authentication method should consider what it will do if the
declared ID differs from the default ID that is used by their method.
The options are:
a) Ignore the default. The ID declaration over-rides.
b) Ignore the declared ID except to find the initial DNS record and
determine what methods are available. Then use the default ID, start
with a fresh query for DNS records at that ID.
c) Do a cross-check, then proceed with the desired ID. e.g. The
default ID must be a subdomain of the declared ID.
MacQuigg Expires - November 2005 [Page 5]
Email Sender's Declaration of Identity May 2005
The proper procedure depends on what the requirements of the
particular method are. If they are simply to verify that the ID
authorizes the transfer, option 'a' will be the quickest. If
additional requirements are important, options 'b' or 'c' may be
necessary. Additional requirements may include such things as
matching between header fields and the authorizing Identity, or
existence of a particular DNS record structure for the sending MTA.
The problem of introducing a new identity into the SMTP session has
been addressed before. See [SUBMITTER] for one alternative.
MAIL FROM:<bob@sales.some-company.com> SUBMITTER=bigforwarder.com
The proposed SUBMITTER parameter for the MAIL FROM command is
intended to provide header information (the "PRA" address) in the
SMTP commands. The limitation to PRA makes it inapplicable as a
universal ID declaration.
See [SRS] for another alternative. The MAIL FROM command is
rewritten so that it contains both the original return path before
any forwarding and a new return path for the current hop.
MAIL FROM:<bob#sales.some-company.com@bounce.bigforwarder.com>
The limitation to defining a new return path makes SRS inapplicable
as a universal ID declaration.
5. Example Using the ID
Here is a typical SMTP session using the ID command. C is the client
(sender). S is the server (receiver).
C: EHLO mailserver7.bigforwarder.com
S: 250-host.com, welcome
S: 250-SIZE ETRN
S: 250-AUTH LOGIN ID
S: 250 HELP
C: ID bigforwarder.com
S: 250 ... Sender validation pending. Continue.
C: MAIL FROM:<bob@sales.some-company.com>
S: 250 Ok
Without the ID command, you will waste a bunch of DNS queries and
possibly conclude this sender offers no authentication. For each
possible Identity (mailserver7.bigforwarder.com, bigforwarder.com,
sales.some-company.com, some-company.com) you need to search every
possible location for DNS records (<Identity>,
_client._smtp.<Identity>, ...), and we still haven't searched all the
MacQuigg Expires - November 2005 [Page 6]
Email Sender's Declaration of Identity May 2005
header identities. This is what we mean by DNS "hunting" - searching
for records that may not exist.
With the ID command, the receiving MTA does a DNS query for a TXT
record at a standard location, like _AUTH.bigforwarder.com.mail.net
The query returns a record that specifies exactly what methods are
supported by the owner of the Identity. If the method parameters all
fit in the first record, no further queries are necessary. If the
parameters don't all fit, you will at least know exactly where to
look for the rest.
6. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in [RFC-2234].
The ID command can occur any time in an SMTP session except during
data transfer. The specified Identity remains in effect until the
end of the session, or another ID command. Clients MUST NOT send an
ID command unless that keyword is offered in the server's EHLO
response.
ID-command = "ID" 1*SP Domain 1*SP options CRLF
Domain = (sub-domain 1*("." sub-domain))
sub-domain = Let-dig [Ldh-str]
Let-dig = ALPHA / DIGIT
Ldh-str = *( ALPHA / DIGIT / "-" ) Let-dig
options = 1*(%d0-9 / %d11-12 / %d14-127)
; string of any characters other than CR or LF
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SP = %x20 ; space
CRLF = CR LF
CR = %x0D ; carriage return
LF = %x0A ; linefeed
The domain name used as an Identity, has the same syntax as the
domain name in the EHLO command. Options are not defined, but are
included here to allow future extensions to the ID command.
Security Considerations
ID strings are easily faked, the same as any other envelope or header
parameters. Security depends entirely on the authentication method.
Until the ID is authenticated, it should not be trusted.
IANA Considerations
MacQuigg Expires - November 2005 [Page 7]
Email Sender's Declaration of Identity May 2005
The proposed syntax will require an SMTP service extension with the
following addition to the Mail Parameters Registry.
Keywords Description Reference
------------------- --------------------------- ---------
ID Sender's Declared Identity [RFC....]
There are no additional parameters needing registration.
Normative References
[RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
[RFC-2234], Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997
[RFC-2821], Klensin, J., "Simple Mail Transfer Protocol", April 2001
Informative References
[draft-macquigg-authent-IOP], MacQuigg, D., "Email Authentication
Inter-Operability Protocol", (work in progress) May 2005,
http://purl.net/net/macquigg/email
[SRS] draft-mengwong-sender-rewrite-01, Wong, M.,"Sender Rewriting
Scheme", (expired) http://www.libsrs2.org/
[SUBMITTER] draft-katz-submitter-01, Allman, E., and Katz, H., "SMTP
Service Extension for Indicating the Responsible Submitter of an E-
mail Message", (work in progress) May 2005
Author's Addresses
David R. MacQuigg, PhD
9320 East Mikelyn Lane
Tucson Arizona 85710 USA
Phone: 520-721-4583
Email: david_macquigg a-t yahoo.com
URL: http://purl.net/macquigg/
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
MacQuigg Expires - November 2005 [Page 8]
Email Sender's Declaration of Identity May 2005
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 (C) The Internet Society (2005)
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.
Acknowledgments
The author thanks all those who participated in discussions with him
on the ietf and spf mailing lists.
Funding for the RFC Editor function is currently provided by the
Internet Society.
MacQuigg Expires - November 2005 [Page 9]
