Subject: Re: mail server recommendations? - msg#00061

Previous Message by Date: click to view message preview

re: mail server recommendations?

Hi Michael, I've researched mail systems myself for quite some time now. We currently use Sendmail + a custom pop3 server. We don't use system accounts. Sendmail is showing its age, mostly in the way it scales. It's difficult to integrate with any database backend. LDAP is your only solid option, but I'm no fan of LDAP. We are about to migrate from Sendmail and have considered Qmail and Postfix. Qmail is great. The only reason we did not choose it is because most features are patches of different authors and the quality and documentation of the patches varies. It makes us a little nervous to patch so much. So we've decided on Postfix+mysql+courier-imap. Postfix seems to have everything we're looking for: security, speed, sql backend, no system accounts, and quotas. We're still testing it, but it seems to behave very well under heavy loads. Regarding virus and spam filtering, we are doing it on Sendmail boxes now, which simply forward to other servers for pickup via pop. That will not change when we migrate since milter works well and there is no need for a sql backend on these boxes. We never looked at Exim. Some people like it. We just never got around to it so I can't give you any information on it. Hope the info helps. Arie Kachler Hi folks, I've already tried Google, and found a lot of discussions that are either a) old, or b) don't quite match our requirements. So: I'm looking for a decent solution for a mail server software package. We need SASL, IMAP, pop3ssl, antivirus, and mime-type filtering. In an ideal world, we'd have the ability to create mail accounts without creating user accounts. I have to admit that I'm partial to sendmail simply for the milter interface that lets me plug in, say, MIMEDefang, clamav, and all sorts of other nifty stuff. What are people using these days? What sucks the least? Any opinions from folks who have been there welcome. Thanks, ==ml -- Michael Lucas mwlucas@xxxxxxxxxxx, mwlucas@xxxxxxxxxxxxxxxxxxxx Today's chance of throwing it all away to start a goat farm: 49.1% http://www.BlackHelicopters.org/~mwlucas/ <http://www.BlackHelicopters.org/%7Emwlucas/> _______________________________________________ freebsd-isp@xxxxxxxxxxx mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isp To unsubscribe, send any mail to "freebsd-isp-unsubscribe@xxxxxxxxxxx"

Next Message by Date: click to view message preview

Re: synchronising failover web servers

So, say you have to update /usr/local/etc/httpd.conf. Would your process be this: * checkout cvs onto your workstation * change httpd.conf * check into cvs * log into server * update cvs repository * run Makefile script which installs httpd.conf in the correct location from the cvs repository and then executes 'apachectrl graceful'. * repeat on secondary standby machine by running a Makefile which uses ssh to trigger a remote Makefile I've never really liked Makefiles, but I guess we could do something very similar with shell scripts. Thanks for the info. But what do you do about synchronising data directories (eg. /usr/local/etc/www/data). In those cases you very often can't put them into cvs. Do you use Unison or something similar? Cheers Ari Maniatis On 11/04/2004, at 3:09 AM, Scott Lambert wrote: One word "Makefiles". :-) I have a lot of system configs in cvs. Eventually I'll have all of them. Each subsystem config has it's own directory and I have Makefiles setup to work the subdirs where necessary. We check the configs out in our home directories on each machine and run : $ make update install [test] [restart] --------------------------> ish group pty ltd 7 Darghan St Glebe 2037 Australia phone +61 2 9660 1400 fax +61 2 9660 7400 http www.ish.com.au | email info@xxxxxxxxxx PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 _______________________________________________ freebsd-isp@xxxxxxxxxxx mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isp To unsubscribe, send any mail to "freebsd-isp-unsubscribe@xxxxxxxxxxx"

Previous Message by Thread: click to view message preview

Re: mail server recommendations?

Mark Johnston wrote: Miroslav Lachman <000.fbsd@xxxxxxx> wrote: Hi, I am running similar configuration on several machines (Postfix + Courier-IMAP [with POP3ssl/IMAP4ssl] + MySQL). I have a guestion about one general difference - unique UID / GID for each user. I guess it provide more security, but also some troubles. If all virtual users (stored in MySQL) have same UID/GID, postfix can be configured to create maildirs itself with first incoming message. If each user has unique UID, maildirs must be created manualy (or from shellscript) and chowned to UID/GID. Exactly - that's the tradeoff. My question: "If all virtual users have same UID/GID, is there some real security risk?". Sharing UIDs and GIDs can have good or bad effects on security. On a server with no users logging in, like mine, it's moot; nobody (well, nobody who hasn't compromised the server) can get at the maildir storage on disk, so nobody (ditto) can play with the mailboxes. On a server where users do log in, you can go two routes: - Unique UIDs/GIDs. This makes things more convenient for the user, since they can use mail clients on the server and get right at their mail. If you want to have local mail clients work at all, you have to do this. - Shared UID/GID. In this case, the user can't get at their own maildir, and they'll have to use LDAP/POP3 over loopback to read their mail. It does make management easier, though. It sounds to me like you're working with a server where users don't log in, since you're using MySQL to manage user accounts. In that case, unique UIDs buy you essentially nothing. Yes, I am one and only who has shell account (logging via SSH), users have FTP, POP3/IMAP/webmail, HTTP access and CVS (CVSd pserver throught SSL [stunnel]) I'll be glad to read if same UID/GID is secure or not, because I am writing webbased administration tool in PHP and main problem is creation of maildirs for new accounts. Same UID/GID could solve my problem. The only time that unique UIDs and GIDs are useful is when the user will be logging in locally, so you can just look in /etc/passwd, find the user's UID, and create the maildir with that. If the user doesn't have a system account, you've got no reason to start making up UIDs to give them one; just share a single UID. PS: sorry for my bad english and a little offtopic message Since you say "offtopic", I assume you intended this for the freebsd-isp list, instead of private mail. I've taken the liberty of including the list in the Cc again, since security advice like this shouldn't go unreviewed. :) You might also want to move this thread to freebsd-security@xxxxxxxxxxx, to reach people with more security know-how. I am sorry for my mistake, I really intended this for freebsd-isp list and I'll send it to freebsd-security too. Thank you for your opinion. PPS: I'll publish webbased administration tool on sourceforge.net after completition One more question - does anybody know some webbased administration tools for email accounts of postfix virtual users in MySQL/PgSQL? (I started writing my own, but I am still interested in comparison with other tools) -- Miroslav Lachman Webapplication Developer _______________________________________________ freebsd-isp@xxxxxxxxxxx mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isp To unsubscribe, send any mail to "freebsd-isp-unsubscribe@xxxxxxxxxxx"

Next Message by Thread: click to view message preview

Re: mail server recommendations?

Aristedes Maniatis <ari@xxxxxxxxxx> writes: > We have sold Communigate Pro (http://www.ish.com.au/communigate) to > customers with up to 30,000 accounts. Others run up to 100,000 on a > single server, more in a cluster. It runs great on FreeBSD and that is > the combination we usually recommend and use ourselves. It costs > money, but you didn't say whether you wanted a free or commercial > product. I plugged qmail-ldap in an earlier message, but in a previous life^H^H^H^H job we deployed Communigate Pro (on Solaris)-: and it was rock-solid and handled pretty heavy loads without burdening the server much. Good responsive online tech support and bug-fixes, feature additions. IMHO their web gui's a bit ... uh... primitive, but it's useable. At another ISP we supported, we deployed Mirapoint mail appliances and they were fine too, but I don't have much direct hands-on experience with them. Both are worthy commercial offerings, and I think better than most other commercial alternatives. Check communigate's web for some interesting tech-rag reviews and comparisons with other products. I would definitely advocate some kind of fault-tolerant architecture, whether it's tight clustering, loosely-coupled federation (qmail-ldap with shared NFS mailstore), or whatnot. Email's dead critical to users and you can't afford downtime. It's really sweet to be able to take down one MTA/SMTP/POP/IMAP/LDAP box in the middle of the day for an upgrade, and have no one notice. :-) _______________________________________________ freebsd-isp@xxxxxxxxxxx mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-isp To unsubscribe, send any mail to "freebsd-isp-unsubscribe@xxxxxxxxxxx"