Your goals sound really good. But as for the plan... Are you forking because you want a different code structure or because you want a completely independent project that is not going to be compatible with mainline DBMail?
After 2.0, we're planning on changing the database structure to better handle header and mime caching, as well as a few other refinements. I'm more than sure that people here would like to see a "libdbmail.so" that exposed the message delivery and retrieval functions, and still have those functions be shared with the real DBMail to maintain compatibility. Don't fork to add features that people in the mainline want, too. Aaron Dan Weber <[EMAIL PROTECTED]> said: [snip] > ... I started working at this because I plan to fork dbmail > as soon as it hits a solid 2.0 release. I was going to split it more > into a mail management system and take away the pop and imap. Then I > would provide libraries and headers to write frontends to it. --
