Alexey Melnikov wrote:
Do people think that would go in the header field draft, or should it
be on its own?
IMHO, either way is fine.
OK, so here's where we are then. Attached are two things:
a) diffs from the currently published form of the draft, taking into
account the discussion thus far, and
b) a supplementary draft that creates trivial SMTP, IMAP and POP3
extensions to cover the optional discovery features Lisa, Tony and
Alexey are proposing.
Comments, please. And thanks for the contributions, folks. Have a good
weekend.
-MSK
@@ -286,8 +286,24 @@
See [I-D.DRAFT-CROCKER-EMAIL-ARCH] for further discussion on e-mail
system architecture.
+1.4. Trust Environment
+ This new header field permits one or more message validation
+ mechanisms to communicate its output to one or more separate
+ assessment mechanisms. These mechanisms operate within a unified
+ trust boundary that defines an Administrative Management Domain
+ (ADMD). An ADMD contains one or more entities that perform
+ validation and generate the header field, and one or more that
+ consume it for some type of assessment. The field contains no
+ integrity or validation mechanism of its own, so its presence must be
+ trusted implicitly. Hence, use of the header field depends upon
+ ensuring that mail entering the ADMD has instances of the header
+ field claiming to be valid within this domain removed, so that
+ occurrences of such header fields can be trusted by consumers.
+ The "authserv-id" token defined in Section 2.2 can be used to label
+ an entire ADMD or a specific validation engine within an ADMD. The
+ labeling scheme is left as an operational choice.
@@ -518,7 +518,7 @@
The authentication identifier field provides a unique identifier that
refers to the authenticating service within a given mail
- administrative domain. The uniqueness of the identifier is
+ administrative domain. The uniqueness of the identifier MUST be
guaranteed by the mail administrative domain that generates it and
must pertain to exactly that one mail administrative domain. This
identifier is intended to be machine-readable and not necessarily
@@ -758,7 +758,7 @@
2.4.6. Extension Result Codes
- Additional result codes (extension results) may be defined in the
+ Additional result codes (extension results) might be defined in the
future by later revisions or extensions to this specification.
Extension results beginning with "x-" will never be defined as
standard fields; such names are reserved for experimental use.
@@ -983,6 +983,14 @@
authentication schemes were applied prior to delivery of this
message.
+ An MTA adding this header field must take steps to identify it as
+ legitimate to the MUAs that will ultimately consume its content. One
+ required process to do so is described in Section 5. Further
+ measures may be required in some environments. Some possible
+ solutions are enumerated in Section 8.1. This memo does not mandate
+ any specific solution to this issue as each environment has its own
+ facilities and limitations.
+
4.1. Header Position and Interpretation
In order to ensure non-ambiguous results and avoid the impact of
@@ -1408,15 +1464,15 @@
8.1. Forged Headers
- An MUA that accesses a mailbox whose mail is handled by a non-
- conformant MTA, and understands Authentication-Results header fields,
- could potentially make false conclusions based on forged header
- fields. A malicious user or agent could forge a header field using
- the destination MX for a receiving domain as the hostname token in
- the value of the header, and with the rest of the value claim that
- the message was properly authenticated. The non-conformant MTA would
- fail to strip the forged header field, and the MUA could
- inappropriately trust it.
+ An MUA or filter that accesses a mailbox whose mail is handled by a
+ non-conformant MTA, and understands Authentication-Results header
+ fields, could potentially make false conclusions based on forged
+ header fields. A malicious user or agent could forge a header field
+ using the destination MX for a receiving domain as the authserv-id
+ token in the value of the header field, and with the rest of the
+ value claim that the message was properly authenticated. The non-
+ conformant MTA would fail to strip the forged header field, and the
+ MUA could inappropriately trust it.
It is for this reason an MUA should not have processing of the
"Authentication-Results" header field enabled by default; instead it
@@ -1427,15 +1483,52 @@
of hostnames whose "Authentication-Results" header fields are
trustworthy; however, this list should initially be empty.
- Proposed alternate solutions to this problem are nascent. Possibly
- the simplest is a digital signature on the header field that can be
- verified by a posted public key. Another would be a means to
- interrogate the MTA that added the header field to see if it is
- actually providing any message authentication services and saw the
- message in question, but this isn't especially palatable. In either
- case, a mechanism needs to exist to verify that the host that appears
- to have added the header field (a) actually did so, and (b) is
- legitimately adding that header field for this delivery.
+ Proposed alternate solutions to this problem are nascent:
+
+ 1. Possibly the simplest is a digital signature protecting the
+ header field, such as using [DKIM], that can be verified by an
+ MUA using by a posted public key. Although one of the main
+ purposes of this memo is to relieve the burden of doing message
+ authentication work at the MUA, this only requires that the MUA
+ learn a single authentication scheme even if a number of them are
+ in use at the border MTA.
+
+ 2. Another would be a means to interrogate the MTA that added the
+ header field to see if it is actually providing any message
+ authentication services and saw the message in question, but this
+ isn't especially palatable given the work required to craft and
+ implement such a scheme.
+
+ 3. Yet another might be a method to interrogate the internal MTAs
+ which apparently handled the message (based on Received: header
+ fields) to determine whether any of them conform to Section 5 of
+ this memo. This, too, has potentially high barriers-to-entry.
+
+
+
+
+
+Kucherawy Expires April 13, 2009 [Page 27]
+
+Internet-Draft Authentication-Results Header October 2008
+
+
+ 4. On the presumption that internal MTAs are fully compilant with
+ [MAIL], and the compliant internal MTAs are using their own
+ hostnames as the "authserv-id" token, the header field proposed
+ here will always appear adjacent to a Received: header bearing
+ the same name. This can be used as a test for header field
+ validity.
+
+ Support for some of these can be found in
+ [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-CAPS].
+
+ In any case, a mechanism needs to exist for an MUA or filter to
+ verify that the host that appears to have added the header field (a)
+ actually did so, and (b) is legitimately adding that header field for
+ this delivery. Given the variety of messaging environments deployed
+ today, consensus appears to be that specifying a particular mechanism
+ for doing so is not appropriate for this memo.
8.2. Misleading Results
@@ -1585,8 +1697,8 @@
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
- [MAIL] Resnick, P., "Internet Message Format", RFC 2822,
- April 2001.
+ [MAIL] Resnick, P., "Internet Message Format", RFC 5322,
+ October 2008.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
@@ -1620,19 +1732,23 @@
-Kucherawy Expires March 5, 2009 [Page 29]
+Kucherawy Expires April 13, 2009 [Page 31]
-Internet-Draft Authentication-Results Header September 2008
+Internet-Draft Authentication-Results Header October 2008
[I-D.DRAFT-IETF-DKIM-SSP]
Allman, E., Delany, M., and J. Fenton, "DKIM Author
Signing Practices", I-D draft-ietf-dkim-ssp, January 2008.
+ [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-CAPS]
+ Kucherawy, M., "Indicating Message Authentication Status
+ Capabilities", I-D draft-kucherawy-sender-auth-caps,
+ October 2008.
+
[IANA-CONSIDERATIONS]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
- IANA Considerations Section in RFCs", RFC 5226,
- October 1998.
+ IANA Considerations Section in RFCs", RFC 5226, May 2008.
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003.
@@ -1641,8 +1757,8 @@
Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006.
- [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
- April 2001.
+ [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
+ October 2008.
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
Individual submission M. Kucherawy
Internet-Draft Sendmail, Inc.
Intended status: Experimental October 10, 2008
Expires: April 13, 2009
Indicating Message Authentication Status Capabilities
draft-kucherawy-sender-auth-caps-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 April 13, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Kucherawy Expires April 13, 2009 [Page 1]
Internet-Draft Authentication-Results Capabilities October 2008
Abstract
This memo defines simple extensions to IMAP, POP3 and SMTP to permit
a user's message reading agent (Mail User Agent, or MUA) to determine
the properties of its environment with respect to available message
authentication services.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SMTP AUTHSERV Extension . . . . . . . . . . . . . . . . . . . 6
3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Framework for the AUTHSERV SMTP Extension . . . . . . . . 6
3.3. Details . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. IMAP AUTHSERV Capability . . . . . . . . . . . . . . . . . . . 8
5. POP3 AUTHSERV Capability . . . . . . . . . . . . . . . . . . . 9
6. Conformance and Usage Requirements . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. SMTP Extension Registration . . . . . . . . . . . . . . . 11
7.2. IMAP Extension Registration . . . . . . . . . . . . . . . 11
7.3. POP3 Extension Registration . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 15
B.1. Example use of SMTP extension . . . . . . . . . . . . . . 15
B.2. Example use of IMAP extension . . . . . . . . . . . . . . 16
B.3. Example use of POP3 extension . . . . . . . . . . . . . . 17
Appendix C. Public Discussion . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
Kucherawy Expires April 13, 2009 [Page 2]
Internet-Draft Authentication-Results Capabilities October 2008
1. Introduction
The message header field defined in
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER] can be used to relay to MUAs
or other internal filtering agents the results of message
authentication efforts performed by upstream Mail Transport Agents
(MTAs). As messaging is generally not secure by default, there exist
some vectors for allowing forgeries of that header field through to
user agents which might then take inappropriate action. (See the
Security Considerations section of that memo for details.)
Part of the work required to secure those vectors involves securing
the channel between MTAs and user agents such that the contents of
the header field can be trusted. There are two important facilities
needed toward this end:
1. An [SMTP] extension: User agents can contact upstream MTAs within
their administrative domains to see if those MTAs are conforming
to the security requirements of
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER].
2. [IMAP] and/or [POP3] extensions: User agents can contact their
message store servers to determine what token(s) authorized MTAs
use when generating the authentication results header fields,
which also implicitly notifies the MUA that the administrative
domain conforms to the security requirements of
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER].
Kucherawy Expires April 13, 2009 [Page 3]
Internet-Draft Authentication-Results Capabilities October 2008
2. Definitions
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.
An "MTA" is a Mail Transfer Agent, or any agent which uses [SMTP] or
its extensions to format and transport a message.
An "MDA" is a Mail Delivery Agent (also sometimes referred to as
"LDA" or Local Delivery Agent), or any agent which has access to
receive a message from an MTA and write it into the receiving user's
"inbox".
An "MUA" is a Mail User Agent, or any software which retrieves and
displays messages on behalf of a user. It may use [IMAP] or [POP3].
A "border MTA" is an MTA which acts as a gateway between the general
Internet and the users within an organizational boundary.
An "intermediate MTA" is an MTA which handles messages after a border
MTAs and before a delivery MTA.
+-----+ +-----+ +------------+
| MUA |-->| MSA |-->| Border MTA |
+-----+ +-----+ +------------+
|
|
V
+----------+
| Internet |
+----------+
|
|
V
+-----+ +-----+ +------------------+ +------------+
| MUA |<==| MDA |<==| Intermediate MTA |<==| Border MTA |
+-----+ +-----+ +------------------+ +------------+
Generally it is assumed that the work of applying message
authentication schemes takes place at a border MTA or a delivery MTA.
This specification is written with that assumption in mind. However,
there are some sites at which the entire mail infrastructure consists
of a single host. In such cases, such terms as "border MTA" and
"delivery MTA" may well apply to the same machine or even the very
same agent. It is also possible that message authentication could
take place on an intermediate MTA. Although this document doesn't
Kucherawy Expires April 13, 2009 [Page 4]
Internet-Draft Authentication-Results Capabilities October 2008
specifically include such cases, they are not meant to be excluded
from this specification.
See [I-D.DRAFT-CROCKER-EMAIL-ARCH] for further discussion on e-mail
system architecture.
In the figure shown above, the double-lines indicate the portions of
the transport of a message where this protocol would be applied.
Note also that the Local Mail Transfer Protocol [LMTP] could benefit
from a similar extension.
"authserv-id" is imported from
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER].
Kucherawy Expires April 13, 2009 [Page 5]
Internet-Draft Authentication-Results Capabilities October 2008
3. SMTP AUTHSERV Extension
3.1. Description
This section defines a new [SMTP] extension which enables user agents
and downstream filters to interrogate an MTA as to whether or not it
conforms to the security requirements of
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER]. In particular, it reveals
(a) that it conforms to that memo's requirements, and (b) what
"authserv-id" that MTA uses when adding Authentication-Results:
header fields to messages inbound.
3.2. Framework for the AUTHSERV SMTP Extension
Per the requirements of [SMTP], the framework for the AUTHSERV
Extension is as follows:
1. The name of the SMTP service extension is "Authserv-ID";
2. The SMTP buffer length is extended by 256 bytes on servers
offering this service extension;
3. The EHLO keyword value associated with the extension is AUTHSERV;
4. The parameter used with the AUTHRES EHLO keyword is an
"authserv-id" as defined above, and is optional;
5. No additional parameters are added to the MAIL command;
6. No additional parameters are added to the RCPT command;
7. No additional SMTP verbs are defined by this extension; and
8. The next subsection how support for the extension affects the
behaviour of a server and client SMTP session.
3.3. Details
If an MTA is compliant with that specification, it SHOULD use this
extension to advertise the "authserv-id" it uses when generating new
Authentication-Results: headers. An MUA can then use SMTP to query
the upstream MTA by issuing an EHLO command to determine whether or
not the MTA implements the specification in the header memo and also
what "authserv-id" it should expect. Once the presence or absence of
this information is determined by the MUA, it would simply issue a
QUIT command and disconnect.
The SMTP server MAY choose not to include the "authserv-id" token in
Kucherawy Expires April 13, 2009 [Page 6]
Internet-Draft Authentication-Results Capabilities October 2008
use if there is some practical reason to do so. In this case, the
server is simply announcing that it conforms to the remaining
security issues discussed in
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER].
This SMTP extension adds no new SMTP functionality per se. Rather,
it simply provides a means for an MUA attempting to implement
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER] to acquire important
security information about its environment.
Kucherawy Expires April 13, 2009 [Page 7]
Internet-Draft Authentication-Results Capabilities October 2008
4. IMAP AUTHSERV Capability
A new [IMAP] capability called AUTHSERV is defined.
Prior to authentication, it has no value associated with it. After
authentication, it always has a value associated with it, namely the
"authserv-id" string used within the administrative domain
represented by the IMAP server to declare validated authentication
results.
The advertisement of this capability to a client
1. should be considered by the client to be a statement that the
administrative domain is compliant with the security requirements
of [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER]; and
2. contains the "authserv-id" string which will be present on all
Authentication-Results: header fields which the client should
trust when determining courses of action based on the results of
prior message authentication efforts.
Kucherawy Expires April 13, 2009 [Page 8]
Internet-Draft Authentication-Results Capabilities October 2008
5. POP3 AUTHSERV Capability
The formal definition, per [POP3-CAPA]:
CAPA tag AUTHSERV
Arguments "authserv-id" string used within the administrative domain
Added commands none
Standard commands affected none
Announced states / possible differences both / yes (see above)
Commands valid in states n/a
Specification reference this document
Discussion A new [POP3] capability called AUTHSERV is defined. It
MUST have value associated with it in the TRANSACTION state,
namely the "authserv-id" string used within the administrative
domain represented by the POP3 server to declared validated
authentication results. It MUST NOT have a value in the
AUTHENTICATION state. The advertisement of this capability to a
client
1. should be considered by the client to be a statement that the
administrative domain is compliant with the security
requirements of [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER]; and
2. contains the "authserv-id" string which will be present on all
Authentication-Results: header fields which the client should
use when determining courses of action based on the results of
prior message authentication efforts.
Kucherawy Expires April 13, 2009 [Page 9]
Internet-Draft Authentication-Results Capabilities October 2008
6. Conformance and Usage Requirements
Section 3, Section 4 and Section 5 are each individual specifications
containing proposals supporting the goals specified in Section 1 and
in [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER]. Use of them in any
combination (other than "none") constitutes minimal conformance to
this specification and support of the header field memo.
Kucherawy Expires April 13, 2009 [Page 10]
Internet-Draft Authentication-Results Capabilities October 2008
7. IANA Considerations
This section discusses actions requested by IANA, per
[IANA-CONSIDERATIONS].
7.1. SMTP Extension Registration
IANA is requested to register the AUTHSERV extension to SMTP,
referencing this memo as its defining document.
7.2. IMAP Extension Registration
This document constitutes registration of the AUTHSERV IMAP
capability in the imap4-capabilities registry.
7.3. POP3 Extension Registration
This document constitutes registration of the AUTHSERV POP3
capability in the pop3-extension-mechanism registry.
Kucherawy Expires April 13, 2009 [Page 11]
Internet-Draft Authentication-Results Capabilities October 2008
8. Security Considerations
This memo serves to address some of the security considerations
within [I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER]. In particular, the
focus of this memo is to provide the means to determine automatically
whether the administrative domain in which an MUA finds itself is (or
claims to be) conformant with the security considerations of that
memo, and furthermore to acquire a key piece of information to be
used in carrying out the work described there. It is not an attempt
to resolve any of those considerations, other than simplifying to
some extent the work of configuring MUAs, thus leaving fewer places
for misconfigurations to occur and security problems to form.
Consult that document for further discussion of security issues.
Kucherawy Expires April 13, 2009 [Page 12]
Internet-Draft Authentication-Results Capabilities October 2008
9. References
9.1. Normative References
[IMAP] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 3501, March 2003.
[POP3-CAPA]
Gellens, R., Newman, C., and L. Lundblade, "POP3 Extension
Mechanism", RFC 2449, November 1998.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
9.2. Informative References
[I-D.DRAFT-CROCKER-EMAIL-ARCH]
Crocker, D., "Internet Mail Architecture",
I-D draft-crocker-email-arch, May 2007.
[I-D.DRAFT-KUCHERAWY-SENDER-AUTH-HEADER]
Kucherawy, M., "Message Header Field for Indicating
Message Authentication Status",
I-D draft-kucherawy-sender-auth-header-16, September 2008.
[IANA-CONSIDERATIONS]
Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", RFC 2434,
October 1998.
[LMTP] Meyers, J., "Local Mail Transport Protocol", RFC 2033,
October 1996.
[POP3] Meyers, J. and M. Rose, "Post Office Protocol - Version
3", RFC 1939, May 1996.
Kucherawy Expires April 13, 2009 [Page 13]
Internet-Draft Authentication-Results Capabilities October 2008
Appendix A. Acknowledgements
The author wishes to acknowledge the following for their review and
constructive criticism of this proposal: (add names here)
Kucherawy Expires April 13, 2009 [Page 14]
Internet-Draft Authentication-Results Capabilities October 2008
Appendix B. Examples
This section presents some examples of the use of these extensions.
In all cases, "C:" represents a transmission by the client and "S:"
represents a transmission by the server.
B.1. Example use of SMTP extension
An example use of the AUTHSERV SMTP extension:
C: (establishes connection to SMTP server)
S: 220 server.example.com ESMTP; Fri, 10 Oct 2008 13:52:37 -0700 (PDT)
C: EHLO myname.example.com
S: 250-ENHANCEDSTATUSCODES
S: 250-PIPELINING
S: 250-8BITMIME
S: 250-SIZE
S: 250-DSN
S: 250-DELIVERBY
S: 250-AUTHSERV=authserver.example.com
S: 250 HELP
C: QUIT
S: 221 server.example.com closing connection
S: (closes connection channel)
The client has connected to the SMTP server and issued the EHLO
command to determine whether or not the SMTP server claims to support
the requirements of the header memo. From this the client learns
that in fact it does conform, and furthermore knows what
"authserv-id" will be used by this MTA when communicating
authentication results.
Kucherawy Expires April 13, 2009 [Page 15]
Internet-Draft Authentication-Results Capabilities October 2008
B.2. Example use of IMAP extension
An example use of the AUTHSERV IMAP capability (server replies
wrapped here for legibility):
C: (establishes connection to IMAP server)
S: * OK IMAP server IMAP4rev1 ready
C: x CAPABILITY
S: * CAPABILITY CAPABILITY IMAP4 IMAP4rev1 UIDPLUS
AUTHSERV
S: x OK CAPABILITY COMPLETED
(authentication takes place)
C: x CAPABILITY
S: * CAPABILITY CAPABILITY IMAP4 IMAP4rev1 UIDPLUS
AUTHSERV=authserv.example.com
S: x OK CAPABILITY COMPLETED
(session continues)
The client connects and requests capabilities, immediately learning
that this administrative domain complies with the security
requirements of the header memo. After authentication, the client
issues a second request for capabilities at which point the local
"authserv-id" in use is revealed.
Kucherawy Expires April 13, 2009 [Page 16]
Internet-Draft Authentication-Results Capabilities October 2008
B.3. Example use of POP3 extension
An example use of the AUTHSERV POP3 capability (server replies
wrapped here for legibility):
C: (establishes connection to IMAP server)
S: +OK POP3 server ready
C: CAPA
S: +OK Capability list follows
S: TOP
S: USER
S: SASL CRAM-MD5
S: RESP-CODES
S: AUTHSERV
S: .
(authentication takes place)
C: CAPA
S: +OK Capability list follows
S: TOP
S: USER
S: SASL CRAM-MD5
S: RESP-CODES
S: AUTHSERV authserv.example.com
S: .
(session continues)
The client connects and requests capabilities, immediately learning
that this administrative domain complies with the security
requirements of the header memo. After authentication, the client
issues a second request for capabilities at which point the local
"authserv-id" in use is revealed.
Kucherawy Expires April 13, 2009 [Page 17]
Internet-Draft Authentication-Results Capabilities October 2008
Appendix C. Public Discussion
[REMOVE BEFORE PUBLICATION]
Public discussion of this proposed specification is handled via the
mail-vet-discuss(_at_)mipassoc(_dot_)org mailing list. The list is open.
Access to subscription forms and to list archives can be found at
http://mipassoc.org/mailman/listinfo/mail-vet-discuss.
Kucherawy Expires April 13, 2009 [Page 18]
Internet-Draft Authentication-Results Capabilities October 2008
Author's Address
Murray S. Kucherawy
Sendmail, Inc.
6475 Christie Ave., Suite 350
Emeryville, CA 94608
US
Phone: +1 510 594 5400
Email: msk+ietf(_at_)sendmail(_dot_)com
Kucherawy Expires April 13, 2009 [Page 19]
Internet-Draft Authentication-Results Capabilities October 2008
Full Copyright Statement
Copyright (C) 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(_at_)ietf(_dot_)org(_dot_)
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Kucherawy Expires April 13, 2009 [Page 20]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html