mutt workflow and mail filtering

[benfitzg at gmail.com]

On Sun, May 12, 2019 at 08:43:04AM +1000, Cameron Simpson wrote:
> On 11May2019 09:38, benfitzg at gmail.com <benfitzg at 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