On Sun, May 12, 2019 at 08:43:04AM +1000, Cameron Simpson wrote: > On 11May2019 09:38, benfi...@gmail.com <benfi...@gmail.com> wrote: > > On Mon, May 06, 2019 at 03:59:04PM +1000, Cameron Simpson wrote: > > > Ny mail filtering is maildir based. I fetch from my ISP with getmail > > > which > > > simply delivers to my "+spool" maildir. My mail filer watches that > > > directory > > > and filters anything which lands there. > > > > > > To use such a scheme for gmail I'd imagine watching the local INBOX > > > maildir > > > and filtering everything which shows up; one side effect is that INBOX > > > would > > > stop being your inbox, and something else would need to become so. > > > > > > My mail filer is here: > > > > > > https://pypi.org/project/cs.app.mailfiler/ > > > > This is really interesting, I'll check it out. > > Apologies for the typos in the description page; I'm tidying that up. And I > need to update the package to include the mailfiler(1cs) and mailfiler(5cs) > man pages (command line and rule syntax respectively). > > If it's any comfort, I've been running mailfiler on my email for years. > > > My main concern is the resync > > back up to the IMAP server. OfflineImap keeps metadata on each mail, in the > > form > > of a UID. > > I would think that should still work. This is an untested belief. > > However, offlineimap might push all the refiled email back up into the > respective folders; I don't know if it is smart enough to see the UID move > and issue an IMAP message move instruction.
When I stop offlineimap, then save we go through the following: - in INBOX, before delete/save: $Maildir/INBOX/cur/1557336646_0.12279.server,U=26609,FMD5=7e33429f656f1e6e9d79b29c3f82c579 So here the msg has been assigned a UID of 26609 by offlineimap, which is also stored in offlineimap sqlite db. - after delete from INBOX, save to other folder, in mutt: this file disappears: $Maildir/INBOX/cur/1557336646_0.12279.server,U=26609,FMD5=7e33429f656f1e6e9d79b29c3f82c579 A new file appears in the other folder, with no UUID: $Maildir/folder/cur/1557609494.14736_7.server:2,S So mutt has removed the UID and the FMD5 folder hash. Now start offlineimap. Offlineimap reconciles with it's sqlite db and spots that the msg has gone from the INBOX. It deletes this remotely from the IMAP server. It also sees there is a new msg in the other folder, and then uploads this msg, obtains a new UID and renames the file: $Maildir/folder/cur/1557614822_0.8889.server\,U=44\,FMD5=c2ba172f48386ebda39871ac012912e9\:2\,S So now it has UID 44 and a new folder hash. I *believe* the UID is allocated on the IMAP server side, not had time to read up on this yet. >From a Maildir perspective it seems as though one could just process emails on the local filesystem by obeying this filename move rule of removing the UID and FMD5. Perhaps there is more to it than this. Anyhow thought I'd share those observations. I'm also curious why an MDA seems baked into most mail filtering options, like procmail. In a world where people want to forward emails from one account to another, an MDA that goes via a mailserver like sendmail/dovcot is a must, but for local processing it's overkill, and I'd imagine most people fall into the latter bucket. For me running a mail server to interface with a MDA is just too much on a shared unix server in a corporate environment. I'm not au fait with the history of MDAs so most likely I'm missing something. I just want to have something look at the headers of every mail that comes into my INBOX and then put *some* of those in another Maildir, all of which reside on the same filesystem under the same subfolder. Regards, -- Ben Fitzgerald