From: Peter Wang Date: Wed, 6 Mar 2013 11:08:49 +0000 (+1100) Subject: Re: [RFC PATCH 3/3] cli: support Mail-Followup-To: in notmuch reply X-Git-Url: http://git.tremily.us/gitweb.cgi?a=commitdiff_plain;h=c893648ef77b8a9da10a5e34632209431eddc4e7;p=notmuch-archives.git Re: [RFC PATCH 3/3] cli: support Mail-Followup-To: in notmuch reply --- diff --git a/a6/46052c0b5b0e5813769a58510a2cd6bc2858d5 b/a6/46052c0b5b0e5813769a58510a2cd6bc2858d5 new file mode 100644 index 000000000..6747d0ed9 --- /dev/null +++ b/a6/46052c0b5b0e5813769a58510a2cd6bc2858d5 @@ -0,0 +1,91 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 6E003431FAF + for ; Wed, 6 Mar 2013 03:09:08 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0.602 +X-Spam-Level: +X-Spam-Status: No, score=0.602 tagged_above=-999 required=5 + tests=[DKIM_ADSP_CUSTOM_MED=0.001, DKIM_SIGNED=0.1, + FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_LOW=-0.7] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id DLEd1qZSJrvi for ; + Wed, 6 Mar 2013 03:08:58 -0800 (PST) +Received: from mail-ia0-f174.google.com (mail-ia0-f174.google.com + [209.85.210.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id E15A5431FAE + for ; Wed, 6 Mar 2013 03:08:57 -0800 (PST) +Received: by mail-ia0-f174.google.com with SMTP id u20so7148990iag.5 + for ; Wed, 06 Mar 2013 03:08:56 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=x-received:date:message-id:from:to:cc:subject:in-reply-to + :references:mime-version:content-type:content-disposition + :content-transfer-encoding; + bh=6Hltio5o8RaabGKtmD/OHBurA5A2U2XNCVaKZ06EdRY=; + b=kUiSS+V84f6N01t11ckF5avHoIz7OfwWLkB9RPD+f9fXA3CRYr9m1jRtyEhiCf8hgK + 5IzRIKgmXrcBmr80VjFCy9ysuZ+RS5Y3u7wxa8+HOcC1PJF+3rC/ydvbRdTji0MiG1wK + /mFva7MtA1IvRqf5kDFuFlBs6G5/ny0hR9i2eq1PqG0f40PNsHzegNFtCFdPMnMD5V2T + pLlJhGkRnec2Mc46adFieHX7gVwatAchIauWa0scgDepf808OIic0RGcXvFHhfZ2M/TJ + pcdDkBOdtcyIYxGpcWrGsmUhzzNjV6W1pPW049ZW+jU9ytV1h1uLbuIFYJivgHy94RlM + yHEw== +X-Received: by 10.50.154.129 with SMTP id vo1mr10127419igb.93.1362568136411; + Wed, 06 Mar 2013 03:08:56 -0800 (PST) +Received: from localhost (215.42.233.220.static.exetel.com.au. + [220.233.42.215]) + by mx.google.com with ESMTPS id uq1sm21505480igc.5.2013.03.06.03.08.53 + (version=TLSv1.2 cipher=RC4-SHA bits=128/128); + Wed, 06 Mar 2013 03:08:55 -0800 (PST) +Date: Wed, 6 Mar 2013 22:08:49 +1100 +Message-ID: <20130306220849.GB5730@hili.localdomain> +From: Peter Wang +To: Jani Nikula +Subject: Re: [RFC PATCH 3/3] cli: support Mail-Followup-To: in notmuch reply +In-Reply-To: <871ubwdcy7.fsf@nikula.org> +References: + <5eaa3acc22ee5513bdce5ab931b7a79ade880e06.1362254104.git.jani@nikula.org> + + <20130303120745.GA4884@hili.localdomain> <871ubwdcy7.fsf@nikula.org> +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Disposition: inline +Content-Transfer-Encoding: 8bit +Cc: notmuch@notmuchmail.org +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Wed, 06 Mar 2013 11:09:08 -0000 + +On Sun, 03 Mar 2013 11:56:00 +0200, Jani Nikula wrote: +> I have added the reply.honor_followup_to configuration because, although +> widely used, it's not a standard, and therefore some people might not +> like to respect that. Although I'd argue if the sender of the message +> has added that header, it's the sender's wish it should be respected. +> +> If people think our reply-all should always and unconditionally respect +> Mail-Followup-To if it's present, I'd be happy to throw out the config +> option. It's ugly. + +How about making it it optional on the command-line rather than through +configuration? Then you don't lose the functionality where you can +initiate a reply to all visible From/To/Cc addresses (ready for pruning), +regardless of the value of some header you probably don't even see, even +if typically you *do* want to respect that header. + +(Bringing us back to the three reply functions.) + +Peter