89/33b67561ef0d108be799630bf2c840b123f6a4

   1 Return-Path: <amdragon@gmail.com>\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 22D7E431FB6\r
   6         for <notmuch@notmuchmail.org>; Sun, 20 Mar 2011 11:01:24 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.699\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
  13         RCVD_IN_DNSWL_LOW=-0.7] 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 lyNiaLyQFfvu for <notmuch@notmuchmail.org>;\r
  17         Sun, 20 Mar 2011 11:01:23 -0700 (PDT)\r
  18 Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com\r
  19         [209.85.216.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
  20         (No client certificate requested)\r
  21         by olra.theworths.org (Postfix) with ESMTPS id 59C5A431FB5\r
  22         for <notmuch@notmuchmail.org>; Sun, 20 Mar 2011 11:01:23 -0700 (PDT)\r
  23 Received: by qwc9 with SMTP id 9so4052026qwc.26\r
  24         for <notmuch@notmuchmail.org>; Sun, 20 Mar 2011 11:01:20 -0700 (PDT)\r
  25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  26         h=domainkey-signature:mime-version:sender:in-reply-to:references:date\r
  27         :x-google-sender-auth:message-id:subject:from:to:cc:content-type\r
  28         :content-transfer-encoding;\r
  29         bh=XIO3zVbXnyrFGbwhzMfj5yvBZQmTY4hDJtiFy1sLT8A=;\r
  30         b=rHzZcFUO8GwUZEArtMRJnybEoEmDZ7bqtO8f9cT5+VJDZ0iQr2wy2mVePLta2uxv/R\r
  31         azJArAlYGe9D0/iT0T0lZc3CwXOGUm1b0iH0SAqzqc2FJh19pJzwX7q06HQO3V+ogFMB\r
  32         ll/QOyOmcQwtHbTsjU9Pm8djDunD4XJoeM4ks=\r
  33 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  34         h=mime-version:sender:in-reply-to:references:date\r
  35         :x-google-sender-auth:message-id:subject:from:to:cc:content-type\r
  36         :content-transfer-encoding;\r
  37         b=b+0RaCY5K4sr2u/DShBltrGncoflsAHOVCfikDpepmB2LG0G6cLVpDtDLw/R9TJ/UM\r
  38         IM9i1lWRUwiHV9Xvln33/sURgAbtqw7Hnj4vP2TY7V4/B4m9eX36Z6l8XfDagqBOat77\r
  39         jG3S8cwFYLRGzu6S/12dTuTGMtZQKWWF4EgP4=\r
  40 MIME-Version: 1.0\r
  41 Received: by 10.224.130.14 with SMTP id q14mr2603451qas.250.1300644080875;\r
  42         Sun, 20 Mar 2011 11:01:20 -0700 (PDT)\r
  43 Sender: amdragon@gmail.com\r
  44 Received: by 10.229.30.68 with HTTP; Sun, 20 Mar 2011 11:01:20 -0700 (PDT)\r
  45 In-Reply-To: <AANLkTim=-dYoR+LbV1UtH8f-Of-M_2AuEJYrGt-NeY4f@mail.gmail.com>\r
  46 References: <AANLkTim=-dYoR+LbV1UtH8f-Of-M_2AuEJYrGt-NeY4f@mail.gmail.com>\r
  47 Date: Sun, 20 Mar 2011 14:01:20 -0400\r
  48 X-Google-Sender-Auth: QVGx3v5aLkL__-LsApwnjQB9t04\r
  49 Message-ID: <AANLkTi=C7mK=RiUsoGcv1=ruyY=yBvsZLfDSeRHW_P87@mail.gmail.com>\r
  50 Subject: Re: RFC: notmuch powered (personal) (end-to-end) e-mail system\r
  51 From: Austin Clements <amdragon@mit.edu>\r
  52 To: Ciprian Dorin Craciun <ciprian.craciun@gmail.com>\r
  53 Content-Type: text/plain; charset=ISO-8859-1\r
  54 Content-Transfer-Encoding: quoted-printable\r
  55 Cc: notmuch@notmuchmail.org\r
  56 X-BeenThere: notmuch@notmuchmail.org\r
  57 X-Mailman-Version: 2.1.13\r
  58 Precedence: list\r
  59 List-Id: "Use and development of the notmuch mail system."\r
  60         <notmuch.notmuchmail.org>\r
  61 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  62         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  63 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  64 List-Post: <mailto:notmuch@notmuchmail.org>\r
  65 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  66 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  67         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  68 X-List-Received-Date: Sun, 20 Mar 2011 18:01:24 -0000\r
  69 \r
  70 Much of the beauty of notmuch is how few assumptions it makes about\r
  71 your mail system.  It plays well with others.  For example, one deep\r
  72 insight of notmuch is that it *doesn't* require a custom mail store,\r
  73 even though a more obvious design might; in fact, it doesn't even\r
  74 require Maildir.\r
  75 \r
  76 That said, I think I can see where you're coming from and I also think\r
  77 you're targeting some of the deficiencies of notmuch, but I also think\r
  78 you're overengineering the solution.  As a result of notmuch's\r
  79 simplicity, a fully working mail setup requires a lot of moving parts\r
  80 besides notmuch and it can take a while for a new user to set all that\r
  81 up, especially if they're migrating wholesale from some external mail\r
  82 setup.\r
  83 \r
  84 On Sun, Mar 20, 2011 at 10:07 AM, Ciprian Dorin Craciun\r
  85 <ciprian.craciun@gmail.com> wrote:\r
  86 > =A0 =A0As such I'm thinking on implementing a custom end-to-end email\r
  87 > system and I would like to hear your feedback before embarking on such\r
  88 > a task.\r
  89 >\r
  90 > =A0 =A0I'm targeting the following features:\r
  91 > =A0 =A0* (inbound) SMTP integration, thus once an email is received it is\r
  92 > automatically pushed through the system; (I'm primarily targeting\r
  93 > those users that afford to run their own SMTP server; but the solution\r
  94 > could still be adapted for those that only want the other features;)\r
  95 \r
  96 As others have mentioned, see notmuch-deliver.  I and others have also\r
  97 suggested inotify support for notmuch before, which would make the\r
  98 inbound mail mechanism (be it SMTP, IMAP fetching, or whatever)\r
  99 completely unaware of notmuch, offer some other benefits (for example,\r
 100 if mail is manipulated outside notmuch via IMAP), and is highly\r
 101 discoverable for new users (just have notmuch setup ask if they want\r
 102 notmuch to monitor for new email and then fire up an inotify daemon\r
 103 the first time notmuch is called).\r
 104 \r
 105 > =A0 =A0* automatic spam filtering, and tag applying;\r
 106 > =A0 =A0* automatic email triggers based on tags (such as user\r
 107 > notifications, forwarding, etc.)\r
 108 \r
 109 Obviously the above two can be scripted, but I agree that it's\r
 110 unsatisfying that every user needs to roll their own delivery script.\r
 111 While tagging and triggering are highly personal, they're not *so*\r
 112 personal that everyone needs a completely custom solution.  This\r
 113 should be more approachable.  I'm not sure what the best answer here\r
 114 is, but I don't think it requires it requires integration with a\r
 115 monolithic system to do right.\r
 116 \r
 117 > =A0 =A0* remote RPC-like access to the whole system;\r
 118 \r
 119 This is another deep insight of notmuch.  It already has an awesome\r
 120 RPC interface: the CLI.  Perhaps your actual problem is that the only\r
 121 supported remote transport protocol is SSH.  This comes with a lot of\r
 122 benefits (authentication, RPC pipelining), but also a lot of baggage\r
 123 (a full SSH client on the client side).  I've thought about this in\r
 124 the context of both an HTTP client and an Android client and in both\r
 125 cases I concluded that a simple HTTPS transport wrapped around the\r
 126 notmuch CLI would be the way to go.  Just put the CLI arguments in a\r
 127 POST and send the JSON on stdout back.  This is trivial to prototype\r
 128 as a Python CGI script, easy to build as a standalone Python server,\r
 129 and not especially hard to build as a robust C server.\r
 130 \r
 131 > =A0 =A0* remote Web user interface;\r
 132 \r
 133 A good web UI would be fantastic.  Based on the rest of your email, I\r
 134 get the impression this was a requirements driver from much of the\r
 135 above, especially the integrated tagging/triggering and RPC access.\r
 136 I've already suggested a simple solution to the RPC problem.  For\r
 137 tagging/triggering, it's probably worth developing a solution that\r
 138 allows for machine-editable rules (ideally retaining\r
 139 user-editableness), which would make it possible to integrate filter\r
 140 management in to a web UI.  This could be as simple as a standard\r
 141 delivery script that operates from some simple rule database.\r