Hello, I consider migration from dovecot to dbmail 2.3.5 As is released on January, I guess if it had some really major bugs, it would have been known already, is it? :)
Now, actually I have one problem with migration, which is well-known UIDL problem. I found the place where UIDL are kept in dbmail, so I can update table with moved emails to contain exactly the same value as generated by currently used POP3/IMAP, but the problem is, how to match and email stored in dbmail's db, with the email stored in MBOX mailbox file. I can move particular user messages to dbmail with provided mailbox2dbmail and additional script(s). But this will generate new UIDLs stored in DB, I consider the following solution: If a user have 158 messages in old mailbox, and I'm able to collect with some simple perl pop3 script UIDL's for these 158 messages, I can update 158 rows in a table with set of UIDLs I collect with my perl script. Assuming emails are moved to dbmail in the same order as they are stored in mbox file (I can update n-th message UIDL column with result of "UIDL n" pop3 command), this would be perfect solution - old mails would have the same UIDL and newly, later received messages would have new dbmail UIDL, I'm happy and free :) To make sure migration will proceed without interference, I can setup some temporarily pop3/imap proxy, which allows me to specify that a user "john" is migrated and proxy should direct pop3 client to dbmail's IP, and user "mary" is still with mbox - and direct pop3 client to some old pop3/imap server's IP. I'm also able to make some trick with my beloved sendmail to trigger dbmail-deliver for john, and (e.g.) procmail for mary. The only thing I need is UIDL match, to update UIDL in db. AFAIK dbmail does not support configuration directive nor other option, to force generating UIDL exactly the same way some previously used pop3 did. Other solution would be to add a TRIGGER to UIDL's column on postgres, which will call untrusted pl/Perl script, connecting to old pop3 server, retrieving UIDL for message x++, and update newly added column with retrieved variable. Anyway a dbmail's way UIDL generator for mbox file would be probably more safe solution. Any other ideas? Regards P. PS. And no, storing old mbox in Moved-Inbox accessible via imap, and emptying real inbox in new dbmail's location is not a solution for me, obviously :( -- View this message in context: http://www.nabble.com/additional-migration-issues-tp23115174p23115174.html Sent from the dbmail dev mailing list archive at Nabble.com. _______________________________________________ Dbmail-dev mailing list [email protected] http://mailman-new.icns.fastxs.net/cgi-bin/mailman/listinfo/dbmail-dev
