On Thu December 9 2004 09:03, Jacob Palme wrote:
A related issue is if a message arrives in two copies, one
with the recipient as personal recipient, the other via a
mailing list. When this happens, the cause is almost always
faulty handling by the sender's MUA, and the intention is
that the message should only be sent to/via the list. So in
this case, the best receiving MUA behaviour is probably to
completely suppress the personal copy of the message.
We've had this discussion recently; check the archives
for September and October. There are several actors
involved (in particular, it's not exactly clear who you
mean by "sender"):
O: a message originator
MA: mailing list expander for list A
MB: mailing list expander for list B
R: respondent to a mailing list message
D: a recipient of the response (directly, via a list
expander, or both)
O can indicate a suggestion for where to send responses
via the Reply-To message header field (as described in
RFCs 2822, 822, 733; it is particularly applicable to
messages sent to mailing lists ("text message
teleconference") as described in those RFCs).
Some mailing list expanders inappropriately alter or
insert an author's Reply-To field, causing problems.
The field is clearly defined as an originator field, and
should not be touched by list expanders -- expanders
have a variety of List- fields for their use (RFCs 2369,
2919). Let's assume that MA and MB are well-behaved
and do not affect originator fields.
A message sent by O duly arrives at list subscribers'
mailboxes and may be visible via mailing list archives
or web interfaces (etc.). A respondent R elects to
send a message regarding some topic in a message
sent by O. R presumably knows whether his
response is intended for O alone or for the entire
mailing list(s), or for O as well as mailing list subscriber/
viewers (O might not be a mailing list subscriber). In
general R cannot know whether or not O is a
mailing list subscriber, nor can he tell what O's
preferences are. Only if O clearly indicates these
items can R make an informed decision. If O, as
the author (possibly also sender) of the original
message did not include any such indication or a
Reply-To field suggesting a set of addresses for
responses, R must guess. Invariably some guess
will turn out to be inconsistent with some O's
preferences. Who is to blame: the hapless R who
has been forced into guessing, or O who failed to
provide any information? It is unreasonable to
blame any MUA, since the MUA is only an agent
for a human -- the human must decide (or guess)
where to send a message (response or otherwise),
and what suggestion to include (if any) for response
destinations for that message. I certainly don't want
UAs second-guessing. Just as R in general has no
way of knowing whether or not O is a subscriber to
any given mailing list, R's MUA certainly has no way
of making such a determination.
Some mailing list expanders have an option for list
subscriber to suppress list copies of messages in
which the list subscriber's exact mailbox appears in
a list message's recipient address fields. That of
course can't help those who are not list subscribers,
list subscribers who, for whatever reason, have a
different list mailbox from any other mailbox which
might result in delivery to the same person, nor is
it able to take into account the fact that recipient
message header fields have nothing whatsoever to
do with actual message recipients (other than by
convention).
Some MDAs have the capability of suppressing
duplicate messages. As do some rMUAs. But a
respondent should not rely on that ability of *some*
MDAs and *some* MUAs -- if an original message's
author has suggested a specific set of addresses, a
respondent shouldn't send a scattergun response
under the assumption that duplicate suppression
will occur.
All described above is easy to implement if the mailer
keeps a data base of message-ids and which messages they
refer to.
It's unclear what you mean by "mailer": the author?
the sender (if different from the author)? the author's
MUA? some MSA or MTA or MDA? some recipient's
rMUA?... It's also unclear how that would help those
who choose to interact with mailing lists via a web
interface.