Announcements and discussions for Gnus, the GNU Emacs Usenet newsreader
 help / color / mirror / Atom feed
From: W. Greenhouse <wgreenhouse-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org>
To: info-gnus-english-mXXj517/zsQ@public.gmane.org
Subject: Re: emac gnus-centric gmail-phobic multi-host mail management
Date: Wed, 19 Feb 2014 08:59:24 +0000	[thread overview]
Message-ID: <87ppmjqxzn.fsf@motoko.kusanagi> (raw)
In-Reply-To: <87r470tkr3.fsf@channing.harvard.edu>

Taking your last two questions:

regcl <regcl-layyI3BE+OXOHkwriC13pfZ8FUJU4vz8@public.gmane.org> writes:

[...]

> C) Compatible mail repo/backup scheme
>
> I need to park the mail I am sweeping somewhere, once again with the
> compartmentalization issues. While I use emacs as my primary email
> client, it would probably be wise not to lock myself in to emacs, so
> maybe I want the mail in a form compatible with other clients on my mac
> os x desktops, most likely mac mail.app. What is the lightest weight
> approach here? Is it maildir with dovecot/localhost?
>
>
> D) Replication of the mail repos.
>
> I don't think I want to put up a pop or imap server on the net, at least
> not now. So I am thinking the problem here is primarily one of
> replication of my  mail directories across machines. Am I right?
>
> Based on my limited reading about mail, it seems like this could be done
> with IMAP, but I know zilch about IMAP and I don't have a place to park
> a personal IMAP server on the net.  
>
> On the other hand I use git for all of the other replication/syncing
> that I ever do. So here is the question: Can I park my mail in maildir
> with sub-repos for work and play, and use git for replication between
> machines? What would be the pros and cons of this approach vs learning
> using IMAP?

Git would be sub-optimal for syncing Maildirs around, as would a
standard file-moving tool like rsync, because a fundamental idea of
Maildir is that mail states are expressed by renaming/moving the file.
Whenever Gnus flags something or marks it read, therefore, git or rsync
would treat this like a whole new file, leading to inefficiencies.
Fortunately, there are tools to parse the Maildir format and figure out
which messages are in fact the same on both ends, so we can quickly
rename them to express a change in "flaggedness", instead of resending
the whole thing and deleting the file on the other end (yuck).

Here are the two implementations I know of to efficiently sync maildirs
over SSH, without exposing a new network service such as IMAP.  (They
also bypass the system MTAs on both ends, as they operate on the end
user's maildirs directly):

1. Maildirsync <http://search.cpan.org/dist/maildirsync/maildirsync.pod>:
   Single perl script.  Requires you to write your own short shell script
   or cron job to handle synchronization.

2. http://syncmaildir.sourceforge.net/: a complete rewrite of
   maildirsync.  Evidently meant to "just work" without writing own shell
   hax; I had trouble getting it to install on Slackware, however, so I've
   been happily using maildirsync.  Syncmaildir seems to be packaged for
   Debian-like distros, so that's a consideration.

My configuration looks something like this:

1. My almost-always-on homebox slurps various mail sites via fetchmail
   using POP3.  On landing at the system MTA, the mail gets delivered
   (along with any local/daemon-generated mail) to various Maildirs
   according to rules in my ~/.procmailrc.

2. I read some mail on Gnus at the homebox.  When fetchmail->procmail
   delivers some new mail to my priority inbox, `display-time-mode'
   notifies me by putting a little picture of an envelope on my mode
   line. :) Otherwise I don't get prodded about new mail until I poll
   Gnus again myself.

3. I go on the road with my netbook.  On the netbook, I run my maildirsync
   script when I have reliable net, and then M-x gnus to read the mail.

4. Gnus nnmaildir is pretty self-contained (flags/unread state is all
   inside the maildir itself), so if you are only using maildir,
   maildirsync will be enough to share state between the two machines.
   Since I also read NNTP news with Gnus, however, and also use niceties
   like adaptive scoring, I also sync my emacs configuration dir (which
   contains the gnus score files and newsrc* files) using Bzr.

TODO: be able to sync just one thing, instead of the sync
mailidr-then-sync-bzr-repo dance.  Maybe
http://lars.ingebrigtsen.no/2014/02/01/emacs-cloud/ will help with this
someday.  Also, cronify the maildirsync end on the netbook.

Hope this helps.  Please don't hesitate to ask for clarification; I'd be
happy to share any of the configuration files (fetchmail, procmail,
gnus/message/smtpmail/bbdb, maildirsync) that might be interesting.

  reply	other threads:[~2014-02-19  8:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-18 17:04 regcl
2014-02-19  8:59 ` W. Greenhouse [this message]
2014-02-20  1:05   ` regcl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ppmjqxzn.fsf@motoko.kusanagi \
    --to=wgreenhouse-sgozh3hwpm2stnjn9+bgxg@public.gmane.org \
    --cc=info-gnus-english-mXXj517/zsQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).