Re: quick & dirty alternate addresses

Pete Resnick <[email protected]> wrote:

> my MUA has never treated the display-name as an opaque string.  It
> decodes it and, upon reply, copies the whole address (display name and
> angle-addr) directly into the "To:" field where it expects to be able
> to be able to re-encode it for sending.

I guess "opaque" was the wrong word.  I just meant that it contains no
protocol elements, only text for the human.  I accept all of the above.

> But when the MUA tries to re-encode the address, it finds these
> angle-bracketed things that it thinks are illegal addresses and
> chokes.

That's interesting.  My MUA (Mutt) has no such trouble.  I've created
another display-name test in the To: field of this message.  I wonder:

 * Is the To: field of this message valid?

 * If so, should MUAs be able to compose a reply to it?  Or is there a
   flaw in the specs that allows To: fields for which replies cannot be
   composed?

 * If MUAs should be able to compose a reply to it, what is the proper
   procedure, and how does that differ from whatever your MUA is doing?

I can tell you what Mutt does.  I type this into the To: field:

To: "tést <fake-address@tést.example>" <[email protected]>

Since the display-name contains non-ASCII characters, encoded-words will
need to be used.  The special characters (brackets, at-sign, dots) are
not allowed bare in a display-name, so they need to be either quoted or
encoded (that's why I quoted them when I entered the To: field).  Since
encoded-words are not allowed inside quoted-strings, Mutt removes the
quotes and encodes the special characters as =3C, =3E, =40, =2E inside
the quoted-printable encoded-word, resulting in:

To: =?iso-8859-1?Q?t=E9st_=3Cfake-address=40t=E9st=2Eexample=3E?=
  <[email protected]>

When it receives this header, it decodes the encoded-words and then,
because the result contains special characters that are not allowed bare
in a display-name, it puts the result in quotes, and displays this:

To: "tést <fake-address@tést.example>" <[email protected]>

When I reply, it converts that back into an unquoted encoded-word as
described above.

I don't know if Mutt's behavior is required by the specs, or if the Mutt
authors just figured that this is what they needed to do.

AMC