>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 -- Nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
