From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 06240431FBC for ; Thu, 14 Jan 2010 00:12:37 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] autolearn=ham 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 l7+ItS7m1smT for ; Thu, 14 Jan 2010 00:12:36 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by olra.theworths.org (Postfix) with ESMTP id 19068431FAE for ; Thu, 14 Jan 2010 00:12:36 -0800 (PST) Received: from rose.makesad.us ([219.105.37.19]) by mx.perfora.net (node=mxus0) with ESMTP (Nemesis) id 0MMlbb-1NW9lO1fV1-0087Ve for notmuch@notmuchmail.org; Thu, 14 Jan 2010 03:12:34 -0500 Received: from vellum (localhost [127.0.0.1]) by rose.makesad.us (Postfix) with ESMTP id 871B2A005C; Thu, 14 Jan 2010 03:12:29 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by vellum (Postfix) with ESMTPS id 8B4BDC014B; Thu, 14 Jan 2010 03:12:24 -0500 (EST) Date: Thu, 14 Jan 2010 03:12:24 -0500 (EST) From: Asheesh Laroia X-X-Sender: paulproteus@vellum To: martin f krafft In-Reply-To: <20100112045152.GA15275@lapse.rw.madduck.net> Message-ID: References: <20100111221909.GA30299@lapse.rw.madduck.net> <1263267603-sup-302@elise> <20100112045152.GA15275@lapse.rw.madduck.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-OpenPGP-Key-ID: 0x70096AD1 MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323329-1696459810-1263456744=:27198" X-Mailman-Approved-At: Thu, 14 Jan 2010 13:13:45 -0800 Cc: notmuch Subject: Re: Potential problem using Git for mail (was: Idea for storing tags) 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: Thu, 14 Jan 2010 08:12:37 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-1696459810-1263456744=:27198 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 12 Jan 2010, martin f krafft wrote: > If the MDA delivers to Git, then potentially, you might get into a > situation where you cannot write your own changes back to the repo. This > is also a DoS scenario: I'll just keep sending you e-mail, and if I > manage to pass your mail filters, I'll basically commit to your mail > repository at regular intervals. Say those are 5 seconds. In order for > you to write updates to the repo, e.g. to update tags, then you would > need to pull, rebase, and push all within 5 seconds, for otherwise you'd > try to push non-fast-forwards. Sure. But the MDA doesn't need to do the commit immediately. Since (presumably) we're using Maildir, the MDA on the mail receiving server is going to generate filenames that won't cause conflicts. So it's okay to leave the files uncommitted. If that's too scary, then have the MDA deliver to its own git branch with its own checkout. Then, if you can force linearity with a lock (!), your client can have a special "lock the repo and push" command. Your remote MUA could even ask the MDA to lock the Maildir while it does a merge and then pushes that, and then the MDA can go back to dequeuing messages from the MTA into the Maildir. Not the beautiful lockless world the purists want, but I'm okay with that. > This a bit unrealistic, surely, but there's a real annoyance in it: > you'd have to pull/rebase/push until a push succeeds — until you found a > time window between pull and push during which the MDA didn't write to > the repo. This might take a long time. If this happens in the background > by Cron, it's not a real concern, but if this becomes a UI issue, I > wouldn't know how to handle it. It's not entirely unreasonable. Cron caused issues like that for me when I tracked my Maildir in git. I'm just learning about notmuchmail.org, but I'll keep listening here. Preferably CC: me on replies to this mail. I will say, I'm interested in an email setup with with working IMAP on at least one side. There's one other bad race I ran into when using git to manage my Maildirs. I was using Dovecot to serve my Maildir to an IMAP client, alpine. I separately did a "git merge" from origin/master, where the remote MTA had an MDA deliving messages and a layer on top of that committed them. When I did the "git merge", git would create the Maildir files in ~/Maildir/cur/... non-atomically. Dovecot would notice the file in ~/Maildir/cur/ and think, "This file must be ready!" So it would parse it even though git hadn't finished writing it. This caused me to only see partial headers in Alpine since Dovecot parsed it before it was a complete message. That kind of sucked. -- Asheesh. -- Almost anything derogatory you could say about today's software design would be accurate. -- K. E. Iverson --8323329-1696459810-1263456744=:27198--