a6/6f8036910874695da94363636a4c8e9453d54a

   1 Return-Path: <m.walters@qmul.ac.uk>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 1056E4143A3\r
   6         for <notmuch@notmuchmail.org>; Sun,  8 Jan 2012 15:23:22 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -1.098\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-1.098 tagged_above=-999 required=5\r
  12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
  13         NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3] autolearn=disabled\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id OaO1ZIfvtn5w for <notmuch@notmuchmail.org>;\r
  17         Sun,  8 Jan 2012 15:23:21 -0800 (PST)\r
  18 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
  19         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 69CAE4143A1\r
  22         for <notmuch@notmuchmail.org>; Sun,  8 Jan 2012 15:23:21 -0800 (PST)\r
  23 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
  24         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
  25         (envelope-from <m.walters@qmul.ac.uk>)\r
  26         id 1Rk256-0004IS-KP; Sun, 08 Jan 2012 23:23:17 +0000\r
  27 Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223]\r
  28         helo=localhost)\r
  29         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69)\r
  30         (envelope-from <m.walters@qmul.ac.uk>)\r
  31         id 1Rk256-00041r-An; Sun, 08 Jan 2012 23:23:16 +0000\r
  32 From: Mark Walters <markwalters1009@gmail.com>\r
  33 To: Jani Nikula <jani@nikula.org>, notmuch@notmuchmail.org\r
  34 Subject: Re: [PATCH v2 3/6] cli: add support for replying just to the sender\r
  35         in "notmuch reply"\r
  36 In-Reply-To:\r
  37  <6e37e058190d7c06519de3e67569fbee0be45461.1326058946.git.jani@nikula.org>\r
  38 References: <cover.1326058946.git.jani@nikula.org>\r
  39         <6e37e058190d7c06519de3e67569fbee0be45461.1326058946.git.jani@nikula.org>\r
  40 User-Agent: Notmuch/0.10.2+183~g99cd7be (http://notmuchmail.org) Emacs/23.3.1\r
  41         (i486-pc-linux-gnu)\r
  42 Date: Sun, 08 Jan 2012 23:23:15 +0000\r
  43 Message-ID: <877h11eq3g.fsf@qmul.ac.uk>\r
  44 MIME-Version: 1.0\r
  45 Content-Type: text/plain; charset=us-ascii\r
  46 X-Sender-Host-Address: 94.192.233.223\r
  47 X-QM-SPAM-Info: Sender has good ham record.  :)\r
  48 X-QM-Body-MD5: 2f85d17497675942f7020f78d15a5c6d (of first 20000 bytes)\r
  49 X-SpamAssassin-Score: -1.7\r
  50 X-SpamAssassin-SpamBar: -\r
  51 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
  52         determine if it is\r
  53         spam. We require at least 5.0 points to mark a message as spam.\r
  54         This message scored -1.7 points.\r
  55         Summary of the scoring: \r
  56         * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\r
  57         *      medium trust\r
  58         *      [138.37.6.40 listed in list.dnswl.org]\r
  59         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
  60         provider *      (markwalters1009[at]gmail.com)\r
  61         * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay\r
  62         *      domain\r
  63         *  0.6 AWL AWL: From: address is in the auto white-list\r
  64 X-QM-Scan-Virus: ClamAV says the message is clean\r
  65 X-BeenThere: notmuch@notmuchmail.org\r
  66 X-Mailman-Version: 2.1.13\r
  67 Precedence: list\r
  68 List-Id: "Use and development of the notmuch mail system."\r
  69         <notmuch.notmuchmail.org>\r
  70 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  71         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  72 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  73 List-Post: <mailto:notmuch@notmuchmail.org>\r
  74 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  75 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  76         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  77 X-List-Received-Date: Sun, 08 Jan 2012 23:23:22 -0000\r
  78 \r
  79 \r
  80 I like this version (of the whole series) but have two queries. (Note I\r
  81 haven't actually tried it out yet: I have just been reading the code.)\r
  82 \r
  83 > +     /* Force recipient type in reply-to-sender mode just in case replying to\r
  84 > +      * user's own message finds recipients in Cc/Bcc fields only.\r
  85 > +      */\r
  86 > +     if (reply_all)\r
  87 > +         recipient_type = reply_to_map[i].recipient_type;\r
  88 > +     else\r
  89 > +         recipient_type = GMIME_RECIPIENT_TYPE_TO;\r
  90 > +\r
  91 > +     addr = add_recipients_for_string (reply, config, recipient_type,\r
  92 > +                                       recipients, add_recipients);\r
  93 > +\r
  94 \r
  95 Why force the recipient type?  I do not think notmuch should ever move\r
  96 bcc people onto a different header. I think that will bite someone when\r
  97 it leaks information.\r
  98 \r
  99 I would be happy with either empty headers or with the people staying\r
 100 as bcc.\r
 101 \r
 102 In the cc: case I have no preference (as those addresses are already\r
 103 public) but I would suggest being consistent with bcc so either empty\r
 104 headers or keep them in the cc line.\r
 105 \r
 106 >     for (messages = notmuch_query_search_messages (query);\r
 107 >         notmuch_messages_valid (messages);\r
 108 >         notmuch_messages_move_to_next (messages))\r
 109 >     {\r
 110 [...]\r
 111 >       (void)add_recipients_from_message (reply, config, message, reply_all);\r
 112 \r
 113 Since the above logic is applied to each email individually I think\r
 114 working out the recipients when replying to multiple emails (e.g.,\r
 115 reply-to-sender on a thread) could be very confusing. Some of the people\r
 116 being replied to will have been senders, some recipients (it is very\r
 117 likely that the thread contains messages we sent), some could even be\r
 118 cc, bcc people. Personally, I would have no idea what to expect from\r
 119 reply-to-sender in this case.\r
 120 \r
 121 (My personal choice would be not to allow notmuch-reply-to-sender if\r
 122 multiple messages are specified. But I can obtain that by unbinding "r"\r
 123 in the notmuch-search-mode-map keymap.)\r
 124 \r
 125 Best wishes\r
 126 \r
 127 Mark\r
 128 \r