I like this version (of the whole series) but have two queries. (Note I haven't actually tried it out yet: I have just been reading the code.) > + /* Force recipient type in reply-to-sender mode just in case replying to > + * user's own message finds recipients in Cc/Bcc fields only. > + */ > + if (reply_all) > + recipient_type = reply_to_map[i].recipient_type; > + else > + recipient_type = GMIME_RECIPIENT_TYPE_TO; > + > + addr = add_recipients_for_string (reply, config, recipient_type, > + recipients, add_recipients); > + Why force the recipient type? I do not think notmuch should ever move bcc people onto a different header. I think that will bite someone when it leaks information. I would be happy with either empty headers or with the people staying as bcc. In the cc: case I have no preference (as those addresses are already public) but I would suggest being consistent with bcc so either empty headers or keep them in the cc line. > for (messages = notmuch_query_search_messages (query); > notmuch_messages_valid (messages); > notmuch_messages_move_to_next (messages)) > { [...] > (void)add_recipients_from_message (reply, config, message, reply_all); Since the above logic is applied to each email individually I think working out the recipients when replying to multiple emails (e.g., reply-to-sender on a thread) could be very confusing. Some of the people being replied to will have been senders, some recipients (it is very likely that the thread contains messages we sent), some could even be cc, bcc people. Personally, I would have no idea what to expect from reply-to-sender in this case. (My personal choice would be not to allow notmuch-reply-to-sender if multiple messages are specified. But I can obtain that by unbinding "r" in the notmuch-search-mode-map keymap.) Best wishes Mark