nametrans confusion ...

Cameron Simpson cs at
Wed Feb 8 03:18:05 GMT 2012

TL;DR: I can't make nametrans create/sync correctly named local folders.

I'm trying to support a slightly odd setup, I think, from the lack of
matching examples I can find. It is clear that I don't understand how
the Local and Remote nametrans functions are used.

First, my setup. Second, my configs (made from a script).

The outline of my setup is probably common to many: a "home" server with all
my email; getmail runs there from cron and files to many folders via procmail.

I spend most of my time in front of a laptop. It lacks both storage
and bandwidth to keep all my mail locally, so I'm setting up a scheme to
keep only a few folders local. I invoke mutt indirectly via a script
that probes: if the folder is local it runs offlineimap to update it,
then a local mutt; otherwise it sshes home and runs mutt there.

So... on both the laptop and home server my mail is in maildirs in
~/mail. The IMAP at home is dovecot. To accomodate other users using mbox
I have a namespace to present ~/mail/foo maildirs as "MD/foo" in dovecot.

For top level folders things have been going smoothly. However, the
archive folders are not so.

For every folder "foo" I have an archive folder "OLD/2012/foo" where
"deleted" messages are moved. So clearly, if I keep 'foo" local to the
laptop I must keep "OLD/2012/foo" local as well so the local mutt can
put things there for later sync by offlineimap.

So here I am trying to sync OLD/2012/getmail (a convenient small
folder). The local folder I want to make is literally that:
"OLD/2012/getmail". The remote folder may be "MD/OLD/2012/getmail" or
"MD/OLD.2012.getmail" or even "MD.OLD.2012.getmail". I don't know!

FYI, mutt happily browses to MD then OLD then 2012 then getmail via
IMAP, so at least I know the folder's in there. However, that doesn't
tell me much about the IMAP side delimiters...

I'm invoking offlineimap like this:

  offlineimap -c myconfig.cfg -f MD/OLD/2012/getmail, -l a-logfile

and it does not seem to be pulling messages from the remote
OLD/2012/getmail folder. (It makes the local one, perhaps purely because
it is named on the command line?)

I'm using this config:

    accounts = _Users_cameron_mail::cameron at cskk.local:143
    metadata = /Users/cameron/.offlineimap
    ui = TTYUI
    ##ui = Blinkenlights
    fsync = false
    pythonfile = ~/

    [Account _Users_cameron_mail::cameron at cskk.local:143]
    localrepository = _Users_cameron_mail
    remoterepository = cameron at cskk.local:143

    [Repository _Users_cameron_mail]
    type = Maildir
    localfolders = /Users/cameron/mail
    sep = /
    nametrans = lambda foldername: here2there(foldername)

    [Repository cameron at cskk.local:143]
    type = IMAP
    nametrans = lambda foldername: there2here(foldername)
    remotehost = cskk.local
    remoteuser = cameron
    ##remotepassword = 
    remotepassfile = ~/private/passwd.cameron at cskk.local:143

and contains the functions:

  prepath = 'MD/'

  def here2there(f):
    rf = (prepath + f).replace('/', '.')
    print >>sys.stderr, "here2there(%s) -> %s" % (f, rf)
    return rf

  def there2here(rf):
    f = rf[len(prepath):] if rf.startswith(prepath) else rf
    print >>sys.stderr, "there2here(%s) -> %s" % (rf, f)
    return f

for debug purposes.

Amongst the stderr I see these referring to getmail:

  there2here(MD/OLD/2012/getmail) -> OLD/2012/getmail
  there2here(MD/getmail) -> getmail
  here2there(getmail) -> MD.getmail
  here2there(OLD/2012/getmail) -> MD.OLD.2012.getmail
  here2there(getmail) -> MD.getmail

I see the there2here for every remote folder and a here2there for every
existing local folder.

For the curious, I'm doing this on the fly using a script:

and for the even more curious, invoking the local/remote mutt thus:

(via a tiny wrapper script called "+", thus "+ getmail").

The mutt stuff is all fine. I clearly do not understand the nametrans


Cameron Simpson <cs at> DoD#743

Heavier-than-air flying machines are impossible.
      --Lord Kelvin, president, Royal Society, 1895.

More information about the OfflineIMAP-project mailing list