On Thu, 24 Apr 2014 14:37:52 -0600 Bob Proulx wrote: > RW wrote: > > Ian Zimmerman wrote: > > > RW wrote: > > > RW> I don't think it will work for the purpose mentioned, and if > > > RW> it's working properly for you, there's a lot you're not > > > RW> mentioning. > > I looked at the script and it looks like an example that would work > for Ian fine. > ... > > > > RW> It's only looking for mail in the immediate post-delivery > > > RW> state after it's been put into the mailbox by an MTA or MDA > > > RW> and before it's been detected as new mail by an MUA (directly > > > RW> or via IMAP). It wont learn mail put into the folders by an > > > RW> MUA or IMAP at all. > > No. That isn't what the script is doing. > > The script is looping through mail files in a maildir and processing > them remotely on the server through sa-learn. After processing the > messages it is moving the messages to mark them as having been read.
No, the Maildir spec defines the "S" flag in the info field for marking mail as read (seen), the new/ to cur/ move is done by an IMAP server (or a local Unix client) in the first session that sees the new mail. Copying an email into an IMAP folder via IMAP will not put it into the new/ sub-directory of the underlying maildir. Opening a folder in IMAP will empty the new/ sub-directory. If you don't believe this, I suggest you actually try it on a real IMAP server. I just tried it on Dovecot, and I found it behaves as I expected. Newly delivered mail is moved to cur/ when a client is first informed about it, copied mail goes to cur/ in the destination mailbox. > > You might have mentioned that because it means it's not the > > solution you implied when you wrote "Here is my cronjob for that > > purpose". It's certainly not appropriate to users that don't like > > the command line. > > Sorry but you are incorrect. Users of Ian's system need not use the > command line. His solution directly answered the Dan's question. No, he said himself that my objections don't apply because it's an isolated mailbox that's not read by anything except the cron script. A macro in the client places the mail directly into the mailbox (bypassing the client's conventional mailbox handling) - this is really only even remotely sensible for a local instance of mutt, emacs etc. Mostly, it's pretty trivial to train Bayes from Maildir, but there is one significant complication, and that's that moving mail between Maildirs after training may break IMAP keywords, which some clients use for custom flags or for sharing proprietary metadata between separate client instances.