} Actually I believe that UAs should encourage people to *select* the
} recipient list of *every* reply which would otherwise be addressed to
} more than one recipient. Of course, they should make the recipient
} (the one issuing the reply) aware of the sender's preference, as
} expressed through the reply-to field from the subject message.
That's all nice in the abstract, but I was just discussing this today
with several of my co-workers, and they all agreed that they hate it
when their UA asks them questions or requires that sort of extra action.
Yeah, I hate it too. But I'm not sure that it can't be done in a
way which is both convenient and effective.
I'm imagining a reply interface where my UA pops up an editing window
and shows me every recipient to which the reply might be addressed,
with the "selected" recipients in normal text and the "unselected"
recipients in dim/gray text. There might also be some sort of
indication (color?) as to where the recipient address came from (From,
To, Cc, Reply-To). The "reply" button would then pop up an editing
window with the default set of recipients selected, but there would be
buttons to select other behaviors (like reply-to-sender only), and I
could click on any recipient to toggle the selected bit.
Guess I'll have to code it up and try it...
} It's an open question as to whether UAs that encourage such behavior
} can be successful in the market...users would probably rather be lazy
} than aware, even if they occasionally get bitten for being lazy.
You have the right of it there. The best thing is for UAs to get better at
providing a complete, yet minimal, set of "default" addresses.
I'm not sure what this would mean. "Complete", for example, is highly
dependent on the context in which a message is sent -- something the
UA isn't likely to know about.
} At any rate, I suspect we're going to end up with some sort of
} List-Address or List-Reply-To header, along with List-Subscribe,
} List-Unsubscribe etc. It's easy to do, and there was a lot of support
} for it at the listhdr BOF at the Memphis IETF.
I see how this might solve the multiple-copies problem for those who are
on the list. How does it solve the lack-of-any-copy problem for those
who are NOT on the list?
It won't. But we'll probably end up with a List-Address header for
other reasons. Once it's there, UAs will probably acquire "reply to
list" commands. We should probably specify in the List-Address field
defintiion that UAs MUST NOT use the List-Address field for the
default reply.
} I thought about proposing a header of the form
}
} Dont-Reply-To: <x(_at_)foo(_dot_)com> if-replying-to <y(_at_)bar(_dot_)com>
I think this is nasty from the user interface point of view, because of
the very effect that you give as its first advantage:
} + It doesn't change the user interface for the guy issuing the
} reply. He just says 'reply' or "reply to author" or reply to
} author+to+cc or whatever he says now, and the user agent does
} this, but leaving out the redundant addresses.
Just because users generally don't notice where replies are going doesn't
mean that they never notice. Some user is going to see two messages that
appear to be identical -- they have the same To/From/Cc -- but then when
he replies to one of them, the To address is NOT included, yet when he
replies to the other, that same address in the same field IS included.
How does the UA explain that inconsistency? By showing the user that
horrible-looking header? Please no. The inconsistency and having that
header visible would both be nightmares; I can't decide which is worse.
The only way to know is to test it. But the confusion doesn't seem
(to me) to be any worse than that which would result from Followup-To
or Reply-Cc.
I agree that reply generation should be based on simple rules that a
user can understand. Ideally they should be the same for most UAs.
} - There's nothing to stop lists from munging this header.
There's also nothing to stop MTAs from munging other headers, so that
it becomes necessary to equate <x(_at_)foo(_dot_)com> with
<x(_at_)bar(_dot_)Foo(_dot_)COM> and
other such lunacy. I think anything involving address comparisons is
doomed to failure.
Good point. The rewriting situation is better than it used to be,
(not so many sendmails rewrite addresses anymore), but it's common
for firewalls to rewrite addresses to hide internal domains.
} If more UAs had
} duplicate suppression there would be very minimal additional gain to
} be had from Dont-Reply-To or similar proposals.
But duplicate suppression doesn't solve the lack-of-any-copy problem.
There still needs to be a way to say "please DO send me a copy," and to
do so without having the list server stomp on it.
By that logic, we can't solve the problem by adding a new header.
There is almost no header that some list server or gateway won't stop
on. Each of the following behaviors is, I believe, quite common:
+ adding or changing the sender header
+ adding a reply-to header
+ changing a sender-supplied reply-to header
+ removing certain headers (e.g. received)
+ removing all headers except those in a stop-list
+ adding headers (comments, x-list-*, precedence, errors-to)
+ rewriting header addresses (in to, from, cc headers)
+ munging the subject header
+ don't send me a copy of the list mail if I'm already in
the to/cc header.
On the other hand, if we can discourage certain of these behaviors,
then it becomes reasonable to say something like "lists SHOULD NOT
mung a sender-supplied Reply-To header", which in turn provides a way
for a sender to say "please DO send me a copy of the reply" which is
compatible with existing UAs.
Keith