Bug 109069

I just noticed an additional problem in relation to this: If the mailing list has two alternative addresses and the original poster posted to the first address while the List-Post header contains the second, then a reply goes to both addresses, thus leading to a duplicate post.

I agree 100% with the reporter of this problem.

 'Reply' should mean reply to sender.
 'Reply all' should mean reply to all.

The behavior of kmail is frustrating. This is a daily problem. When i hit reply or reply all, kmail mess up the list of recipients, and i usually have to edit the list manually before i send replies.

 When i hit 'reply all', all the recipients are put in the cc-field of my reply. Kmail finds an alias for the mailling list and put it in the 'To' field of the reply. This alias might not be expected to be used by human beings. In this way kmail suggest to send 2 copies to the mailling-list. An alias for the maillinglist is put in the 'To' field, and the address of the mailling list is put in the cc-list.
 If i wish to send a personal reply just to the sender, then i hit the reply function in Kmail. Then Kmail put an alias for the mailling list in the 'To' field of my reply. This has to be edited manually. If you are in a hurry when you reply to an message, you will forget to edit the 'To' field. And your personal message to the sender is sent to the mailling list instead.

Here is an example. I tried to send a personal reply to the sender of this email, and the message was sent to an alias of the list instead:

Return-Path: <noc-bulletins-bounces+amuns=domainname.com@lister.domainname.com>
 Received: from tor.domainname.com (virus-out-st.domain.com [193.212.240.200])
        by mail19.domain.no (8.12.11/8.12.11) with ESMTP id jAP6QWjU024536
        for <amuns@9.domain.com>; Fri, 25 Nov 2005 07:26:46 +0100 (CET)
 Received: from mail27.e.domain.no ([193.213.115.27] [193.213.115.27]) by scan.domainname.com with ESMTP for amuns@9.domain.com; Fri, 25 Nov 2005 07:26:45 +0100
 Received: (from mailuser@localhost)
        by mail27.domain.no (8.13.5/8.13.5) id jAP6QjNl015332
        for amuns@9.domain.com; Fri, 25 Nov 2005 07:26:45 +0100 (CET)
 Received: from bruinen.domain.no (bruinen.domain.no [193.213.112.59])
        by mail27.domain.no (8.13.5/8.13.5) with ESMTP id jAP6Qhqk015277
        for <amuns@domain.com>; Fri, 25 Nov 2005 07:26:45 +0100 (CET)
 Received: by bruinen.domain.no (Postfix)
        id AC841148D7; Fri, 25 Nov 2005 07:26:43 +0100 (CET)
 Delivered-To: amuns@domainname.com
 Received: from anduin.domain.no (anduin.domain.no [193.213.112.61])
        by bruinen.domain.no (Postfix) with ESMTP id 91FD6148BF
        for <amuns@domainname.com>; Fri, 25 Nov 2005 07:26:43 +0100 (CET)
 Received: from nsmail4.domain.no (localhost [127.0.0.1])
        by anduin.domain.no (Postfix) with ESMTP id 7F13713653
        for <amuns@domainname.com>; Fri, 25 Nov 2005 07:26:43 +0100 (CET)
 X-Original-To: noc-bulletins@lister.domainname.com
 Delivered-To: noc-bulletins@anduin.domain.no
 Received: from bruinen.domain.no (bruinen.domain.no [193.213.112.59])
        by anduin.domain.no (Postfix) with ESMTP id 5F9C712C83
        for <noc-bulletins@lister.domainname.com>;
        Fri, 25 Nov 2005 07:25:43 +0100 (CET)
 Received: by bruinen.domain.no (Postfix)
        id 18B98148D5; Fri, 25 Nov 2005 07:25:43 +0100 (CET)
 Delivered-To: noc-bulletins@domainname.com
 Received: from langwell.domain.no (langwell.domain.no [193.213.112.60])
        by bruinen.domain.no (Postfix) with ESMTP id E5667148BF
        for <noc-bulletins@domainname.com>; Fri, 25 Nov 2005 07:25:42 +0100 (CET)
 Received: from localhost (localhost [127.0.0.1])
        by langwell.domain.no (Postfix) with ESMTP id 8C2EB186DC
        for <noc-bulletins@domainname.com>; Fri, 25 Nov 2005 07:25:42 +0100 (CET)
 Received: from mail48.e.domain.no (mail48.e.domain.no [193.213.115.48])
        by langwell.domain.no (Postfix) with ESMTP id 59941186C3
        for <noc-bulletins@domainname.com>; Fri, 25 Nov 2005 07:25:41 +0100 (CET)
 Received: from gruZom ([193.214.103.52])
        by mail48.domain.no (8.13.5/8.13.5) with ESMTP id jAP6PKGo017212
        for <noc-bulletins@domainname.com>; Fri, 25 Nov 2005 07:25:41 +0100 (CET)
 Message-Id: <200511250625.jAP6PKGo017212@mail48.domain.no>
 From: "Kai Johansen" <kaijoha@domainname.com>
 To: <noc-bulletins@domainname.com>
 Date: Fri, 25 Nov 2005 07:25:22 +0100
 MIME-Version: 1.0
 X-Mailer: Microsoft Office Outlook, Build 11.0.5510
 Thread-Index: AcXxiQNuzURqWOH6TgGKEU0Da7S9cg==
 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
 Cc: 
 Subject: [ NOC] =?iso-8859-1?q?T=2Enet_Feil=2C_ADSL_-_=C5lesund_ti?=
        =?iso-8859-1?q?511210a080?=
 X-BeenThere: noc-bulletins@lister.domainname.com
 X-Mailman-Version: 2.1.5
 Precedence: list
 List-Id: Driftsmeldinger for IP-Nett
        <noc-bulletins.lister.domainname.com>
 List-Unsubscribe: <https://lister.domainname.com/mailman/listinfo/noc-bulletins>, 
        <mailto:noc-bulletins-request@lister.domainname.com?subject=unsubscribe>
 List-Archive: <https://lister.domainname.com/mailman/private/noc-bulletins>
 List-Post: <mailto:noc-bulletins@lister.domainname.com>
 List-Help: <mailto:noc-bulletins-request@lister.domainname.com?subject=help>
 List-Subscribe: <https://lister.domainname.com/mailman/listinfo/noc-bulletins>,
        <mailto:noc-bulletins-request@lister.domainname.com?subject=subscribe>
 Content-Type: multipart/mixed;
  boundary="===============0907855026=="
 Sender: noc-bulletins-bounces+amuns=domainname.com@lister.domainname.com
 Errors-To: noc-bulletins-bounces+amuns=domainname.com@lister.domainname.com
 X-Length: 7309
 Status: R
 X-Status: NC
 X-KMail-EncryptionState: 
 X-KMail-SignatureState: 
 X-KMail-MDN-Sent: 
 X-UID: 4825

*** Bug 129934 has been marked as a duplicate of this bug. ***

After a discussion with the current kmail maintainer, it was decided that the current behavior will not be modified as there are also mails from mailing lists, which do not correctly specify Reply-To headers. Therefore the auto-detection.
If you want to reply to the author, please use the Reply-To-Author action.

This is an absurd:
a) instead of KMail doing all dirty work, now all user have to do it, to cover limitation of KMail
b) in case of broken ML I could write to admin of such ML. But using KMail would lead to no benefit, since even after fixing problem with ML KMail would be broken

Keeping broken behaviour didn't work and won't work for any app. KMail now promote broken ML, because broken, correct -- for KMail it does not matter, it always works buggy.

And the logic is also flawed. 

> If you want to reply to the author, please use the Reply-To-Author action.

Why we don't hear "If you want to reply to broken (only!) ML, please use the reply-to-ML action"? It make sense -- in case of wrong mail explicit action is required, but not in case of well formed mail.

Do we really have to follow the path of MSIE? I don't think so.

Please reopen this report -- KMail should behave properly for proper mails, it cannot be simpler rule.

I agree that this is absurd.

When any email-user is using the reply action, they think "reply" means "reply to sender".

I find it not logic that this auto-detection should apply when you do a standard reply.  Wouldn't it be more logic, to let this auto-detection just apply to "Reply to Mailling-list"?

As i understand, the situation is like this:
1: There is someone, somewhere, that has experienced a mailing list that behave not correct.
2: This someone somewhere, uses the email-client in an odd way, where it fits well with that "reply" means reply to mailing-list.

To satisfy this someone, the workaround is that the developers of Kmail make kmail to work not correct. And the rest of the kmail users are suffering a lot because of this. These users are getting a lot of problems with there coworkers, because they are broadcasting emails to mailing-lists, instead of sending messages to author. And the users are getting problems with friends, and all kind of organisations and people around them, because personal messages to the author, are broadcasted to the mailing-lists.

Hi!

It is wonderful that you protested against this behavior of Kmail.

What if you leave some votes for this bug as well?

For a long time, i have had the feeling that the maintainers of Kmail, are just taking care of there own special needs of an email-client.  I guess Kmail is fitting well in there environment:  It fits well with the servers they are using, and with the usage that they have. The features of Kmail is not fitting to general users. It seems like the maintainers have this arrogant attitude: This is fitting well to me or us, so the software should work like this. The rest of the world has to accept it. I am really scared, when i think about what kind of personalities these maintainers might have.

AS

On Monday 12 October 2009, Maciej Pilichowski wrote:
> https://bugs.kde.org/show_bug.cgi?id=109069
> 
> 
> Maciej Pilichowski <bluedzins@wp.pl> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |bluedzins@wp.pl
> 
> 
> 
> 
> --- Comment #5 from Maciej Pilichowski <bluedzins wp pl>  2009-10-12 07:41:50 ---
> This is an absurd:
> a) instead of KMail doing all dirty work, now all user have to do it, to cover
> limitation of KMail
> b) in case of broken ML I could write to admin of such ML. But using KMail
> would lead to no benefit, since even after fixing problem with ML KMail would
> be broken
> 
> Keeping broken behaviour didn't work and won't work for any app. KMail now
> promote broken ML, because broken, correct -- for KMail it does not matter, it
> always works buggy.
> 
> And the logic is also flawed. 
> 
> > If you want to reply to the author, please use the Reply-To-Author action.
> 
> Why we don't hear "If you want to reply to broken (only!) ML, please use the
> reply-to-ML action"? It make sense -- in case of wrong mail explicit action is
> required, but not in case of well formed mail.
> 
> Do we really have to follow the path of MSIE? I don't think so.
> 
> Please reopen this report -- KMail should behave properly for proper mails, it
> cannot be simpler rule.
>

This was not decided due to the maintainer(s) personal feelings, but in accordance with the RFC.

For the full story please see:
http://lists.kde.org/?l=kde-pim&m=125425300808560&w=2

And that RFC has a number? I followed the whole discussion and quote or number never appears.

RFC2822 section 3.6.2 (http://tools.ietf.org/html/rfc2822#section-3.6.2)

Thank you. This RFC is quite clear:

"In the absence of the "Reply-To:" field,
   replies SHOULD by default be sent to the mailbox(es) specified in the
   "From:" field unless otherwise specified by the person composing the
   reply."

So KMail as well should use "from".

(In reply to comment #11)
> Thank you. This RFC is quite clear:
> 
> "In the absence of the "Reply-To:" field,
>    replies SHOULD by default be sent to the mailbox(es) specified in the
>    "From:" field unless otherwise specified by the person composing the
>    reply."
> 
> So KMail as well should use "from".

*IF* the reply-to header is missing.

Of course. This is the report about the case WHEN the reply-to is missing. So still I don't get how it is a wontfix.

Ah sorry, I missed the bit about the missing Reply-To header.

But I still think that KMail does the right thing. 99% of replies to mails from lists are meant for the list and the RFC said should not must so better to cater for the 99% case then for the 1% case since there are an easy to use and find function for replying to the author.

Torgny, it is in reverse.
a) RFC does not state KMail "should", it shouts "SHOULD", so KMail better has some _really_ good reason to ignore this 
b) in 99% cases KMail violates the fields given in favor of 1% cases
c) and now simple use case -- what is worse:

1) send a public message to single person
2) send a private message to public (the world)

? 

Why all KMail users should be put at risk for some lazy admin (I assume your answer is (2) ).

*** Bug 177716 has been marked as a duplicate of this bug. ***

(In reply to comment #15)
> Torgny, it is in reverse.
> a) RFC does not state KMail "should", it shouts "SHOULD", so KMail better has
> some _really_ good reason to ignore this

KMail does have a really good reason to behave as it does:
More consistent, reliable and predictable behavior.

Whether a mailing list message has the Reply-to header set (by the mailing list) or not is totally opaque to the user (unless he checks the headers).

Let's assume KMail would behave exactly as stated in the RFC (see Comment #11). In this case, if the user replied to a mailing list message (using Reply) the reply would be addressed to
 a) the mailing list if the mailing list has set the Reply-to header
 b) the From address if the mailing list did not set the Reply-to header
This behavior is inconsistent (from the user's point of view) and totally unpredictable (unless the user looks for the Reply-to header before each reply). To get predictable behavior the user would have to use either Reply to List or Reply to Author depending on what he wants to do. The normal Reply would be useless for replies to mailing list messages due to it "erratic" behavior.

KMail's current behavior makes the behavior of Reply more consistent, reliable and predictable because if the user replies to a mailing list message (using Reply) the reply would be addressed to
 a) the mailing list if the mailing list has set the Reply-to header,
 b) the mailing list if the mailing list did not set the Reply-to header, but it did set the standard List-Post header (see http://tools.ietf.org/html/rfc2369#section-3.4),
 c) the From address if the mailing list did set neither the Reply-to header nor the List-Post header


Note that the real problem is all those mailing lists that set a Reply-to header. As soon as mailing lists stop doing this we will change KMail's behavior. Until then KMail's behavior will not change.


> b) in 99% cases KMail violates the fields given in favor of 1% cases

Is this your personal experience? When I reply to a mailing list message then I want the reply to go to the mailing list in 99.9 % of the cases.


> c) and now simple use case -- what is worse:
> 
> 1) send a public message to single person
> 2) send a private message to public (the world)
> 
> ?

Yes, this risk does exist. But it's not caused by KMail's behavior, but by all those mailing lists setting the Reply-to header.

I have filed a feature request (bug 211014) for making KMail's Reply behavior configurable. Please vote for this feature so that we can see whether it's worth implementing it.

Ingo, about 99% -- I mean most of the mail I have are correct one. 

Is this ok for ML not to set up reply-to?