I have been looking at doing the same,
I was trying however to do SQL > dbmail-lmtp rather than SQL > SQL
That way the conversion can get the benefits of single instance storage etc.
But there's no way to do it that will maintain flags that I know of. SQL
> IMAP may work but the speed of imap inserts seems pretty low (tens of
KB per second range, running through lmtp was in the MB/s range)
Perhaps if you added support for flags in dbmail-export and in
dbmail-lmtp then the migration tool would be pretty minimal?
If you got really fancy you could pipe the output through netcat or
something to get it to jump hosts too.
So something like
dbmail-export -u --flags [EMAIL PROTECTED] -folder=/inbox/porn | nc -w 50
otherhost 54321
then
dbmail-lmtp --respect-flags -u [EMAIL PROTECTED] -folder=/inbox/porn
put flag information in
The ability to do that formed the basis of a highly available system i
had in mind
If your keen then you can also tee it into multiple boxes or whatever.
Paul J Stevens wrote:
Sim Zacks wrote:
I am transferring my dbmal to postgresql. I have been having trouble
with encodings. I tried UTF-8 and when I moved some data it said it was
not compatible with UTF-8.
That is very tricky. I've been trying to convert one of my own stores on and
off. But no luck so far. I'm tempted to come to the conclusion that using
mysqldump->psql is a doomed approach.
Mysql has been very tolerant about inserting non-utf8 data in utf8 columns which
means that any data inserted before 2.2.7 is slightly suspect. The tables
involved are however non-critical. You could try and skip the caching tables,
and regenerate the caching tables after the migration.
But then there are still the blobs. Properly escaping the messageblks/mimeparts
tables before inserting them is very difficult to do from a simple shell pipe.
None of the usual mysql2pgsql tools work for me. I'm sorely tempted to write a
dbmail-migrate tool as part of dbmail itself that will do simple: select from
store1 -> insert into store2. Doing this for a complete store will not be
difficult at all. Being able to migrate a whole store, or even better one user
at a time from one backend to another, will be a major asset for enterprise
deployments. Especially as I plan to start supporting multiple backend stores.
Something like:
---<dbmail.conf>---
[DBMAIL]
db[1] = mysql://dbmail:[EMAIL PROTECTED]/dbmail
db[2] = mysql://dbmail:[EMAIL PROTECTED]/dbmail
db[3] = postgresql://dbmail:[EMAIL PROTECTED]/dbmail
---
dbmail-migrate -u someuser --from-store 1 --to-store 3
or
dbmail-migrate --whole --from-dsn \
"mysql://dbmail:[EMAIL PROTECTED]/dbmail" \
--to-dsn \
"mysql://dbmail:[EMAIL PROTECTED]/dbmail"
etc.
We receive email in a number of different languages. An example is we
get emails in Hebrew in both UTF-8 and Windows-1255. In the client
encoding, we have to manually change it (when it doesn't figure it out
on its own, because UTF8 can't read windows-1255 and vice versa.
Does it make the most sense to use SQL-ASCII instead of UTF-8? Or what
is the best way of doing this.
Don't ever use SQL-ASCII!!
Use default_msg_encoding = windows-1255 in dbmail.conf so that dbmail knows how
to decode headers that contain raw 8bit non-utf8 data.
_______________________________________________
DBmail mailing list
DBmail@dbmail.org
https://mailman.fastxs.nl/mailman/listinfo/dbmail
