RFC relevance of mechanism

As per Relevance of the word mechanism, we have this rfc below:

Network Working Group J.
Request for Comments: 2554 Netscape
Category: Standards Track March 1999

SMTP Service
for

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

1.

This document defines an SMTP service extension [ESMTP] whereby
SMTP client may indicate an authentication mechanism to the server
perform an authentication protocol exchange, and optionally
a security layer for subsequent protocol interactions.
extension is a profile of the Simple Authentication and
Layer [SASL].

2. Conventions Used in this

In examples, "C:" and "S:" indicate lines sent by the client
server respectively

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY
in this document are to be interpreted as defined in "Key words
use in RFCs to Indicate Requirement Levels" [KEYWORDS].

3. The Authentication service

(1) the name of the SMTP service extension is "Authentication

(2) the EHLO keyword value associated with this extension is "AUTH

Myers Standards Track [Page 1]

RFC 2554 SMTP Authentication March 1999

(3) The AUTH EHLO keyword contains as a parameter a space
list of the names of supported SASL mechanisms

(4) a new SMTP verb "AUTH" is

(5) an optional parameter using the keyword "AUTH" is added to
MAIL FROM command, and extends the maximum line length of
MAIL FROM command by 500 characters

(6) this extension is appropriate for the submission
[SUBMIT].

4. The AUTH

AUTH mechanism [initial-response

Arguments
a string identifying a SASL authentication mechanism
an optional base64-encoded

Restrictions
After an AUTH command has successfully completed, no more
commands may be issued in the same session. After a
AUTH command completes, a server MUST reject any further
commands with a 503 reply

The AUTH command is not permitted during a mail transaction

Discussion
The AUTH command indicates an authentication mechanism to
server. If the server supports the requested
mechanism, it performs an authentication protocol exchange
authenticate and identify the user. Optionally, it
negotiates a security layer for subsequent
interactions. If the requested authentication mechanism is
supported, the server rejects the AUTH command with a 504
reply

The authentication protocol exchange consists of a series
server challenges and client answers that are specific to
authentication mechanism. A server challenge, otherwise
as a ready response, is a 334 reply with the text
containing a BASE64 encoded string. The client answer
of a line containing a BASE64 encoded string. If the
wishes to cancel an authentication exchange, it issues a
with a single "*". If the server receives such an answer,
MUST reject the AUTH command by sending a 501 reply

Myers Standards Track [Page 2]

RFC 2554 SMTP Authentication March 1999

The optional initial-response argument to the AUTH command
used to save a round trip when using authentication
that are defined to send no data in the initial challenge
When the initial-response argument is used with such
mechanism, the initial empty challenge is not sent to
client and the server uses the data in the initial-
argument as if it were sent in response to the empty challenge
Unlike a zero-length client answer to a 334 reply, a zero
length initial response is sent as a single equals sign ("=").
If the client uses an initial-response argument to the
command with a mechanism that sends data in the
challenge, the server rejects the AUTH command with a 535
reply

If the server cannot BASE64 decode the argument, it rejects
AUTH command with a 501 reply. If the server rejects
authentication data, it SHOULD reject the AUTH command with
535 reply unless a more specific error code, such as one
in section 6, is appropriate. Should the client
complete the authentication exchange, the SMTP server issues
235 reply

The service name specified by this protocol's profile of
is "smtp".

If a security layer is negotiated through the
authentication exchange, it takes effect immediately
the CRLF that concludes the authentication exchange for
client, and the CRLF of the success reply for the server.
a security layer's taking effect, the SMTP protocol is reset
the initial state (the state in SMTP after a server issues
220 service ready greeting). The server MUST discard
knowledge obtained from the client, such as the argument to
EHLO command, which was not obtained from the SASL
itself. The client MUST discard any knowledge obtained
the server, such as the list of SMTP service extensions,
was not obtained from the SASL negotiation itself (with
exception that a client MAY compare the list of advertised
mechanisms before and after authentication in order to
an active down-negotiation attack). The client SHOULD send
EHLO command as the first command after a successful
negotiation which results in the enabling of a security layer

The server is not required to support any
authentication mechanism, nor are authentication
required to support any security layers. If an AUTH
fails, the client may try another authentication mechanism
issuing another AUTH command

Myers Standards Track [Page 3]

RFC 2554 SMTP Authentication March 1999

If an AUTH command fails, the server MUST behave the same as
the client had not issued the AUTH command

The BASE64 string may in general be arbitrarily long.
and servers MUST be able to support challenges and
that are as long as are generated by the
mechanisms they support, independent of any line
limitations the client or server may have in other parts of
protocol implementation

Examples
S: 220 smtp.example.com ESMTP server
C: EHLO jgm.example.
S: 250-smtp.example.
S: 250 AUTH CRAM-MD5 DIGEST-MD
C: AUTH
S: 504 Unrecognized authentication type
C: AUTH CRAM-MD
S: 334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful

5. The AUTH parameter to the MAIL FROM

AUTH=addr-

Arguments
An addr-spec containing the identity which submitted the
to the delivery system, or the two character sequence "<>"
indicating such an identity is unknown or
authenticated. To comply with the restrictions imposed on
parameters, the addr-spec is encoded inside an xtext. The
of an xtext is described in section 5 of [ESMTP-DSN].

Discussion
The optional AUTH parameter to the MAIL FROM command
cooperating agents in a trusted environment to communicate
authentication of individual messages

If the server trusts the authenticated identity of the client
assert that the message was originally submitted by the
addr-spec, then the server SHOULD supply the same addr-spec in
AUTH parameter when relaying the message to any server
supports the AUTH extension

Myers Standards Track [Page 4]

RFC 2554 SMTP Authentication March 1999

A MAIL FROM parameter of AUTH=<> indicates that the
submitter of the message is not known. The server MUST NOT
the message as having been originally submitted by the client

If the AUTH parameter to the MAIL FROM is not supplied,
client has authenticated, and the server believes the message
an original submission by the client, the server MAY supply
client's identity in the addr-spec in an AUTH parameter
relaying the message to any server which supports the
extension

If the server does not sufficiently trust the
identity of the client, or if the client is not authenticated
then the server MUST behave as if the AUTH=<> parameter
supplied. The server MAY, however, write the value of the
parameter to a log file

If an AUTH=<> parameter was supplied, either explicitly or due
the requirement in the previous paragraph, then the server
supply the AUTH=<> parameter when relaying the message to
server which it has authenticated to using the AUTH extension

A server MAY treat expansion of a mailing list as a
submission, setting the AUTH parameter to the mailing
address or mailing list administration address when relaying
message to list subscribers

It is conforming for an implementation to be hard-coded to
all clients as being insufficiently trusted. In that case,
implementation does nothing more than parse and
syntactically valid AUTH parameters to the MAIL FROM command
supply AUTH=<> parameters to any servers to which
authenticates using the AUTH extension

Examples
C: MAIL FROM: AUTH=e+3Dmc2@example.
S: 250

Myers Standards Track [Page 5]

RFC 2554 SMTP Authentication March 1999

6. Error

The following error codes may be used to indicate various
as described

432 A password transition is

This response to the AUTH command indicates that the user needs
transition to the selected authentication mechanism. This
done by authenticating once using the PLAIN authentication mechanism

534 Authentication mechanism is too

This response to the AUTH command indicates that the
authentication mechanism is weaker than server policy permits
that user

538 Encryption required for requested authentication

This response to the AUTH command indicates that the
authentication mechanism may only be used when the underlying
connection is encrypted

454 Temporary authentication

This response to the AUTH command indicates that the
failed due to a temporary server failure

530 Authentication

This response may be returned by any command other than AUTH, EHLO
HELO, NOOP, RSET, or QUIT. It indicates that server policy
authentication in order to perform the requested action

Myers Standards Track [Page 6]

RFC 2554 SMTP Authentication March 1999

7. Formal

The following syntax specification uses the augmented Backus-
Form (BNF) notation as specified in [ABNF].

Except as noted otherwise, all alphabetic characters are case
insensitive. The use of upper or lower case characters to
token strings is for editorial clarity only. Implementations
accept these strings in a case-insensitive fashion

UPALPHA = %x41-5A ;; Uppercase: A-

LOALPHA = %x61-7A ;; Lowercase: a-

ALPHA = UPALPHA / LOALPHA ;; case

DIGIT = %x30-39 ;; Digits 0-9

HEXDIGIT = %x41-46 / DIGIT ;; hexidecimal digit (uppercase

hexchar = "+" HEXDIGIT

xchar = %x21-2A / %x2C-3C / %x3E-7
;; US-ASCII except for "+", "=", SPACE and

xtext = *(xchar / hexchar

AUTH_CHAR = ALPHA / DIGIT / "-" / "_"

auth_type = 1*20AUTH_

auth_command = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
*(CRLF [base64])

auth_param = "AUTH="
;; The decoded form of the xtext MUST be
;; an addr-spec or the two characters "<>"

base64 = base64_terminal /
( 1*(4base64_CHAR) [base64_terminal] )

base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Case-

base64_terminal = (2base64_char "==") / (3base64_char "=")

continue_req = "334" SPACE [base64]

Myers Standards Track [Page 7]

RFC 2554 SMTP Authentication March 1999

CR = %x0C ;; ASCII CR, carriage

CRLF = CR

CTL = %x00-1F / %x7F ;; any ASCII control character and

LF = %x0A ;; ASCII LF, line

SPACE = %x20 ;; ASCII SP,

8.

[ABNF] Crocker, D. and P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.

[CRAM-MD5] Klensin, J., Catoe, R. and P. Krumviede, "IMAP/
AUTHorize Extension for Simple Challenge/Response",
2195, September 1997.

[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D
Crocker, "SMTP Service Extensions", RFC 1869,
1995.

[ESMTP-DSN] Moore, K, "SMTP Service Extension for Delivery
Notifications", RFC 1891, January 1996.

[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.

[SASL] Myers, J., "Simple Authentication and Security
(SASL)", RFC 2222, October 1997.

[SUBMIT] Gellens, R. and J. Klensin, "Message Submission",
2476, December 1998.

[RFC821] Postel, J., "Simple Mail Transfer Protocol", STD 10,
821, August 1982.

[RFC822] Crocker, D., "Standard for the Format of ARPA
Text Messages", STD 11, RFC 822, August 1982.

Myers Standards Track [Page 8]

RFC 2554 SMTP Authentication March 1999

9. Security

Security issues are discussed throughout this memo

If a client uses this extension to get an encrypted tunnel through
insecure network to a cooperating server, it needs to be
to never send mail to that server when the connection is not
authenticated and encrypted. Otherwise, an attacker could steal
client's mail by hijacking the SMTP connection and either
the server does not support the Authentication extension or
all AUTH commands to fail

Before the SASL negotiation has begun, any protocol interactions
performed in the clear and may be modified by an active attacker
For this reason, clients and servers MUST discard any
obtained prior to the start of the SASL negotiation upon
of a SASL negotiation which results in a security layer

This mechanism does not protect the TCP port, so an active
may redirect a relay connection attempt to the submission
[SUBMIT]. The AUTH=<> parameter prevents such an attack from
an relayed message without an envelope authentication to pick up
authentication of the relay client

A message submission client may require the user to
whenever a suitable SASL mechanism is advertised. Therefore, it
not be desirable for a submission server [SUBMIT] to advertise a
mechanism when use of that mechanism grants the client no
over anonymous submission

This extension is not intended to replace or be used instead of end
to-end message signature and encryption systems such as S/MIME
PGP. This extension addresses a different problem than end-to-
systems; it has the following key differences

(1) it is generally useful only within a trusted

(2) it protects the entire envelope of a message, not just
message's body

(3) it authenticates the message submission, not authorship of
message

(4) it can give the sender some assurance the message
delivered to the next hop in the case where the
mutually authenticates with the next hop and negotiates
appropriate security layer

Myers Standards Track [Page 9]

RFC 2554 SMTP Authentication March 1999

Additional security considerations are mentioned in the
specification [SASL].

10. Author's

John Gardiner
Netscape
501 East Middlefield
Mail Stop MV-029
Mountain View, CA 94043

EMail: jgmyers@netscape.

Myers Standards Track [Page 10]

RFC 2554 SMTP Authentication March 1999

11. Full Copyright

Copyright (C) The Internet Society (1999). All Rights Reserved

This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English

The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns

This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE

Myers Standards Track [Page 11]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX