On Oct 01 2004, Martin Trautmann wrote:
But apart from the user's clash of culture, which is based on a very
personal flavour, it should depend on the idea of a list as well.
What's the idea of a mailing list?
A) one way announcements - e.g. some kind of newsletter or market group
B) dicussion lists
I've always thought of mailing lists as a proxy for one to many
communication, ie an artificial construct which allows an individual
(me!) to interact with a group of people as if it was a single person.
In your case A, I would be "interacting" by never responding to messages,
while in case B I would respond to messages if I like. I can also
mine the mailing list messages for information, such as a person's
email address, and do something such as send them email directly, but
that's "beside" the mailing list interaction, I don't consider it part
of the interaction.
Thus I'm very comfortable about my most interesting dicussion lists, which
set a 'Reply-To' header of the list and a mail reader that does ask me on
reply whether I actually want to answer to the reply-to (prefered default)
or to the original sender. Problem: If the sender defined a Reply-To on
his own, this is replaced by the list. Thus if you want to answer to the
author directly, you can't.
Yes, which is why people have come up with many different types of
extra headers to handle such cases. There are also the complementary problems
where an author may not want their address added, so that people can't
reply directly to him or her.
To me, these are list policy issues. Some lists may insist that posters
display a correct reply address, other lists might anonymise posters,
other lists might restrict who can post and when in complex ways.
When personal addresses are displayed in headers such as Reply-To, it
gives the MUA the ability to interact directly with list posters, in a
way which doesn't involve the list. So I don't see it as a mailing
list problem. Only if a message is sent to the list address (possibly
with other destinations as well) will it become a mailing list problem.
The other option that you mentionned concerned that some people prefer to
view messages as soon as possible which are replies to their own message.
That's a reasonable question. But I feel the best idea here would be some
kind of better threading or filtering in order to detect those messages
which are replies to my own message - e.g. control of my own message-id
and filtering on the In-Reply-To or References.
If the mental picture I described in the previous post is reflective
of the truth, then the source of difficulty in that case is an
information overload problem. Some people subscribe to many lists or
high volume lists, and even with better threading or filtering keeping
an overview may be difficult or require too much time investment.
For such people, the more practical method is not to actively monitor
a large number of sources for interesting things, but instead to
arrange for interesting things to find them on their own whenever
they occur.
For example, consider a high volume mailing list (Arnt's bugtracking
mailing list example). A non-list member X makes a post, but has no
intention of monitoring the mailing list, or even to subscribe to it
and keep it in a separate folder to see if somebody responds. He
doesn't know how quickly a response might come, a few hours, a few
weeks, or whether a response will come at all. Having better threading
or filtering is useless, because the mailing list traffic is not going
to be monitored by his MUA.
But the mailing list server knows immediately that X is not a list
member, so if his post is accepted (this is a policy issue), then if
somebody else responds to this post on the mailing list, the list
server can send X a copy of the message. The people who are list members
don't need to know if X is a list member or not, everything is handled
by the list server.
Unfortunately, a good threading is broken on many lists:
That's one of the reason why newsgroups are much more efficient here: Both
subject manipulation (one Re: only) and References are within a much
tighter standard.
Yes, it's a big problem, and requires a better standard.
What I'm suggesting is that the mailing list server should act as a
more intelligent multiplexer, which could interface with people who prefer
the 1) custom according to the 1) custom, and could interface with
the people who like 2) according to their own preferences, etc.
No, I feel
- the list server should work reasonable
- people should adopt reasonable tooling which does what they actually
want.
ok, I know, wishful thinking...
The fundamental issue is whether you want the logic to reside at the
extremities of the network (ie in the MUA software) or at the center
(ie the mailing list software). Currently, I consider a mailing list
as a star topology:
list member list member
\ /
list member - list server - list member
/ \
list member list member
(where perhaps some members have more privileges than others) When you
want people to have smart MUAs, then conceptually you are imposing
extra direct links between all the list members. That's fine for non
list communication, but for list communication I think it's simpler to
pass everything to and from the list server only.
This line of thinking also reduces the need for extra message headers,
since in this view, the function of extra mailing list headers is
mainly to transfer enough addressing information to a receiving MUA,
so that the logic residing within this MUA can perform the replying
and other interaction it wants.
Simulating custom 1) for list members who like that custom:
* To send mail, a list member sends a single mail to the list address only.
* For each new mail posted to the list, the list server sends a single
copy to the said list member.
custom 1) can be handled more flexibly.
If the list does not set a Reply-To, you have to use e.g. the less known
List-Reply option or the easiest, best known way as a 'group reply'.
Yes, but this is logic which exists inside the MUA. Before the MUA can
perform this type of reply, it needs to learn the destination addresses
by reading both the Reply-To and List-Reply fields.
In the scenario I'm proposing above, there is no need to read the
List-Reply field or other specialized fields. In my scenario, the
Reply-To field contains the mailing list address, and the list server,
when it receives the reply, decides what to do with it, how many
copies to send to each list member, etc.
If the MUA wants to reply directly to the poster without passing through
the mailing list, then for example the From: field can be used.
There are only two operations: list reply and personal reply off list.
If it's a list reply, the logic inside the list server should take care
of everything, if it's reply off list, then the MUA should take care of
everything.
Thus the list server COULD handle that a member won't get a message twice.
Each member could tell the server that he either prefers duplicate
messages (directly + list) or one only (so that the list server won't send
a copy to him if he's in the To/Cc).
The sender still can inforce both e.g. by putting a recipient as Bcc.
Yes, but doing so would become unnecessary as list servers become smarter.
Simulating custom 2) for list members who prefer that custom:
* To send mail, the list member sends a single mail to the list address
only.
* For each new mail posted to the list, the list server sends a copy
to the said list member. Furthermore, the list server checks in the
list archive to see who posted the parent message, and if the parent is
identical to the said list member, then a second courtesy copy is sent
to this list member.
Hm - strange thing that I actually never wanted. But probably this
courtesy copy could act in most different styles, e.g. by sending a
digested overview of answered messages. Or by sending a SMS or any other
type of message on any other message channel.
I should explain this better, as I see it. Nowadays, people's MUAs can
look in several fields (To, Cc, ...) for the presence of the list
address (e.g. ietf-822(_at_)imc(_dot_)org). If this address is found, then the
message is a list message, so it is put in another folder say, away
from the inbox.
But with custom 2), the personal courtesy copy doesn't contain the
list address in those places, so when it is received it probably stays
in the inbox. When the human being looks at his inbox, he sees the
courtesy copy and realizes that there has been a reply on the mailing
list. He then takes action as he wants to. Without the courtesy copy,
he would only see the reply inside the list folder, and he only looks
at this folder once a week maybe...
So in my simulation scenario above, the list server sends the normal
copy containing the list address, which will probably be filed away
automatically in the folder. But the list server also sends a courtesy
copy where the list address is absent, which will end up in the
inbox and be seen. Of course, the exact details are a question of
preferences chosen by the list member.
However, this kind of service could be done not only by the list server,
but more powerful
- on the user's mail agent which does proper sorting/filtering or
- by some kind of dedicated service provider which will filter
incoming messages from the list and will provide further actions,
such as your courtesy copy.
Yes, that is possible as well. However, in that case, we already have
the current system, where people get unwanted duplicates and other people
don't receive personal replies. This extra traffic can only be
"fixed" by making it unnecessary, ie if the list server handles it.
Behind the scenes, the list server implementation could involve
a dedicated service provider etc. of course.
This sort of system accomodates everybody at a high level, and the
cost is small (modifying list servers) compared with some alternatives
proposed (modifying everybody's MUA, or modifying everybody's
behaviour).
It depends on the kind of service that you want. At the moment you feel a
courtesy copy is good enough. But maybe someone else prefers a short note
on his pager or mobile phone. Maybe someone wants a short automated phone
call - or even a telegram or nice piece of paper on a silver platter ;-)
Luckily, people don't yet phone me up for every message
they send to some mailing list, but it's possible ;-)
--
Laird Breyer.