Will Yardley (12024-12-04): > As noted already, this solves the problem of handling replying to the > list yourself, but not the problem of someone replying to you directly > (unless their mailer honors your M-F-T header). > > I will just make an aside here that I've made another time or two on the > list: this header is a draft that was never made an actual standard, and > is really only either generated by, or honored by, one or two other > clients aside from Mutt (none of them widely used). > > And, the type of people most likely to reply-all and leave you copied > are probably the most likely to not be using those very niche clients.
It is a good thing it never graduated to full standard, because it was bad. The reason it was bad is that it expected users to use a different button or keyboard shortcut whether replying to a mailing-list or a personal mail: it relied on people paying attention. People make mistakes; people make more mistakes when subjected to repetitive tasks. If people make 10% mistakes and the system requires a decision each time, then the system will lead to a 10% error rate. If the system guesses right 90% of the times, then the error rate drops to 1%. Based on my experience, with a significant portion of mail coming from mailing-lists with reply-to set, I estimate that “always reply to all” is right better than 90% of the times. A standard written taking human fallibleness in account could have achieved at least that. Furthermore, the remaining 10% tend to stand out (talking about somebody in the conversation in their back), making the actual error rate even lower. > The war is probably long over, and you're probably right that it's the > least annoying thing, especially for non-technical lists, but seeing > this brought me back to the days when I actually used mailing lists > routinely, and people posting this article was common: > > https://marc.merlins.org/netrants/reply-to-harmful.html > > One thing is that doing this does make it more difficult for someone to > reply to you off-list should they want / need to. I have known of this document for a long time. It exemplifies what is wrong with essays titled “foobar considered harmful” instead of “the pros and cons of foobar”: - They address a completely strawmanized version of foobar, where the implementation makes all the mistakes a good implementation would have avoided. - They ignore the problems people were trying to solve with foobar instead of trying to provide alternate solutions that do solve the same problems almost as well as foobar without its cons. > That's always been a thing. But the issues is that MUAs *must* (in my > understanding) use the Reply-To header over the From header when > replying if Reply-To is set. I have seen people make the same claim, and the short answer is that they can be safely ignored because a “must” in the context of software-user interaction is a nonsense. The longer answer is: There is never a “must” without an “if” and a “want”. You MUST drink water… only IF you WANT to stay alive. Otherwise, you don't need to drink water. Protocol specifications say MUST because there is an implicit “if you want your code to successfully interact with any standard-compliant peer”. If you are Apple or Google or Microsoft and do not care about most peers, then you can ignore MUSTs in protocols you implement and get away with it. But there is no if and want to enforce a must about user interface. (Unless you are about to implement a system of DRM to prevent users from copying copyrighted material and skipping ads, but I am assuming people here are not evil.) What will happen if a MUA does not respect this must about applying reply-to? The software police will raid the developer's home? The software police will raid MY home for installing the soft? (Well, the soft can get kicked out of the app store and demonetized: there is an if and a want in monetizable app stores.) User interface is something between the author of the soft and its users. No standard can have anything to say about it. And it is especially true for Libre Software where I could just patch the soft to behave the way I want it to. Last point: you will probably find that standards that ignore all the obvious thing I stated above and still state MUSTs about user interaction are usually bad standards in other ways and inefficient about a lot of things. Regards, -- Nicolas George
