Re: Automatic suppression of non-duplicate messages
authorEirik Byrkjeflot Anonsen <eirik@eirikba.org>
Mon, 5 Nov 2012 15:22:30 +0000 (16:22 +0100)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:50:19 +0000 (09:50 -0800)
36/40e8f902048d74492cd86d1e26a766f2754977 [new file with mode: 0644]

diff --git a/36/40e8f902048d74492cd86d1e26a766f2754977 b/36/40e8f902048d74492cd86d1e26a766f2754977
new file mode 100644 (file)
index 0000000..32dd800
--- /dev/null
@@ -0,0 +1,78 @@
+Return-Path: <eirik@eirikba.org>\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 10915431FB6\r
+       for <notmuch@notmuchmail.org>; Mon,  5 Nov 2012 07:22:37 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\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 H70w1aOy7vaT for <notmuch@notmuchmail.org>;\r
+       Mon,  5 Nov 2012 07:22:33 -0800 (PST)\r
+Received: from atmail.labs2.com (atmail.labs2.com [93.182.166.49])\r
+       (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id 4D59E431FAE\r
+       for <notmuch@notmuchmail.org>; Mon,  5 Nov 2012 07:22:33 -0800 (PST)\r
+Received: from [178.74.1.248] (helo=star.eba)\r
+       by atmail.labs2.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77)\r
+       (envelope-from <eirik@eirikba.org>) id 1TVOVN-0000xq-7d\r
+       for notmuch@notmuchmail.org; Mon, 05 Nov 2012 16:22:25 +0100\r
+Received: from eirik by star.eba with local (Exim 4.80)\r
+       (envelope-from <eirik@eirikba.org>) id 1TVOVS-0001l0-UG\r
+       for notmuch@notmuchmail.org; Mon, 05 Nov 2012 16:22:30 +0100\r
+From: Eirik Byrkjeflot Anonsen <eirik@eirikba.org>\r
+To: notmuch@notmuchmail.org\r
+Subject: Re: Automatic suppression of non-duplicate messages\r
+References: <87mwyz3s9d.fsf@star.eba> <87390qxvb4.fsf@maritornes.cs.unb.ca>\r
+       <87390pf14v.fsf@nikula.org>\r
+Date: Mon, 05 Nov 2012 16:22:30 +0100\r
+In-Reply-To: <87390pf14v.fsf@nikula.org> (Jani Nikula's message of "Mon, 05\r
+       Nov 2012 00:34:40 +0200")\r
+Message-ID: <87sj8ot6q1.fsf@star.eba>\r
+User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+X-ACL-Warn: Authenticated as:  Sent as: eirik@eirikba.org\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: Mon, 05 Nov 2012 15:22:37 -0000\r
+\r
+Jani Nikula <jani@nikula.org> writes:\r
+\r
+> On Sat, 03 Nov 2012, David Bremner <david@tethera.net> wrote:\r
+>> Offhand I'm not sure of a good method of automatically deciding what is\r
+>> the same message (with e.g. headers and footer text added by a mailing\r
+>> list).\r
+>\r
+> Assuming there was good method, what would you do with two different\r
+> messages that have the same message id? That is the unique id we use to\r
+> identify messages (which should be fine per RFC 5322 and its\r
+> predecessors; we're talking about messages from broken systems here).\r
+\r
+We're also talking about data from "untrusted" sources.  Assuming that\r
+such data is always non-broken seems overly optimistic.  (See\r
+e.g. http://cr.yp.to/immhf/thread.html, the section "Security and\r
+reliability issues" for one view on the matter.)\r
+\r
+In fact, I'd say that it should be a design goal for any mail client to\r
+deal with as much invalid input as possible.  Show big, fat warning\r
+messages if you want to, but don't just drop the message and pretend it\r
+does not exist.\r
+\r
+eirik\r