Chris Mason wrote: > > It seems to have something to do with procmail, I can't reproduce when > inserting the messages manually. Looking harder...
I noticed that you insert messages via "dbmail-smtp -m mailbox -u mason", I've got approx 20 users using procmail to insert their mail with dbmail-smtp, but I do it via "dbmail-smtp -u username" without specifying a mailbox and haven't found any problems yet. I'm not sure if this has got anything to do with it? On a second note, I've been thinking that with the procmail delivery support calling dbmail-smtp -u/-m, by the time it comes round to inserting the mail, if the database is not contactable, then the mail is lost (bounced or whatever) rather than being inserted into the database. My idea round this was, that when dbmail-smtp finds that it cannot contact the database, rather than just exiting, it should write a file in a configurable directory. Each file should be the mail it cannot delivery because of this database problem - one file per mail. The filename could be something useful, since we know that the process is called with a username, the filename could be something like "$username-$mailbox-$date/time-dbmail-deffered.mail". Re-insertion should be easy, since each file is a mailbox in effect, and raw-convert.c does this function for us. Matt
