Re: [vchkpw] Big server
- Original Message - From: Eric Ziegast [EMAIL PROTECTED] To: Marcos Dutra [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Monday, July 21, 2003 11:12 PM Subject: Re: [vchkpw] Big server The client mail server would serve whatever combination I would like make a big server with qmail +vpopmail +mysql +procmail. I think in this structure: Server 1: Mx domain + smtp delivery +filters (Antispam, user filter(procmail) and antivirus) This server basically is the mail gateway of all domains, where is passed in the filters rules per domain and redirect all mails to server 2 Server 2: Pop3 accounts + mysql server Here is created all accounts. This schema is good for multiple domains? Based on my experience, I agree, but I might split Server2 into Server2 (delivery/storage/database) and Server3 (pop/imap/webmail servers for clients). I include more details below for one economical infrastructure I worked with. It's not a HOWTO, but knowing what someone else has done might help guide you instead of figuring it out from scratch. Another question is how do i do the message delivery the messages from server 1 to server2? Qmail! :^) In /var/qmail/control/smtproutes, set it so that all mail goes to Server2 (eg: :server2.mydomain.com). If you're fancy, you can try QMTP instead of SMTP. -- Eric Ziegast A sample large server environment (hundreds of domains, thousands of users) I once helped with: The MX record points to multiple cheap parallel inbound mail servers: - Single CPU PC at the best Price/Performance cost. I've found that one can build these for $300 each. You will find that when doing Virus/Spam scanning that the first bottleneck that you hit (out of CPU/memory/disk/network) is CPU. All of the regular expression searching on an e-mail message takes processing power. Assuming you have enough RAM, disk I/O would be the next bottleneck. I found a good balance AMD 1800+ motherboard /w 512MB PC133 RAM and 7200RPM IDE. Another option is investing in a very fast multi-processor Intel screamer with lots of RAM, but the cheap and disposable dervers are linearly scalable. - RAM depends on how many simultaneous connections you want to be allowed for Spam/Virus filtering. I used 512MB on a cheap system becasue RAM is cheap these days. I usually ran out of CPU before memory. If the OS uses any significant amount of virtual memory, you need more RAM. Run vmstat. If pi or po is above 0, you need more RAM or need to lower the number of simultaneous connections allowed by qmail (eg: concurrencyincoming in /var/qmail/control). The inbound server is your mail firewall and doesn't have time for paging to disk when the message load is high. - Hardware or softare RAID1 7200+ RPM IDE drives is sufficient. I have been told by a Linux integrator that Linux software RAID1 can be faster than the RAID1 provided by hardware controllers. If you have a budget for SCSI, use it. You need merely a 9GB drive in an inbound relay server anyway because the mail doesn't sit on the server. In fact, you may see a disk I/O improvement if you limit /var/qmail/queue to a 2GB partition of the hard drive. If you don't need the space, you don't need to have the disk head potentially cross the entire disk to find data. If you select a hardware RAID controller, prefer a controller that has non-volatile RAM or RAM /w a battery. This will allow the controller to use write-back mode on write and significantly reduce response time between the computer and the hard drives. - While I love OpenBSD and FreeBSD, I've used Linux for Qmail services because I've had other Linux-capable staff that could help administer the servers. Another advantage to Linux is ReiserFS. I have used ReiserFS on /var/qmail/queue partitions with success after applying the fsync patches. (http://www.jedi.claranet.fr/qmail-reiserfs-howto.html) ReiserFS performs well with thousands of files in a directory and allows you to keep the default hash value (23) for the spool directory. If using ufs (Solaris/BSD), consider compiling a queue hash value of some large prime number (like 101). If using Linux without ReiserFS, at least use ext3 instead of ext2 so that you can recover after a crash. If using Solaris, consider VxFS if you have the ability to use it. A standard fsck of a non-journaled filsystems used for qmail REALLY sucks. Aside: I don't export ReiserFS over NFS - just use it for the mail relays themselves. For vpopmail directories, I use filesystems that are known to be tried and tested in heavy read/write environments under NFS. I hope ReiserFS gets to this state, but at the time of my implementation, it was easier for me to use ext3 for vpopmail dirs. - I followed instructions for using QmailScanner /w SpamAssassin (spamc -f -c) and a Virus checker. I found
Re: [vchkpw] Big server
You would handle delivery from Server1 to Server2 making Server1 the primary MX record. Then from there, you will have the domains listed in smtproutes to hand of to Server2. Also, make sure your domains are listed in rcpthosts on Server1 or they will be rejected. - Original Message - From: Marcos Dutra [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, July 21, 2003 8:50 AM Subject: [vchkpw] Big server Hi people, I would like make a big server with qmail +vpopmail +mysql +procmail. I think in this structure: Server 1: Mx domain + smtp delivery +filters (Antispam, user filter(procmail) and antivirus) This server basically is the mail gateway of all domains, where is passed in the filters rules per domain and redirect all mails to server 2 Server 2: Pop3 accounts + mysql server Here is created all accounts. This schema is good for multiple domains? Another question is how do i do the message delivery the messages from server1 to server2? Thanks Marcos Dutra
[vchkpw] Big server
Hi people, I would like make a big server with qmail +vpopmail +mysql +procmail. I think in this structure: Server 1: Mx domain + smtp delivery +filters (Antispam, user filter(procmail) and antivirus) This server basically is the mail gateway of all domains, where is passed in the filters rules per domain and redirect all mails to server 2 Server 2: Pop3 accounts + mysql server Here is created all accounts. This schema is good for multiple domains? Another question is how do i do the message delivery the messages from server1 to server2? Thanks Marcos Dutra
Re: [vchkpw] Big server
The client mail server would serve whatever combination I would like make a big server with qmail +vpopmail +mysql +procmail. I think in this structure: Server 1: Mx domain + smtp delivery +filters (Antispam, user filter(procmail) and antivirus) This server basically is the mail gateway of all domains, where is passed in the filters rules per domain and redirect all mails to server 2 Server 2: Pop3 accounts + mysql server Here is created all accounts. This schema is good for multiple domains? Based on my experience, I agree, but I might split Server2 into Server2 (delivery/storage/database) and Server3 (pop/imap/webmail servers for clients). I include more details below for one economical infrastructure I worked with. It's not a HOWTO, but knowing what someone else has done might help guide you instead of figuring it out from scratch. Another question is how do i do the message delivery the messages from server 1 to server2? Qmail! :^) In /var/qmail/control/smtproutes, set it so that all mail goes to Server2 (eg: :server2.mydomain.com). If you're fancy, you can try QMTP instead of SMTP. -- Eric Ziegast A sample large server environment (hundreds of domains, thousands of users) I once helped with: The MX record points to multiple cheap parallel inbound mail servers: - Single CPU PC at the best Price/Performance cost. I've found that one can build these for $300 each. You will find that when doing Virus/Spam scanning that the first bottleneck that you hit (out of CPU/memory/disk/network) is CPU. All of the regular expression searching on an e-mail message takes processing power. Assuming you have enough RAM, disk I/O would be the next bottleneck. I found a good balance AMD 1800+ motherboard /w 512MB PC133 RAM and 7200RPM IDE. Another option is investing in a very fast multi-processor Intel screamer with lots of RAM, but the cheap and disposable dervers are linearly scalable. - RAM depends on how many simultaneous connections you want to be allowed for Spam/Virus filtering. I used 512MB on a cheap system becasue RAM is cheap these days. I usually ran out of CPU before memory. If the OS uses any significant amount of virtual memory, you need more RAM. Run vmstat. If pi or po is above 0, you need more RAM or need to lower the number of simultaneous connections allowed by qmail (eg: concurrencyincoming in /var/qmail/control). The inbound server is your mail firewall and doesn't have time for paging to disk when the message load is high. - Hardware or softare RAID1 7200+ RPM IDE drives is sufficient. I have been told by a Linux integrator that Linux software RAID1 can be faster than the RAID1 provided by hardware controllers. If you have a budget for SCSI, use it. You need merely a 9GB drive in an inbound relay server anyway because the mail doesn't sit on the server. In fact, you may see a disk I/O improvement if you limit /var/qmail/queue to a 2GB partition of the hard drive. If you don't need the space, you don't need to have the disk head potentially cross the entire disk to find data. If you select a hardware RAID controller, prefer a controller that has non-volatile RAM or RAM /w a battery. This will allow the controller to use write-back mode on write and significantly reduce response time between the computer and the hard drives. - While I love OpenBSD and FreeBSD, I've used Linux for Qmail services because I've had other Linux-capable staff that could help administer the servers. Another advantage to Linux is ReiserFS. I have used ReiserFS on /var/qmail/queue partitions with success after applying the fsync patches. (http://www.jedi.claranet.fr/qmail-reiserfs-howto.html) ReiserFS performs well with thousands of files in a directory and allows you to keep the default hash value (23) for the spool directory. If using ufs (Solaris/BSD), consider compiling a queue hash value of some large prime number (like 101). If using Linux without ReiserFS, at least use ext3 instead of ext2 so that you can recover after a crash. If using Solaris, consider VxFS if you have the ability to use it. A standard fsck of a non-journaled filsystems used for qmail REALLY sucks. Aside: I don't export ReiserFS over NFS - just use it for the mail relays themselves. For vpopmail directories, I use filesystems that are known to be tried and tested in heavy read/write environments under NFS. I hope ReiserFS gets to this state, but at the time of my implementation, it was easier for me to use ext3 for vpopmail dirs. - I followed instructions for using QmailScanner /w SpamAssassin (spamc -f -c) and a Virus checker. I found QmailScanner to be quite inefficient and significantly rewrote it to not break up the message into a zillion pieces for its internal scanning. SpamAssassin (spamd) does that for you anyway,
