From: "Bruce Lilly" <blilly(_at_)erols(_dot_)com>
I agree with most of your statements. I have some comments about the
following.
Expecting a mailing list expander to become such a magic
oracle is an unrealistic expectation, at least with current
mail protocols [and this is not the place to discuss possible
future protocols, that would be the mail-ng list]. The implicit
assumptions that you made all bear upon that:
* expecting software to be able to deduce message relationships
is unrealistic because there is no mandatory feature of the
mail protocols which can be used (Message-ID, In-Reply-To, and
References are all optional). That leaves examining the entire
archive content and making some sort of guess as an alternative;
albeit an expensive alternative that still amounts to mere
guesswork.
In my design philoshophy (which is incorporated into our mail products), I
believe the host is very much in the middle and has technical
responsibilities in making sure that the technical expectations for the
targeted end-point mail reader or device is statisfied.
Just consider the high possibility for hetergenous systems - non-RFC/RFC
gateways and transformations. When that user finally pops into a server, if
that stored message is not RFC 822 ready, the pop3 server needs to make sure
it is RFC 822 prepared accordingly when transferring it.
Same is true for mail receivers and mail list server and "expanders." when
sending out.
Again, that has been my design approach in helping to create the "best"
natural and/or technical expectations for the end-point.
* lacking strong authentication in the core mail protocol, it
is not possible for mailing list software (or humans for that
matter) to accurately determine the identity of a message
author or sender [without depending on the sender to include
some optional authentication information such as a digital
signature]. Inability to identify the author/sender means
an inability to perform some feat of magic based on author/
sender identity.
[Minor side note: Generally True, but trust always begins at the submission
point. I trust all mail coming into this list is not based on abuse, that
atleast there is a 'subscription' concept to the service. That in itself
is a "authentication" as small it may be. Coupled with recent Return Path
Authethication ideas, more strength is added.]
Ergonomically, the mailing list "kludge" simulate the idea groupware
conferencing where frankly, the name of the author is usually oblivious to
the readers. Content is more important. You say your are "bruce lilly"
from so so address.com, well, that means nothing to me and most readers.
Sure, many people have no problem exposing what is actually "real contact
information." but it is only when we try to do more personal direct contact
and communications, face to face or otherwise, where it becomes important.
Sure, the name can become "branded" in some way, but If you understand my
point, I had no control of the receipt of your message. It came from a
common "Dummy User" (the list address) that is authorized on our end. But
generally, it (your address) is really meaningless until it becomes
important, if ever, for pure direct communications.
* because different humans have different preferences, a one-
size-fits-all approach enforced by fascist software won't
work for a group with diverse preferences.
But there should be some level of standard conformity at both ends, and as I
starting above, I believe the host is an important factor as well,
providing the necessary expectations for the natural behavior of the end
point.
This includes two parts:
Network Control Lines
Information/Display Control Lines.
A simple idea is this.
The standard expectation for a MUA are:
Display (ignoring CC/BC):
From: 822.From
To: 822.To
For a Reply, the Network Control Lines are:
821.MailFrom MUA account Reply Address or Display Address
821.RcptTo Taken from message Reply-To: or From:
822.From MUA account Display Address
822.To Taken from message Reply-To: or From:
These are the general across the aboard framework. So regardless if the
EMAIL message is a mailing list-based "kludge," I believe it is still
necessary that the host makes sure the network controls are proper for
natural MUA reaction as it is most common, expected and "defined" today.
So when hitting the REPLY button the natural technical expection should be
preserved.
Is there such a concept of standard "Mailing List Technology" and ideas that
a host and MUA can be trained to provide this natural functionality?
I think so. I would like to see what that is. That is my interest in this
thread. This is where the MUAs differ when it comes to the variant Reply
ideas, "Reply to All" is easy, but "Forwarding, Followup" need some work
especially for a group ware concept.
But that's not a problem, because human authors *can* indicate
their preferences to others, within existing protocol framework,
with no meddling from list expanders. Indeed, any such meddling
is more likely to cause problems than to solve them, as has
been the case with some list expansion software which has been
implemented in such a manner as to overwrite the authors'
expressed preferences.
Well, I think it does so in such a way, as I indicated above, to prepare the
minimum requirements, that I don't see it as a problem. I see it as network
technical transport requirement. As long as it does not change the final
user intent of the message, its all "legal" and good in my book.
Anyway, those are my comments.
Sincerely,
Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office