On Tue, Aug 28, 2007 01:03:13 AM +0300, Timo Sirainen (tss@iki.fi) wrote:
Basically, I need to write some shell scripts that, from cron jobs, regularly do this:
foreach file in some_incoming_mailbox/new/ do #process the file and/or set some variable according to its content delete the file or mv it to some_other_maildir/new/
So what happens if Dovecot sees the mail and moves it to cur/ before you had a chance to do that? If you really need to see all the new mails, then you'll need to figure out some way to handle that, such as add a new private flag for all processed messages.
Or you could deliver mails to some private maildir that Dovecot doesn't see, and process the messages from there to maildirs that Dovecot sees.
Yes, this is exactly what I want to do, sorry if it wasn't clear from the beginning. I am not going to _create_ messages, or _remove_ them under Dovecot's nose.
I have procmail delivering to:
aux_maildir_1/ aux_maildir_2/ ... aux_maildir_N/ INBOX
these scripts must only delete or move (not create or rename!) files/messages, with certain criteria and at certain times, from the aux_maildirs only to INBOX and INBOX.one, INBOX.two, INBOX.number
Dovecot only sees the INBOX* folders. Under these constraints I'm safe, am I not? Also, since all the file names are created by procmail (there is nobody else injecting email from the outside) I can count on them being always unique, right?
mv, rm and ln are always safe. Just don't ever write to new mail files in new/ or cur/ directory, because then Dovecot might read partially written files. That means that "cp file new/" isn't safe, but "ln file new/" is.
Er.. sorry, what do you mean exactly here? where is "file" where I link to new? What is the complete, exact sequence of Unix commands to safely go from:
aux_maildir_1/new/some_file
to, say,
INBOX.one/new/some_file
TIA, Marco
-- Help *everybody* love Free Standards and Free Software http://digifreedom.net/