I currently use maildirproc for filtering Maildirs downloaded by offlineimap and like its highly flexible approach to filtering a lot (filters Python code). This works very well, except for one problem: after filtering, the next offlineimap run deletes the messages that where previously in Inbox on the mail server and uploads them to the folders they were sorted into. Depending on how many emails one gets, this is a colossal waste of bandwidth.

It is technically possible to filter and move on the server side, as proven by imapfilter. I would like to add the same capability to maildirproc by implementing an IMAP client.

Looking for mad skills in:

Nothing? Add some keywords!

This project is part of:

Hack Week 16

Activity

  • 6 months ago: aspiers liked Make maildirproc IMAP ready
  • about 2 years ago: jgrassler started Make maildirproc IMAP ready
  • about 2 years ago: jgrassler originated Make maildirproc IMAP ready
  • Show History

    Comments

    • jgrassler
      about 2 years ago by jgrassler | Reply

      This is where this will mainly happen:

      https://github.com/jgrassler/maildirproc/tree/imapproc

      I'll try to have something reasonably stable in this branch by the end of each day I'm working on this. You may find more up to date stuff in various topic branches I'll create as I go along, but I'll try to only merge working code into the imapproc branch.

      Today I mainly laid some groundwork, splitting up the original 25000 line monolithic maildirproc script into a bunch of individual modules. This appears to have worked out fine. I ran it with my usual maildir filter set after refactoring and it put everything where it was supposed to go.

      Note: If you want to try it for yourself, install it into a Python 3 virtual env. There is at least one Python3-ism in the original code (there may be more of these but I chose not to go down that particular rabbit hole since establishing Python 2 compatibility is not what I set out to do).

    • jgrassler
      about 2 years ago by jgrassler | Reply

      Ok, refactoring is complete, tested and merged to the maildirproc branch. Beginning with the IMAP implementation now. Work on that will happen in the add-imap branch. Again, I'll merge it into the imapproc branch as soon as it is tested/verified.

    • jgrassler
      about 2 years ago by jgrassler | Reply

      The imapproc command line entry point and all the code it uses exists now. As opposed to "it is tested". Which means that the command line utility is running and will happily complain that it cannot connect to the invalid host name I gave it. That's the extent I tested it to so far. Tomorrow I'll set up dovecot to see how it fares against an actual IMAP server. Since the current code is not fully tested, you'll only find it in the add-imap branch.

    • jgrassler
      about 2 years ago by jgrassler | Reply

      Jolly good news: IMAP filtering is working, at least against my local dovecot. I haven't thrown this at any other IMAP servers, yet, so your mileage may vary. Nonetheless, this warrants a merge into the imapproc branch, I guess.

      Next I'll do some cleanup, for there are still some things that could use improvement (error handling, feature/interface parity between the IMAP and Maildir processors, a signal handler, consistent configuration/log file naming and maybe a persistent header cache).

    • jgrassler
      about 2 years ago by jgrassler | Reply

      Ok. So cleanup is mostly done. I left out the error reporting cleanup, signal handler and persistent header cache, though. I'll rebase and package this later and try to muster the courage to throw it at something other than my local dovecot instance...

    • jgrassler
      about 2 years ago by jgrassler | Reply

      Ok, now there's updated documentation, proper dry run functionality for both IMAP and Maildir processing and a whole bunch of small fixes. I'll still have to test this against a real IMAP server though (I'm no longer scared of this now that the dry run function exists and works for IMAP, but I'm too tired to continue). Stay tuned. Probably some time this weekend, for I am itching to use this thing in anger, for it is the missing puzzle piece which allows me to finally get rid of Thunderbird :-)

    • jgrassler
      over 1 year ago by jgrassler | Reply

      I omitted the final update back then: I've been using this since Christmas and it mostly worked fine. I discovered one problem that caused it to occasionally eat emails early on. There's been no trouble ever since.

    Similar Projects

    This project is one of its kind!