On Wed, Nov 24, 2004 at 07:15:43PM +0200, Uffe Pensar wrote: > > [141 lines of quoted material deleted. please learn to trim your quotes ] > > ok thanks for all the good advices, I will install postfix and have a > look att the dovecot and xinetd packages
if you're running dovecot, you don't need xineted. it is a standalone daemon, which has it's own (configurable) limits on maximum simultaneous connections. > but as a quick fix its seems that authenticating from a local server > (instead of radius) and restricting the number of webmailsessions has > helped for the moment. But I suppose we have to buy more servers in > the near future. yes, separating the tasks of 1) sending & receiving mail and 2) storing it & providing imap/pop/webmail/etc access is very useful. remember that mail is an I/O bound system. i.e. most of the time the processor is sitting idle waiting for disk I/O to complete. upgrading the CPU will do little or no good here. to improve performance, you need to improve the I/O speed - you can do this with faster disks, hardware raid card with large non-volatile cache, and by adding more RAM to the system. or by spreading the I/O load over more disks and/or more servers. a good starting point for a design is to have multiple small & cheap machines which are configured to accept all incoming mail (i.e. the MX records point at them), filter spam and viruses, and then either forward it on to the backend mail store server, or write it directly into NFS-mounted mail spool directories. if you use nfs, then you MUST use an NFS-safe mailbox store, like Maildir. trying to use mbox over NFS will almost certainly lead to mailbox corruption (although on debian it should be safe because *all* mail handling programs should use the *same* NFS-safe locking method. i wouldn't count on it though, especially if you compile your own mail programs rather than use the packaged ones) note that these MX boxes *MUST* have access to a list of valid recipients for all domains that it accepts mail for. this allows it to reject mail for unknown users during the smtp session rather than accept-and-bounce, so it doesn't generate backscatter and get bogged down with virus bounces and undeliverable spam bounces. the backend mail store could be either one very large and expensive server which stores the mail(*) and handles all the imap clients, or one medium-sized file-server (which stores the mail) and several small and cheap imap boxes which handle the imap connections, with NFS-mounted mail store (see comments above about NFS-safe mailboxes). when building the mail store, I/O performance is your key design criteria. don't worry about CPU, all the CPU-heavy tasks (like spam and virus filtering) are dont by the MX boxes. you may optionally want another box to handle all outgoing mail (i.e. the one that your clients use to send mail through, the mail relay). this one should also be optimised for fast I/O. one good way of doing this is to use a solid-state-disk (SSD - essentially a large battery-backed ramdisk that looks like a scsi or ide drive) for the mail queue. e.g. mount /var/spool/postfix (or /var/spool/mqueue if using sendmail) on the SSD device. SSDs are typically small and expensive, 1 or 2GB is likely to be the limit of affordability....but that's more than enough for a mail queue partition. in my experience, though, all but the largest ISPs receive dozens or hundreds of times more mail than they send, even when taking mailing lists into account. the mail store machine can double as the outbound mail relay - giving it an SSD device for the mail queue is a good idea. (*) e.g. on multiple 15000 rpm hard disks on a hardware raid-5 controller with at least 128MB of non-volatile cache ram. or whatever else it takes to optimise this box for extremely fast I/O. craig -- craig sanders <[EMAIL PROTECTED]> (part time cyborg) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]