Slashdot Mirror
Good POP3 Server for Huge Mailboxes?
brainchill asks: "I've got about 10,000 users split between a couple of quad 550 xeon machines. The machines have 2GB of ram. The problem is that the UW POP3 server takes a huge hit in both cpu and memory utilization when a 40+MB mail spool is requested via POP3. Sometimes it's bad enough to drag the monster boxes to their knees. What other POP3 daemons do you guys have experience with and how do they perform with large mailboxes"
You won't get good performance with mbox, period. You need to switch to Maildir. qmail-pop3d works great with Maildir. Maildir scales far better than mbox since it doesn't have to parse out the individual messages. It also doesn't have to use locking. This also makes Maildir inherently more reliable than mbox. There are many tools available to convert between mbox and Maildir.
How is this relevant to the question asked? The poster asked for a POP3 server that copes well when serving a mailbox > 40MB. This mailbox could have 1 40MB message or it could have 41000 1k messages.
Sending large emails via SMTP may not be the best useage of the protocol but in many cases (read - when one party is running Windows) it is very difficult to use FTP or scp to accomplish the same task as the tools are simply not available.
I would say: try popa3d.
We just went from cucipop to popa3d on a sendmail box supporting ~10000+ users. The load dropped from ~8 to ~1.5 during peak hours.
Before cucipop we were using qpopper, and the switch from qpopper to cucipop made a similar drop in load. Remember that this were with the "old" versions of qpopper, before the remote-root vulnerabilities were found. Don't know about the performance of today's qpopper.
I have never understood the hostility of mail admins to large emails. Simply because a number of mail servers have piss-poor performance with large emails is not a reason to go crazy over them. Fix the mail server.
Oh, and the fact that some people still use POP3, and their life is made miserable when they're working with large files over a modem. People should use IMAP.
There are quite legitimate uses for file transfer via email. Most people (i.e. not UNIX geeks) do not want to maintain a file server and keep their system up 24/7. The other person may not be at the computer...this puts it in their "queue of things to deal with".
If you mean "why don't people use ftp to transfer files to a third, intermediary system that acts as a drop box"...well, that's doing exactly what you're doing with SMTP. Why *not* do it with SMTP?
Finally, from a user perspective, mail is much more convenient to use than dedicated file transfer protocols. Most people constantly use a mail program and know how to use it reasonably well. Everyone has an email address (a more useful mapping to users than an IP address that FTP would require), and there are no worries about different companies having different places to drop files. Email lets users sort and date emails, and tag files as being from some user. It makes it accessable from anywhere they can get at their email.
Another thing that mail admins should live with is large mailboxes -- not just a single mail, but people leaving mail on the server, or keeping old mail around on the server. This is one of the *best* things to happen to IT. It's been the holy grail of NC designers for years. Centralize data storage to reduce costs, allow reuse of hardware, and facilitate backup.
Frankly, if anything, mail should be extended to have *better* support for this (like resumable transfers, etc). The FTP model -- where you have machines that are always up 24/7, users that associate well with "computers" rather than "other people", users that are familiar with a larger number of programs, and a network that has no firewall or other restrictions -- simply doesn't fit the reality of what's going on at businesses today. It's fantastic for techies who want to work with their own systems, but less good for your average end users.
May we never see th