Re: [Nmh-workers] What OS/Architecture Do You Run nmh On?

[Ken Hornstein]

>if MH could speak IMAP and if pick(1) could use Sieve, life would be great!

I understand the first part of that sentence (like I've said previously,
I see no fundamental problems with that, just a matter of engineering).
But how do you envision the second part working?  My limited
understanding of Sieve is that it is designed to be at the same spot in
the email delivery process as slocal(1), and my reading is that only 4
actions it supports are "keep" (keep in "default location"), "fileinto"
(put into another mailbox), "redirect" (forward message to another email
address) or "discard" (just delete it).  Right now pick's job is to just
select messages (at most it can put them on a sequence), but the
argument has been made before that pick could be smarter and do common
tasks.  It seems like really we should consider having slocal have the
option for it to use Sieve as a language.

It seems logical that at some point in the future an nmh utility that
speaks ManageSieve (RFC 5804) should be written, but that's not
really related to pick.

>> Also, I was curious so I looked at the Dovecot sources; it seems that
>> if Dovecot notices that the mtime of the new or cur directories has
>> been updated, it will rebuild the indexes.  Also, it will move messages
>> from "new" to "cur" when it clears the \Recent flag.
>
>that's the suspenders, as in, belt and suspenders. the belt is, if 
>Dovecot moves a message on its own, it will usually update the index 
>incrementally. the mtime comparison is there to cope with the 
>possibility that some other Maildir client makes changes behind 
>dovecot's back.

Right, I was wondering if Dovecot was cool with other Maildir clients
modifying its store; the answer is "yes".  I was also wondering if
we do a "refile +/path/to/dovecot/folder 42", should we put the message
in "new" or "cur"?  Since it seems (in the singular instance of Dovecot)
that "new" is for messages that are flagged as \Recent, and I don't think
refiled messages should count as \Recent, then that suggests that the
message should go into cur.

As for a scan(1) or other nmh program taking the lead and moving a message
from "new" to "cur" ... maybe?  I lean toward "yes".  We'd make that
decision later, I think.

--Ken