Subject: regarding draft-myers-smtp-auth-08.txt

From: "Jack De Winter" <[email-masked]>
Date: Thu, 08 Jan 1998 15:11:49 -0500

a quick question regarding the inclusion of the AUTH=addr-spec to
the Mail From line.

My question centres around how to translate any characters that are in
the "not allowed list" (space, '=', and any of the control characters)
to something that can be placed in that line.

If you examine the definition for addr-spec, it boils down mainly to
atoms and words.  With an atom, the '=' is not covered in the specs,
and with the words, it devolves into atoms and quoted strings.

Given an example authentication id such as:

"name=\"Fred Flintstone\""@mynode.com

how would we encode that so that it could be passed as an authentication
token, seeing as it is perfectly valid according to the RFC822
construction rules for addr-spec?

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/jacks/

---

From: Chris Newman <[email-masked]>
Date: Thu, 08 Jan 1998 12:30:40 -0800 (PST)

> construction rules for addr-spec?

Good question.  I believe the SMTP AUTH spec should be revised to use the
encoding described in section 5 of RFC 1891.

		- Chris

---

From: "Jack De Winter" <[email-masked]>
Date: Tue, 13 Jan 1998 12:30:08 -0500

>encoding described in section 5 of RFC 1891.

To be more specific:

5.  Additional parameters for RCPT and MAIL commands

   The extended RCPT and MAIL commands are issued by a client when it
   wishes to request a DSN from the server, under certain conditions,
   for a particular recipient.  The extended RCPT and MAIL commands are
   identical to the RCPT and MAIL commands defined in [1], except that
   one or more of the following parameters appear after the sender or
   recipient address, respectively.  The general syntax for extended
   SMTP commands is defined in [4].

   NOTE: Although RFC 822 ABNF is used to describe the syntax of these
   parameters, they are not, in the language of that document,
   "structured field bodies".  Therefore, while parentheses MAY appear
   within an emstp-value, they are not recognized as comment delimiters.

   The syntax for "esmtp-value" in [4] does not allow SP, "=", control
   characters, or characters outside the traditional ASCII range of 1-
   127 decimal to be transmitted in an esmtp-value.  Because the ENVID
   and ORCPT parameters may need to convey values outside this range,
   the esmtp-values for these parameters are encoded as "xtext".
   "xtext" is formally defined as follows:

     xtext = *( xchar / hexchar )

     xchar = any ASCII CHAR between "!" (33) and "~" (126) inclusive,
          except for "+" and "=".

; "hexchar"s are intended to encode octets that cannot appear
; as ASCII characters within an esmtp-value.

     hexchar = ASCII "+" immediately followed by two upper case
          hexadecimal digits

When encoding an octet sequence as xtext:

+ Any ASCII CHAR between "!" and "~" inclusive, except for "+" and "=",
  MAY be encoded as itself.  (A CHAR in this range MAY instead be
  encoded as a "hexchar", at the implementor's discretion.)

+ ASCII CHARs that fall outside the range above must be encoded as
  "hexchar".

Is there any reason why we should use this approach instead of the
Quoted-Printable approach?  I know its a difference of whether or
not the character is a % or a +, but just curious.

Also, the 129 character limit, is that 129 characters after or before
any translation to hexchars are applied?

regards,
Jack

---

From: Chris Newman <[email-masked]>
Date: Thu, 08 Jan 1998 12:30:40 -0800 (PST)

- Chris

---

From: "Jack De Winter" <[email-masked]>
Date: Tue, 13 Jan 1998 12:30:08 -0500

To be more specific:

regards,
Jack