77/1cda1c32f12ea3ecade95d283ac766a42c5399

   1 Return-Path: <ciprian.craciun@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 E363E431FD0\r
   6         for <notmuch@notmuchmail.org>; Sun, 20 Mar 2011 07:07:53 -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.799\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
  13         FREEMAIL_FROM=0.001, 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 B1gnxX-ixy57 for <notmuch@notmuchmail.org>;\r
  17         Sun, 20 Mar 2011 07:07:53 -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 3D3B4431FB5\r
  22         for <notmuch@notmuchmail.org>; Sun, 20 Mar 2011 07:07:53 -0700 (PDT)\r
  23 Received: by qwc9 with SMTP id 9so3983639qwc.26\r
  24         for <notmuch@notmuchmail.org>; Sun, 20 Mar 2011 07:07:50 -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:date:message-id:subject:from:to\r
  27         :content-type; bh=d0zASK3fO5NGyFvdySqTpoViqI3C2piQb8VkyeXNzfg=;\r
  28         b=mrKbMx5Nic7ZtPGbOUWPokM4MTIU3jA1Kykrlww9YRjyPMhk1Ea+cEx+Gh5nlIO2NR\r
  29         dG84dK4tWFKgaaPe4Z61SRXlu+XaDYNG0Hg939F4fySW5jbS7XlRRC820FIAVYw3jvg9\r
  30         nt/DZNnUr58i/RpsnLEjZxO3GSsceJcO0yAI8=\r
  31 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  32         h=mime-version:date:message-id:subject:from:to:content-type;\r
  33         b=P/VhRoFLWsZpJQYZ2WeY1StOsljmDrXEFfU8uUI2d9E5Zq9oFhqJlGe93jt5ffYgAq\r
  34         xfhXX6PiBDGWRPBpZsbtXdPrOi9xLyGRoddLvylhP9x0rI5qpWvGEbo55OaRQwcCFUSa\r
  35         N7TohmyDjSmpEP9ws3ROCl5Bvc7hVMKWXf7+A=\r
  36 MIME-Version: 1.0\r
  37 Received: by 10.229.44.129 with SMTP id a1mr2387378qcf.228.1300630070710; Sun,\r
  38         20 Mar 2011 07:07:50 -0700 (PDT)\r
  39 Received: by 10.229.190.82 with HTTP; Sun, 20 Mar 2011 07:07:50 -0700 (PDT)\r
  40 Date: Sun, 20 Mar 2011 16:07:50 +0200\r
  41 Message-ID: <AANLkTim=-dYoR+LbV1UtH8f-Of-M_2AuEJYrGt-NeY4f@mail.gmail.com>\r
  42 Subject: RFC: notmuch powered (personal) (end-to-end) e-mail system\r
  43 From: Ciprian Dorin Craciun <ciprian.craciun@gmail.com>\r
  44 To: notmuch@notmuchmail.org\r
  45 Content-Type: text/plain; charset=UTF-8\r
  46 X-BeenThere: notmuch@notmuchmail.org\r
  47 X-Mailman-Version: 2.1.13\r
  48 Precedence: list\r
  49 List-Id: "Use and development of the notmuch mail system."\r
  50         <notmuch.notmuchmail.org>\r
  51 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  53 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  54 List-Post: <mailto:notmuch@notmuchmail.org>\r
  55 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  56 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  57         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  58 X-List-Received-Date: Sun, 20 Mar 2011 14:07:54 -0000\r
  59 \r
  60     Hello all! (Sorry for the long email.)\r
  61 \r
  62     I'm "struggling" for some time to get rid of the current\r
  63 "de-facto" email solutions (i.e. GMail, Zimbra), and I've passively\r
  64 observed for some time the notmuch project and community.\r
  65 \r
  66     Although I've forwarded all my email to a single account, and I'm\r
  67 currently mirroring my GMail account locally (by using `mbsync`),\r
  68 index it by using notmuch, and I collect spam mails for later filter\r
  69 training, unfortunately I'm unable to "convert" because the current\r
  70 notmuch-powered solutions have (some of) the following shortcomings (I\r
  71 don't want to offend anyone, so please take these as observations):\r
  72     * the most feature full UI is the Emacs one -- thus limited remote\r
  73 access (I mean from an arbitrary computer with only a web-browser);\r
  74 (and I'm not a very big fan of Emacs;)\r
  75     * most are still dependent on external IMAP systems -- this is not\r
  76 a problem with notmuch itself, but for the integrating clients;\r
  77     * SPAM -- as above -- is not integrated;\r
  78     * filtering (tag applying) is not automatic (as in integrated in\r
  79 notmuch itself or the client), but triggered through external scripts;\r
  80 \r
  81     As such I'm thinking on implementing a custom end-to-end email\r
  82 system and I would like to hear your feedback before embarking on such\r
  83 a task.\r
  84 \r
  85     I'm targeting the following features:\r
  86     * (inbound) SMTP integration, thus once an email is received it is\r
  87 automatically pushed through the system; (I'm primarily targeting\r
  88 those users that afford to run their own SMTP server; but the solution\r
  89 could still be adapted for those that only want the other features;)\r
  90     * automatic spam filtering, and tag applying;\r
  91     * automatic email triggers based on tags (such as user\r
  92 notifications, forwarding, etc.)\r
  93     * remote RPC-like access to the whole system;\r
  94     * remote Web user interface;\r
  95 \r
  96     About the overall architecture I'm thinking on adopting the following:\r
  97     * in general the whole system is decomposed in independent\r
  98 components (long-lived OS daemons) that each one does a particular job\r
  99 (see below);\r
 100     * all the components communicate between each-other through a\r
 101 message queue system (for example ZeroMQ or RabbitMQ);\r
 102     * all the communication is JSON based;\r
 103 \r
 104     The components would be:\r
 105     * SMTP inbound gateway -- for example I could take qmail or\r
 106 Postfix and replace the delivery agent with a custom process that\r
 107 pushes the email into the system; (any other solution suggestions?);\r
 108     * email store -- as the name suggests it is a simple\r
 109 key-value-like store that should persist raw email-messages; it should\r
 110 be as robust as possible, and its contents should be the only thing\r
 111 needed to reconstruct all the other derived data; (I could use here a\r
 112 simple process that maintains a maildir, I could go also with a\r
 113 BerkeleyDB wrapper, or even something more sophisticated;)\r
 114     * spam filter -- which either classifies the email or trains the\r
 115 spam filter; (for example I would use bogofilter;)\r
 116     * email index -- this is where notmuch would come into play; it\r
 117 would be fed with emails, which it would automatically apply tags and\r
 118 issue trigger notifications based on tags; it also maintains a set of\r
 119 filters and tags to automatically apply;\r
 120     * (maybe) a coordinator that should delegate and monitor requests\r
 121 to the above components; but if I'm using RabbitMQ and carefully\r
 122 designing the above components, they could drive each other;\r
 123     * restful web service that would intermediate access to all the\r
 124 above components;\r
 125 \r
 126     For now I have the following uncertainties:\r
 127     * how should I handle multiple users? I think each user should\r
 128 have it's own store / notmuch / bogofilter instance (at least in terms\r
 129 of storage if not even in terms of separate daemon);\r
 130     * should I keep the emails is a file-system, or a key-value store?\r
 131 (the file-system is more bug-free, but I'm confident that a BerkeleyDB\r
 132 instance would be more efficient);\r
 133     * should I use libnotmuch or for starters just make a notmuch tool wrapper;\r
 134     * and the most pressing one, transactions: I would like that at no\r
 135 point does a message get half processed or lost; as such I need\r
 136 notmuch to behave transactionally -- indexing the message and tagging\r
 137 it should be atomic and durable; (is there a way with libnotmuch to\r
 138 control the underlaying BerkeleyDB database?)\r
 139 \r
 140     Suggestions? Considerations?\r
 141 \r
 142     Ciprian.\r