ea/c6fb5e81e79d67c640831090b4fd96e16356f7

   1 Return-Path: <dkg@fifthhorseman.net>\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 5C9B8431FB6\r
   6         for <notmuch@notmuchmail.org>; Thu,  8 Mar 2012 09:16: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: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id l68mOR6wLNd6 for <notmuch@notmuchmail.org>;\r
  16         Thu,  8 Mar 2012 09:16:21 -0800 (PST)\r
  17 Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
  18         by olra.theworths.org (Postfix) with ESMTP id CAD03431FAE\r
  19         for <notmuch@notmuchmail.org>; Thu,  8 Mar 2012 09:16:21 -0800 (PST)\r
  20 Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98])\r
  21         by che.mayfirst.org (Postfix) with ESMTPSA id F005BF970;\r
  22         Thu,  8 Mar 2012 12:16:17 -0500 (EST)\r
  23 Message-ID: <4F58E962.1050403@fifthhorseman.net>\r
  24 Date: Thu, 08 Mar 2012 12:16:18 -0500\r
  25 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  26 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20120125 Icedove/9.0.1\r
  27 MIME-Version: 1.0\r
  28 To: James Vasile <james@hackervisions.org>\r
  29 Subject: Re: a DoS vulnerability associated with conflated Message-IDs?\r
  30 References: <87k42vrqve.fsf@pip.fifthhorseman.net>\r
  31         <87ipif2fdn.fsf@wyzanski.jamesvasile.com>\r
  32 In-Reply-To: <87ipif2fdn.fsf@wyzanski.jamesvasile.com>\r
  33 Content-Type: text/plain; charset=UTF-8; format=flowed\r
  34 Content-Transfer-Encoding: 7bit\r
  35 Cc: notmuch mailing list <notmuch@notmuchmail.org>\r
  36 X-BeenThere: notmuch@notmuchmail.org\r
  37 X-Mailman-Version: 2.1.13\r
  38 Precedence: list\r
  39 Reply-To: notmuch <notmuch@notmuchmail.org>\r
  40 List-Id: "Use and development of the notmuch mail system."\r
  41         <notmuch.notmuchmail.org>\r
  42 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  43         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  44 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  45 List-Post: <mailto:notmuch@notmuchmail.org>\r
  46 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  47 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  48         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  49 X-List-Received-Date: Thu, 08 Mar 2012 17:16:22 -0000\r
  50 \r
  51 On 03/08/2012 12:04 PM, James Vasile wrote:\r
  52 > On Thu, 08 Mar 2012 11:37:09 -0500, Daniel Kahn Gillmor<dkg@fifthhorseman.net>  wrote:\r
  53 >> Any ideas on how to approach this?\r
  54 >\r
  55 > Treat messages with the same ID but different hashes as different?\r
  56 \r
  57 Given that a message hash would include all headers, including Received: \r
  58 and other MTA-added stuff, i think that would remove all relevance of \r
  59 the Message-ID field. in particular, it seems like we would just be \r
  60 identifying messages by their digest.\r
  61 \r
  62 If you're willing to ignore the headers and just look at a digest of the \r
  63 body, that still doesn't provide any help for the common (legitimate) \r
  64 case of a message jointly-delivered to a mailing list and to a specific \r
  65 (already-subscribed) user.\r
  66 \r
  67 That user will get two copies of the message, and since most mailing \r
  68 lists modify the body of the message (usually by adding a footer section \r
  69 with mailing list info) their bodies will also have different digests.\r
  70 \r
  71 So i don't see how to make this suggestion work without giving up on \r
  72 Message-IDs as the identifier entirely (and therefore accepting many \r
  73 more spurious duplicates than users currently need to tolerate).\r
  74 \r
  75 Any other suggestions or ideas?\r
  76 \r
  77         --dkg\r