Version: (using KDE 4.3.2) Installed from: Compiled From Sources The behavior of the normal Reply option should be configurable. Currently, Reply does a Reply to List (if applicable). Not everybody likes this behavior (see for example bug 109069). Therefore, optionally, Reply should behave like Reply to Author for mailing list messages. The default behavior should be the current behavior.
It was not the wish of any of the reporter/commenters -- the wish was _in case of broken message_ from ML reply to author. " Please change this back so a basic Reply goes to the sender unless overridden by the sender using Reply-To, Mail-Followup-To. "
Please re-read what you have quoted. If Reply behaves like Reply to Author then it will do exactly what you have quoted, i.e. "Reply goes to the sender [as seen in From] unless overridden by the sender [!!!] using Reply-To, Mail-Followup-To.". Note that a mailing list is not "the sender". Thus a Reply-to header set by the mailing list shall be ignored. Only a Reply-to header set by the sender shall be respected.
> If Reply behaves like Reply to Author then it will do exactly what you have > quoted, I know. And much more -- it would reply to author in case of 100% valid posts from ML -- and such behaviour is _unwanted_. IOW the proposal here is stretched too far.
What are "valid posts from ML"?
Properly formed mail -- _with_ reply-to and all.
The presence or absence of a Reply-to header in a mailing list message bears no meaning with respect to the preferred address for replies. Mailing lists adding (or, even worse, overwriting) the Reply-to header with their address are simply following bad practice. Unfortunately, this practice is quite common. Nevertheless it's wrong. Consequentely, your "definition" of "valid posts from ML" makes no sense. If you disagree then please provide proof (an RFC or an equivalently authoritative document) for your understanding (?) that the absence/presence of a Reply-to header indicates some kind of reply-policy. Before replying you might want to read http://mail.python.org/pipermail/mailman-users/2009-October/067391.html and http://turnbull.sk.tsukuba.ac.jp/Blog/Software/ReplyToMungingConsideredEmCarefullyEm
(In reply to comment #0) > The behavior of the normal Reply option should be configurable. Currently, > Reply does a Reply to List (if applicable). Not everybody likes this behavior > (see for example bug 109069). Therefore, optionally, Reply should behave like > Reply to Author for mailing list messages. The default behavior should be the > current behavior. I would really appreciate such a feature as I strongly believe that an application should adjustable to the user's preferences and not the other way round! An alternative would be to ask the user when replying if the message should be send to the ML or the author. Perhaps this decision could be remembered by KMail. Maybe it's even possible to remember different decisions depending on the respective ML.
I agree that the "Reply" action should be configurable. As of KMail 1.13.2/KDE 4.4.2, "Reply" prefers "Reply to List" instead of "Reply to Author". This is a real problem if an e-mail is sent to a mailing list by an author who is not a member of the mailing list. Hitting "Reply" in this situation would trigger a "Reply to List", but the original author would never receive the reply e-mail! I would like to configure KMail so that "Reply" would always prefer "Reply to Author" instead of "Reply to List".
In fact, what I really want is to be able to define the following behavior for "Reply": To: original author CC: all other CC'd recipients BCC: mailing list, unless already in CC If a KMail option would allow me to control the "Reply" behavior to this degree, that would be great!
Re comment #8: KMail's Reply prefers "Reply to List" since ages. Re comment #9: BCC'ing a mailing list doesn't make any sense. For one, it's really bad practice to hide some recipients from the other recipients, in particular, a public recipient like a public mailing list. Secondly, such messages have a high probability of being hold for moderation because messages where the mailing list address is neither in To: nor in CC: are usually spam.
(In reply to comment #10) > Re comment #8: KMail's Reply prefers "Reply to List" since ages. Hence, the request for configurability, so that users are not stuck with KMail's historical preference. I think this is especially helpful for new users coming from a non-Linux background, where reply almost always means "Reply to Author". > > Re comment #9: BCC'ing a mailing list doesn't make any sense. For one, it's > really bad practice to hide some recipients from the other recipients, in > particular, a public recipient like a public mailing list. Secondly, such It makes sense in my use case. The mailing list is an IT request mailing list, whose members are IT responders. Non-members send a message to the IT mailing list, and any of those IT responders can respond to the request, and once they do, they take ownership of the request. The BCC is to let the other IT responders know that I've taken ownership of this ticket, and to limit the discussion henceforth to just the ticket responder, me, and explicit CC'd recipients. > messages have a high probability of being hold for moderation because messages > where the mailing list address is neither in To: nor in CC: are usually spam. The mailing list has a whitelist of all IT responders. Anyway, this was just an example to show what kind of configuration options should be available. I'm sure there are other use cases where you would want to configure BCC recipients. There are various bug reports that want to change the "Reply" behavior, and some requests are probably mutually exclusive. Making "Reply" configurable would answer all those bugs in one fell swoop.
Thank you for your feature request. Kmail1 is currently unmaintained so we are closing all wishes. Please feel free to reopen a feature request for Kmail2 if it has not already been implemented. Thank you for your understanding.
Instead of creating a new feature request, please confirm here if the wishlist is still valid for kmail2.