On Wed, 26 Nov 2003, Dave G wrote:
> "Just to add an authoritative answer here. Mucking up the reply-to
> header is simply wrong. I don't really care what arguments you come up
> with..."
> This seems to describe the tone of the debate. The idea of an
> authority on a matter that is incapable of considering alternate
> viewpoints seems oxymoronic to me.
It was an authoritative answer in the sense that I'm the guy who would
have to be convinced to make this change and I really don't see this
happening. I do understand all the arguments and I have duly considered
them. Believe it or not, but I actually know a little bit about this
stuff. Here are just a small set of reasons to keep things the way they
are:
1. Default to safety!
If I think I am sending a private email and unknown to me it ends up
going to a public mailing list with hundreds of subscribers and
archives all over the Net, there is no way to undo the security
breach this could cause if I inadvertently put some non-public
information in my reply. If the odd message intended to be public
instead ends up private, this is a small price to pay and something
that can easily be remedied by either the sender or the receiver
after the fact.
2. People often want personal responses
- There are many interfaces to the PHP mailing lists and people do
not need to be subscribed to send a question to one of the lists.
If you are not subscribed to the list, it is very nice to get a
private reply to your question and all other replies in the thread
which is exactly what happens when people properly do a reply-all
- Sometimes the mailing lists are slow to propogate messages. By
also sending a private reply the person asking the question gets a
much quicker response.
And no, the "but I don't want two copies" isn't much of an argument.
Any decent mail system should be able to weed out duplicate
messages. The following procmail rule does it, for example:
# Remove duplicates
:0 Whc: msgid.lock
| formail -D 16384 msgid.cache
:0 a:
duplicates
I'm saving a copy in duplicates, just in case here, but you could
also just trash the copy.
And yes, I realize not everyone has the ability to install their own
procmail rules but again, this is a technical forum with a lot of
people who can do this stuff. Dumbing down and crippling the list
to cater to the less fortunate at the expense of the rest of us is
not going to happen. This might even help push others to use more
advanced mail clients and mail servers.
3. Avoiding misconfigured mailers from trashing our lists
I often see vacation messages and other crap on lists that have the
reply-to set to point back to the list. This has also been known
to cause mail loops with dozens of copies of this stuff getting sent
to every subscriber of the list.
4. Quality over quantity
I personally don't think it would be a bad thing if we saw less
replies go directly to the mailing list. Especially for
high-volume php-general where there are a lot of newbie questions.
If you know something has been answered dozens of times publically,
a quick private response is fine. And if the person asking the
question would then optionally post a summary later on our signal
to noise ratio would go up considerably.
5. Deleting existing reply-to headers?
Most people would agree that if a message is sent to the list with
an existing reply-to header, then it shouldn't be deleted. Because
if you delete it, there may be absolutely no way to reach the
original author. The purpose of the reply-to header is to allow you
to specify where you want replies to your message to go. You could
even send it from someone else's account and set the reply-to to
your address and should should reasonably expect replies to end up
at the address you specify. Now, if that holds, then only setting
the reply-to on messages that don't already have a reply-to, which
some mailing list software does, means you now lose consistency.
Sometimes a reply will go to the list, sometimes it won't.
I could rhyme off another 5-10 reasons here, but even stopping after #1 in
the above list is more than enough for me to justify the current list
configuration.
-Rasmus
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
