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