Paul, I have a PHP version of this written and thought people might want it. Is there a place I can / should post it rather than on my site?
I've added support for the dates and should conform to the RFC on mbox format. -- David A. Niblett | email: [EMAIL PROTECTED] Network Administrator | Phone: (352) 334-3400 Gainesville Regional Utilities | Web: http://www.gru.net/ -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul J Stevens Sent: Wednesday, May 17, 2006 5:07 AM To: DBMail mailinglist Subject: Re: [Dbmail] Backup and Restore Niblett, David A wrote: > Gee, and I was just working on extracting the relevant queries from > the 2.1 code so that I might just do that very thing. :) > > I'm looking at a php script right now to do this right now. So since > it's in your head I'll try some extraction. > > 1) When you mention the "date" I assume you are using the Date field > from the header? Don't do that. Use internal_date in physmessages. Don't trust the Date field. > > 2) The SQL statement: > > select is_header,messageblk from dbmail_messageblks b > join dbmail_messages m using (physmessage_id) > where message_idnr in (xxxxxxx); > > Seems to be valid in the older 2.0 train. Can you see any reason why > that might not work? > > 3) I believe the mbox format only requires: > > From: <[EMAIL PROTECTED]> > <insert complete header here> > <insert message body here> > <explicit \r\n empty line> > From: <[EMAIL PROTECTED]> > etc... Wrong. Use >From senderaddress internaldate as the first line. So no colon! > > Doing that output looks pretty easy, so the last question is how would > I import that back in should I have to restore a user? cat dump.mbox | formail -ds dbmail-smtp -u username -m mailbox or use the import utility in contrib. Please note however, that the import in 2.0 is somewhat broken in that it doesn't respect the internal date in the From_ header, which means all imported messages will have an internal date set to the time of import. This was fixed in 2.1. > 4) I'm guessing it would be simpler to export the data as SQL for a > direct insert, but I expect the problem is that if the user_idnr > changes your are pretty well screwed. Plus the mbox format is > probably as small as it gets on the export correct? Yep. You will run into serious problems with the primary keys on all relevant tables. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ Dbmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
