--- /dev/null
+Return-Path: <sojkam1@fel.cvut.cz>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by olra.theworths.org (Postfix) with ESMTP id 6596949F192\r
+ for <notmuch@notmuchmail.org>; Thu, 11 Mar 2010 04:46:11 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -2.252\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=0.347,\r
+ BAYES_00=-2.599] autolearn=unavailable\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+ by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id LY56eQiZBH3O for <notmuch@notmuchmail.org>;\r
+ Thu, 11 Mar 2010 04:46:07 -0800 (PST)\r
+Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])\r
+ by olra.theworths.org (Postfix) with ESMTP id 68E7849F191\r
+ for <notmuch@notmuchmail.org>; Thu, 11 Mar 2010 04:46:07 -0800 (PST)\r
+Received: from localhost (unknown [192.168.200.4])\r
+ by max.feld.cvut.cz (Postfix) with ESMTP id 6358119F35EB;\r
+ Thu, 11 Mar 2010 13:45:48 +0100 (CET)\r
+X-Virus-Scanned: IMAP AMAVIS\r
+Received: from max.feld.cvut.cz ([192.168.200.1])\r
+ by localhost (styx.feld.cvut.cz [192.168.200.4]) (amavisd-new,\r
+ port 10044)\r
+ with ESMTP id oD2Q5jdi-E8Y; Thu, 11 Mar 2010 13:45:46 +0100 (CET)\r
+Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])\r
+ by max.feld.cvut.cz (Postfix) with ESMTP id E433B19F35E7;\r
+ Thu, 11 Mar 2010 13:45:45 +0100 (CET)\r
+Received: from steelpick.localdomain (k335-30.felk.cvut.cz [147.32.86.30])\r
+ (Authenticated sender: sojkam1)\r
+ by imap.feld.cvut.cz (Postfix) with ESMTPSA id AAA97FA003;\r
+ Thu, 11 Mar 2010 13:45:45 +0100 (CET)\r
+Received: from wsh by steelpick.localdomain with local (Exim 4.71)\r
+ (envelope-from <sojkam1@fel.cvut.cz>)\r
+ id 1Nphlp-00071H-HC; Thu, 11 Mar 2010 13:45:45 +0100\r
+From: Michal Sojka <sojkam1@fel.cvut.cz>\r
+To: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>, cworth@cworth.org\r
+In-Reply-To:\r
+ <1268238686-13605-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>\r
+References: <87zl2hic7d.fsf@yoom.home.cworth.org>\r
+ <1268238686-13605-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>\r
+Date: Thu, 11 Mar 2010 13:45:45 +0100\r
+Message-ID: <87r5nrm3gm.fsf@steelpick.localdomain>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Cc: "Aneesh Kumar K.V" <aneesh.kumar@gmail.com>, notmuch@notmuchmail.org\r
+Subject: Re: [notmuch] [PATCH -V3 1/2] notmuch-reply: Add support for\r
+ replying only to sender\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 11 Mar 2010 12:46:11 -0000\r
+\r
+Hi,\r
+\r
+On Wed, 10 Mar 2010, Aneesh Kumar K.V wrote:\r
+> From: Aneesh Kumar K.V <aneesh.kumar@gmail.com>\r
+> \r
+> This patch add --recipient=all|sender option\r
+> \r
+> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>\r
+> ---\r
+> notmuch-client.h | 2 +\r
+> notmuch-reply.c | 55 ++++++++++++++++++++++++++++++++++++++++-------------\r
+> 2 files changed, 43 insertions(+), 14 deletions(-)\r
+> \r
+> diff --git a/notmuch-client.h b/notmuch-client.h\r
+> index c80b39c..26fdb4a 100644\r
+> --- a/notmuch-client.h\r
+> +++ b/notmuch-client.h\r
+> @@ -70,6 +70,8 @@\r
+> #define STRNCMP_LITERAL(var, literal) \\r
+> strncmp ((var), (literal), sizeof (literal) - 1)\r
+> \r
+> +#define NOTMUCH_REPLY_ALL 0x1\r
+> +#define NOTMUCH_REPLY_SENDER_ONLY 0x2\r
+\r
+Why not to define this as enum? When I see a definition like this\r
+it reminds me bit flags which can be used together e.g.\r
+ (NOTMUCH_REPLY_ALL | NOTMUCH_REPLY_SENDER_ONLY).\r
+\r
+This has obviously no sense here.\r
+\r
+> static inline void\r
+> chomp_newline (char *str)\r
+> {\r
+> diff --git a/notmuch-reply.c b/notmuch-reply.c\r
+> index 6c15536..e8a0820 100644\r
+> --- a/notmuch-reply.c\r
+> +++ b/notmuch-reply.c\r
+> @@ -232,20 +232,37 @@ reply_to_header_is_redundant (notmuch_message_t *message)\r
+> static const char *\r
+> add_recipients_from_message (GMimeMessage *reply,\r
+> notmuch_config_t *config,\r
+> - notmuch_message_t *message)\r
+> + notmuch_message_t *message,\r
+> + int reply_options)\r
+> {\r
+> - struct {\r
+> + struct reply_to_map {\r
+> const char *header;\r
+> const char *fallback;\r
+> GMimeRecipientType recipient_type;\r
+> - } reply_to_map[] = {\r
+> + } ;\r
+> + const char *from_addr = NULL;\r
+> + unsigned int i;\r
+> + struct reply_to_map *reply_to_map;\r
+> +\r
+> + struct reply_to_map reply_to_map_all[] = {\r
+> { "reply-to", "from", GMIME_RECIPIENT_TYPE_TO },\r
+> { "to", NULL, GMIME_RECIPIENT_TYPE_TO },\r
+> { "cc", NULL, GMIME_RECIPIENT_TYPE_CC },\r
+> - { "bcc", NULL, GMIME_RECIPIENT_TYPE_BCC }\r
+> + { "bcc", NULL, GMIME_RECIPIENT_TYPE_BCC },\r
+> + { NULL, NULL, 0 }\r
+> };\r
+> - const char *from_addr = NULL;\r
+> - unsigned int i;\r
+> +\r
+> + /* we try from first and then reply-to */\r
+> + struct reply_to_map reply_to_map_sender[] = {\r
+> + { "from", "reply-to", GMIME_RECIPIENT_TYPE_TO },\r
+> + { NULL, NULL, 0 }\r
+> + };\r
+\r
+I'm not sure whether an e-mail without From: is a valid e-mail. If not,\r
+you would never use "reply-to" header. Also, given the link below\r
+(http://www.unicom.com/pw/reply-to-harmful.html), this will not behave\r
+as Carl likes :). Finally, don't forget that reply_to_map can be\r
+modified in add_recipients_from_message().\r
+\r
+I missed your original patch so I implement this for myself in a less\r
+intrusive way (see\r
+id:1267464588-21050-1-git-send-email-sojkam1@fel.cvut.cz). What I like\r
+at your approach is that --recipient option can have several values. I\r
+think it would be useful to have three possible values of this option:\r
+"all", "sender" and something like "reply-to-or-sender". The latter\r
+option would cause using of Reply-to: header event if it is found as\r
+redundant by reply_to_header_is_redundant(). I find this useful for\r
+several private mailing lists I use.\r
+\r
+-Michal\r
+> +\r
+> + if (reply_options == NOTMUCH_REPLY_SENDER_ONLY) {\r
+> + reply_to_map = reply_to_map_sender;\r
+> + } else {\r
+> + reply_to_map = reply_to_map_all;\r
+> + }\r
+> \r
+> /* Some mailing lists munge the Reply-To header despite it being A Bad\r
+> * Thing, see http://www.unicom.com/pw/reply-to-harmful.html\r