I would highly recommend dovecot as an IMAP server. It's fast, secure, easy to configure, very well maintained and also very flexible about virtual user management.
See http://wiki2.dovecot.org/VirtualUsers On 12 Dec 2012, at 03:04, dormitionsk...@hotmail.com <dormitionsk...@hotmail.com> wrote: > Yikes! I think this is a little beyond my abilities. I'm a lot more of a > programmer than a system admin. > > I think a more reasonable approach for me would be that if I run into > problems with the long user names using uw-imap, to just use Cyrus-Imap > instead. It doesn't require system user accounts. I didn't like it as well > as uw-imap when I tried it for a while on Linux several years ago. It's a > lot harder to administer and it's not nearly as "mobile" as uw-imap. By > "mobile", I mean that with uw-imap, it's a lot easier to move people's mail > from one server to another, and to restore inadvertently deleted mailbox > folders, etc. > > I appreciate the suggestion, though. I really do. > > I'm an Orthodox Christian priest-monk, and for what it's worth, I pray for > all of you OI developers. I greatly appreciate all of the hard work you are > putting into making OI a viable and freely available Solaris-based operating > system. And I know my God has most certainly helped me on several occasions > to get our OI server I've been working on these past few weeks to get it to > the point where it's almost ready to put online. I don't think that with as > much help as He's given me with this, that he'll abandon the OI Project, or > you all, from His care. > > Thank you again. > > Peter, hieromonk > > > On Dec 10, 2012, at 8:35 PM, Jim Klimov wrote: > >> On 2012-12-11 01:54, dormitionsk...@hotmail.com wrote: >>> Peter, >>> >>> Thank you very much for your feedback. I really appreciate it. >>> >>> Are there any particular tests that you think I should run, just to make >>> sure that I'm not likely to run into corrupted emails three or four months >>> down the road, well after I've implemented OI? >>> >>> I figured I'd test it with sending, replying to, etc. emails of various >>> different scenarios, just to be on the safe side. But if you think I >>> should test anything in particular, I'd appreciate your thoughts. >> >> Is an alternate solution possible for you: use an LDAP catalog >> with email data for users (as well as POSIX data for UNIX accounts)? >> >> This way you can have short "uid" values and arbitrarily long >> mail, mailEquivalentAddress or mailAlternateAddress properties. >> One of these may be "u...@domain.com" to avoid ambiguity, but >> is not required to be. >> >> There are a number of tutorials about making the Solaris operating >> environment a client of LDAP (Sun DSEE, OpenDJ, OpenLDAP, etc.); >> however, the mail subsystem will require its own integration for >> mail routing to the mailbox server ("mailHost"), alias address >> processing, etc. It is well documented for Sendmail in the internet, >> I am not sure about uw-imap. Don't think it should have problems... >> >> Also note that you'd want to avoid a deadlock (rather, a needless >> startup delay) by making an operating environment (global or local >> zone) which hosts the LDAP service a UNIX-client of this service. >> If you must do that, make the LDAP server start up before the SMF >> service ldap/client. I'd just put different tasks in local zones, >> LDAP server into one, mail into another, global zone as hypervisor >> with no end-users (except admins) and no LDAP client. >> >> HTH, >> //Jim Klimov >> >> >> _______________________________________________ >> OpenIndiana-discuss mailing list >> OpenIndiana-discuss@openindiana.org >> http://openindiana.org/mailman/listinfo/openindiana-discuss >> > > > _______________________________________________ > OpenIndiana-discuss mailing list > OpenIndiana-discuss@openindiana.org > http://openindiana.org/mailman/listinfo/openindiana-discuss > _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
