On Wed, 2003-10-15 at 09:55, Matt Dickinson wrote: > 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? >
The docs made me think so (saying -u was less tested), which was my .procmailrc error went unnoticed for so long ;-) > 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. procmail can do much of this for you, when the dbmail-smtp fails it falls back to deliver into the default spool file. This gives you /var/spool/mail/$user When the database comes back up, run formail -s procmail < /var/spool/mail/$user as each user and things will get delivered. It won't be super fast since you're forking a procmail for each message but it'll work. -chris
