quick & dirty alternate addresses

[Adam M. Costello]

While we're considering new header fields and new address-mapping
servers to deal with the problem of having alternate addresses, we ought
to consider how far we could get with what we already have.

Consider this:

From: "name1a <***@domain1a> / name1b <***@domain1b> /
name1c <***@domain1c>" <***@domain1a_ACE>
To: "name2a <***@domain2a> / name2b <***@domain2b>"
<***@domain2a_ACE>,
"name3a <***@domain3a> / name3b <***@domain3b>"
<***@domain3a_ACE>

This is perfectly valid syntax today. Non-ASCII names and addresses
inside the display-name can be represented as encoded-words, and will
display legibly in MIME-enabled MUAs (even if they are IMA-unaware).
The actual angle-addr is encoded using ACE (if necessary), not
encoded-words, and will display correctly only in an IMAA-enabled
MUA, but even if it's not displayed correctly, the user can still see
the redundant copy inside the display-name. If one of the alternate
addresses is pure ASCII, that one could be used for the angle-addr in
order to avoid the use of ACE. (But we still need ACE so that someone
who remembers one of the non-ASCII addresses can later type it in and
have it traverse the SMTP infrastructure.)

In today's MUAs, the user will see all the alternate addresses and can
recognize/remember the one that's easiest and ignore the rest. When
someone replies to all, or saves an address in an address book, all the
alternates automatically go along for the ride, even if the MUA has no
awareness that the display-name contains alternate addresses.

Newer MUAs could look for display-names that obey the pattern, and
perhaps do something more intelligent, like favor the part of the
display-name whose characters are best correlated with the user's
primary script. (But you should always have the option of being shown
the entire display-name and angle-addr, and you should be shown all of
that whenever you compose a reply.)

Of course, when the first message in a thread is composed, unless there
is an address-mapping server, the alternates won't get put in the To:
field unless they were already in the sender's address book.

AMC

[Arnt Gulbrandsen]

Post by Adam M. Costello
While we're considering new header fields and new address-mapping
servers to deal with the problem of having alternate addresses, we ought
to consider how far we could get with what we already have.

...
We don't have that. From my point of view, I could implement it, but it
would be roughly as much work as for the Address-Map list.

I'm jittery about two things, though. 1: What effect do really long
display-parts, say 100 characters, have on crapware? 2: What happens when
crapware simply converts to 8-bit and sends that untagged, without
knowing the New Scheme?

Address-Map seems better, since for that method, that the entire header
field may go away, and that's it. As long as the field is present, it
works, if it has been stripped e.g. by some mailing-list software, things
degrade in a comprehensible manner.

--Arnt

[n***@mrochek.com]

Post by Arnt Gulbrandsen

Post by Adam M. Costello
While we're considering new header fields and new address-mapping
servers to deal with the problem of having alternate addresses, we ought
to consider how far we could get with what we already have.

...
We don't have that. From my point of view, I could implement it, but it
would be roughly as much work as for the Address-Map list.
I'm jittery about two things, though. 1: What effect do really long
display-parts, say 100 characters, have on crapware?

You're right to be worried, as not only are there problems handling long
phrases, I believe there are actually buffer overrun vulnerabilities in this
space. Even if these problems are fixed now (whatever that means) the existance
of a buffer overrun means some firewalls are likely to enforce draconian limits
on such things.'

Ned

[Adam M. Costello / Píxèl Män]

we ought to consider how far we could get with what we already have.

...
We don't have that. From my point of view, I could implement it, but it
would be roughly as much work as for the Address-Map list.

Even if you implement nothing, we already have this. See the From and
To fields of this very message. MUAs already allow people to set the
display-names for themselves and for recipients.

What effect do really long display-parts, say 100 characters, have on
crapware?

That might be a sufficiently serious problem to make this unworkable.

What happens when crapware simply converts to 8-bit and sends that
untagged, without knowing the New Scheme?

I don't know about crapware, but any MIME-supporting MUA, given an
arbitrary non-ASCII display-name, will encode it using encoded-words.

AMC

[Arnt Gulbrandsen]

Post by Arnt Gulbrandsen
We don't have that. From my point of view, I could implement it, but
it would be roughly as much work as for the Address-Map list.

Even if you implement nothing, we already have this. See the From and
To fields of this very message. MUAs already allow people to set the
display-names for themselves and for recipients.

Sure. But to use them as addresses, I have to write real parsing code.
Just as I'd have to write such code to parse address-map.

--Arnt

[Adam M. Costello]

MUAs already allow people to set the display-names for themselves
and for recipients.

Sure. But to use them as addresses, I have to write real parsing
code.

Why would a software agent want to use one of the alternate addresses?
It can just use the real angle-addr (as it always has), and treat the
display-name as an opaque string to display to the user (as it always
has). It's only humans who might have trouble using the angle-addr
(because it might be hard to remember), and thus it's only humans who
need to be able to see the addresses in the display-name, so that if
they ever need to recall an address, they'll have an easier one to
remember.

One of the selling points of the display-name approach was that it would
work in existing MUAs. But that was assuming that they wouldn't choke
on long display-names, which unfortunately seems not to be the case.

AMC

[Pete Resnick]

Post by Adam M. Costello
One of the selling points of the display-name approach was that it
would work in existing MUAs. But that was assuming that they
wouldn't choke on long display-names, which unfortunately seems not
to be the case.

Actually, that's not my problem (and I suspect it's not the other's

Post by Adam M. Costello
It can just use the real angle-addr (as it always has), and treat
the display-name as an opaque string to display to the user (as it
always has).

Nope, 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. But when the MUA tries
to re-encode the address, it finds these angle-bracketed things that
it thinks are illegal addresses and chokes.

pr

[Adam M. Costello]

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-***@tést.example>" <ietf-***@imc.org>

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?=
<ietf-***@imc.org>

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-***@tést.example>" <ietf-***@imc.org>

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

[Keith Moore]

Post by Adam M. Costello
That's interesting. My MUA (Mutt) has no such trouble. I've created
* Is the To: field of this message valid?

yes.

Post by Adam M. Costello
* If so, should MUAs be able to compose a reply to it?

yes, but given that many MUAs implemented RFC 2047 not by changing how
header fields were displayed but by converting header fields containing
encoded-words on the fly, and then using the converted form to compose
replies,
it's unsurprising if MUAs don't do the right thing with it.

Post by Adam M. Costello
* If MUAs should be able to compose a reply to it, what is the proper
procedure

the proper procedure is to use the original message (not the form
converted for display) to compose the reply.

[Simon Josefsson]

Post by Pete Resnick

Post by Adam M. Costello
It can just use the real angle-addr (as it always has), and treat
the display-name as an opaque string to display to the user (as it
always has).

Nope, 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. But when
the MUA tries to re-encode the address, it finds these angle-bracketed
things that it thinks are illegal addresses and chokes.

How is this anything but a software bug? It may be illustrating as a
point in discussion, but if we are going to reject all solutions that
exploit legal constructs in existing specifications, but may trigger a
problem in some piece of software, I don't think we'll be likely to
end up with anything. Introducing capability negotiation, and new
capabilities, including falling back to a compatibility mapping, will
undoubtedly uncover many bugs as well, but that shouldn't prevent us
from choosing that approach [if the gains are worth the prize].

I find the angle-addr-in-quoted-string idea worth exploring. The
arguments against it, so far, hasn't been convincing, to me at least.

Thanks,
Simon

[Arnt Gulbrandsen]

Post by Simon Josefsson
I find the angle-addr-in-quoted-string idea worth exploring. The
arguments against it, so far, hasn't been convincing, to me at least.

Here's an argument:

If early adopters are going to break their correspondents' MUAs in
significant numbers, early adopters will be few and far between.

--Arnt

[Keith Moore]

Post by Simon Josefsson

Post by Pete Resnick
Nope, 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. But when
the MUA tries to re-encode the address, it finds these angle-bracketed
things that it thinks are illegal addresses and chokes.

How is this anything but a software bug?

it's a very common bug. it means the installed base will be less
tolerant of the change, because those running buggy software will get
surprising results when they try to reply to messages.

[Arnt Gulbrandsen]

Post by Adam M. Costello

Post by Arnt Gulbrandsen
Sure. But to use them as addresses, I have to write real parsing code.

Why would a software agent want to use one of the alternate addresses?

Since you ask: For address-book use, and for assigning the message to
the relevant folder(s). Mand maybe more.

--Arnt

[Keith Moore]

Post by Adam M. Costello / Píxèl Män
Even if you implement nothing, we already have this. See the From and
To fields of this very message. MUAs already allow people to set the
display-names for themselves and for recipients.

at least in the MUA I'm currently using, it's confusing as all get out.
it makes it look as if there were multiple senders of the message, with
the wrong syntax.

[n***@mrochek.com]

Post by Keith Moore

Post by Adam M. Costello / Píxèl Män
Even if you implement nothing, we already have this. See the From and
To fields of this very message. MUAs already allow people to set the
display-names for themselves and for recipients.

at least in the MUA I'm currently using, it's confusing as all get out.
it makes it look as if there were multiple senders of the message, with
the wrong syntax.

This pretty much describes the result I got as well. And changing my UA to
handle this case better is far from trivial.

Ned

[Pete Resnick]

On 12/1/03 at 7:12 PM +0000, Adam M. Costello

Post by Adam M. Costello / Píxèl Män
Even if you implement nothing, we already have this. See the From
and To fields of this very message. MUAs already allow people to
set the display-names for themselves and for recipients.

And just as a data point: Mac Eudora was unable to reply to the
message without editing the fields.

pr

[Martin Duerst]

Post by Adam M. Costello
While we're considering new header fields and new address-mapping
servers to deal with the problem of having alternate addresses, we ought
to consider how far we could get with what we already have.

Hello Adam,

I won't comment on the details of your proposal. But I think it's
very good to explore the design space around alternate addresses.
While there are important interactions with Paul's UTF-8 header
proposal, both technically as well as in terms of deployment,
what exact scheme we pick is in many ways just a detail.

Up to now, we have the following alternate address schemes
(please tell me if I missed some):

- Keith's alternate address lookup servers
- Adam's alternate addresses in encoded words
- Paul's Address-map: header
- Calculated alternates using some ACE

For Paul's draft, that suggests to split out the method of
getting to alternate addresses at least into a separate
chapter (maybe later even into a separate draft), so that
it's easy to replace without having to rewrite the whole
document.


Regards, Martin.

[Paul Hoffman / IMC]

Post by Martin Duerst
For Paul's draft, that suggests to split out the method of
getting to alternate addresses at least into a separate
chapter

Yes.

Post by Martin Duerst
(maybe later even into a separate draft)

No.

Post by Martin Duerst
, so that
it's easy to replace without having to rewrite the whole
document.

Yes.

--Paul Hoffman, Director
--Internet Mail Consortium