[Declude.JunkMail] Hardware Upgrade
Hi We are planning a hardware upgrade for february, after 5 years on the previous ML370G2 We will buy a 2slot QuadXeon Motherboard, 1.333FSB, and 2x2.33GHz QuadXeon, 2GB DDR2 and have some technichal questions for the resident techies 1- Should we get the fastest memory available, or should the memory speed be a divider of 1333 or 2.33 ? 2- Does a mail server realy need SCSI or SAS @15K/Minute ? or regular SATA @ 7K or 10K enough ? 3- We are planning on using : 2 HD in Raid1 for System 2 HD in Raid1 for Mailboxes 2 HD in Raid1 for Spool Where should we put the virtual Memory ? Or, is it better to have 2 HD in Raid1 for System 2 HD in Raid1 for Mailboxes 1 HD Spool 1 HD for VM You all have a good weekend and a merry christmas next week Serge Dergham --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] automated response
Ik ben tot 7 januari afwezig. mvg. Erminio --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
RE: [Declude.JunkMail] Hardware Upgrade
Hello, Serge. I'm happy to chime in here, but let me start off with saying that you will get divergent opinions here, and that nobody will be absolutely right, as our answers are coloured by own experiences, and each implementation is unique. I'll also start off with asking you for your current and your intended message volumes, general architecture and software mix. Answering these details will help you keep the arguments comparing apples to apples because what is true for one respondent with low volume will not be true for another respondent with crushingly high volumes! My answers: 1- Memory I used to agonize over the making the exact right decision regarding slots, interleaving and multipliers; my truth *now* is that these are tweaks that make 2% to 6% of the raw memory speed in benchmarks and that it makes precious little difference in the real world for, say, an email server. Memory is relatively cheap; buy as much as you want as long it's from a name brand like Kingston, avoiding for example buying it from HP (the days are long gone where Compaq would tell you to remove 3rd party RAM to get support from them). 2- Disk technology Yes, my truth is that your fast servers need SCSI, SAS or a SAN based on those technologies. For bulk storage, choose SATA to save you a lot of money on back-end servers. In addition, buy a battery backed RAM cache controller for your RAID controller; this will enable write-cacheing on the RAID controller. An HP RAID controller will not assume that you have a battery backed UPS, and will not cache writes without this add-on. The throughput of your write operations are critical for a busy email server. If you buy an HP Proliant server based on SAS with 6 internal drives you will also need a second controller cable. 3- Disk layout Don't go cheap and use a single unprotected drive for any purpose. I used to like that format too, but my uptime and remediation time is more important than the cost of the drive technology. The layout you've described, it's good. Put the swap file on the System drive. Other commentary: If you use HP, you really really really should use their Firmware Update and SmartStart install CDs. Download the current version rather than using the one that comes in the box. Also update your HP Insight Manager once the OS is installed, and set up your HP Insight Manager to send email alerts to a generic helpdesk account within your tech support team and *never* to just one staff member. The cefib.com domain is an ISP; I'd actually recommend TWO servers that are less expensive instead of one large one for your environment. The first server: As an antispam gateway for your inbound mail. The second server: As your mailbox store and for your outbound mail. Put monitoring software on each, watching the other server and your other connectivity as required. Andrew. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Sent: Friday, December 21, 2007 1:41 PM To: declude.junkmail@declude.com Subject: [Declude.JunkMail] Hardware Upgrade Hi We are planning a hardware upgrade for february, after 5 years on the previous ML370G2 We will buy a 2slot QuadXeon Motherboard, 1.333FSB, and 2x2.33GHz QuadXeon, 2GB DDR2 and have some technichal questions for the resident techies 1- Should we get the fastest memory available, or should the memory speed be a divider of 1333 or 2.33 ? 2- Does a mail server really need SCSI or SAS @15K/Minute ? or regular SATA @ 7K or 10K enough ? 3- We are planning on using : 2 HD in Raid1 for System 2 HD in Raid1 for Mailboxes 2 HD in Raid1 for Spool Where should we put the virtual Memory ? Or, is it better to have 2 HD in Raid1 for System 2 HD in Raid1 for Mailboxes 1 HD Spool 1 HD for VM You all have a good weekend and a merry christmas next week Serge Dergham --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Hardware Upgrade
I mostly concur with Andrew here, but let me add some specifics. 1) *Memory* - for the 5000 series of chips using FB-DIMMs you need 4 total sticks to max out the memory bandwidth. 4 gets you twice the memory bandwidth of 2, though you can use just 2. The real-world benchmarks show maybe a 5% improvement, though this depends largely on what you are doing. I'm not aware of any advantage to getting faster memory as I believe these systems will run the memory at the speed dictated by the processors. The amount of memory for this particular application will depend on how many cores you have. I would do 2GB with 4 cores, and 4GB with 8 cores, but only if you are going to be pushing hard on them (and you probably won't be). 2) *CPU* - You should be fine with just 4 cores, in fact Windows will not likely be able to max out 8 cores with Declude due to heap issues (limitations in memory allocations). I run 8 x 1.86 Ghz cores and I start getting a lot of errors if I press the system to 100% from Declude, which with my config is somewhere between 150 and 200 messages being scanned concurrently. How much load per message will depend on what you are running in your Declude config. Mine is rather heavy, though I still couldn't get more out of the server in terms of total utilization due to the heap issues, though the messages would process more quickly with a lighter config. So I would guess that with 4 x 2.33 Ghz cores, you could do about 100 concurrent messages. Also take note that there are lower wattage quad-core Xeons out now that begin with L. These run about 50 Watts instead of 80 Watts for the standard quads. This does add up, especially when you consider that cooling and other supportive processes will at least 1 to 2 times that amount of power for what the server actually uses. If you pay your own power bills, the L series processors should pay for themselves. 3) *Disk and RAID* - SATA is the way to go. Try to stay away from the 2.5 drives if you can. Modern SATA controllers can handle RAID 5 without a bottleneck, and on a 4 drive system with a modern RAID controller, RAID 5 will definitely outperform RAID 10. I recommend 3Ware 9550sx controllers, but you should be safe with any SATA II controller that supports a battery backup for the cache. I would stay away from zero-channel RAID cards, and definitely anything that is host RAID or software RAID because they are much more likely to require physical intervention in the event of a drive failure. There is no need to separate the OS onto a different drive system for this purpose. I would get 250 GB drives since they will initialize faster and the extra space likely isn't needed. I run my 8 core system on a 4 drive RAID 5 array with SATA II drives and it works great. 4) *Pre-scanning Gateway* - Most Declude servers will save between 30% and 50% CPU utilization by adding an Alligate server in front of it (much more if you have catch-alls or aren't doing address verification at all). You will also block significantly more spam that way, especially the zombie stuff. I have helped many set up Alligate, and we can even host a backup server or set something up as a test if you were interested. Alligate doesn't require a lot of processing power, though the system needs to be a stand-alone system. Even a single-core server with a single drive would handle this great, though it makes sense to have a backup. Note that out of the box Alligate won't do near what it can when configured by an experienced administrator, and you can block a ton of spam and other attacks with virtually no false positives (definitely +99.99% accuracy is possible while rejecting over 80% of all connection traffic). There is another hidden benefit to using Alligate; many of the killer messages that can affect both Declude and IMail are stopped by a properly configured Alligate pre-scanning gateway, and virtually all of the automatically-spreading viruses too. Matt Colbeck, Andrew wrote: Hello, Serge. I'm happy to chime in here, but let me start off with saying that you will get divergent opinions here, and that nobody will be absolutely right, as our answers are coloured by own experiences, and each implementation is unique. I'll also start off with asking you for your current and your intended message volumes, general architecture and software mix. Answering these details will help you keep the arguments comparing apples to apples because what is true for one respondent with low volume will not be true for another respondent with crushingly high volumes! My answers: 1- Memory I used to agonize over the making the exact right decision regarding slots, interleaving and multipliers; my truth *now* is that these are tweaks that make 2% to 6% of the raw memory speed in benchmarks and that it makes precious little difference in the real world for, say, an email server. Memory is relatively cheap; buy as
Re: [Declude.JunkMail] Outbound weight
Are you sure your scanning outbound mail? Their is a directive that needs to be turned on for it to work. By default its off. JM ADD Spam checking for inbound/outbound scanning can be turned on/off. Located as a directive in the global.cfg file, below are the default settings. OUTBOUNDSCANNINGSPAMOFF INBOUNDSCANNINGSPAM ON Darrell -- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. David Dodell wrote: I know I'm doing something wrong ... I have the following in my global.cfg at the end WEIGHT10weightrangexx1039 WEIGHT40weightxx400 #CATCHALLMAILS catchallmails x x 0 0 # # The actions listed below only apply to outgoing E-mail, and only if you # have the Pro version. Note that the DUL and OSDUL tests should NOT # be used to block outgoing mail! # WEIGHT10 DELETE - But outbound email is not being caught and deleted ... is the second WEIGHT statement suppose to be configured differently for outbound? My inbound weights are working perfectly. David --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. -- --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
Re: [Declude.JunkMail] Re: Outbound weight
Your weight ranges are set fine. There is nothing wrong with the syntax of those. To be certain you only have weight ranges defined once right? Can you throw your logs into debug and send a test outbound message through. We will be able to help you better seeing this output. Darrell -- Check out http://www.invariantsystems.com for utilities for Declude, Imail, mxGuard, and ORF. IMail/Declude Overflow Queue Monitoring, SURBL/URI integration, MRTG Integration, and Log Parsers. David Dodell wrote: Are you sure your scanning outbound mail? Their is a directive that needs to be turned on for it to work. By default its off. Yes, I do have that line turned ON Do I have my weight defined correctly in the global.cfg that I have defined below? David Dodell wrote: I know I'm doing something wrong ... I have the following in my global.cfg at the end WEIGHT10weightrangexx1039 WEIGHT40weightxx400 #CATCHALLMAILS catchallmails x x 0 0 # # The actions listed below only apply to outgoing E-mail, and only if you # have the Pro version. Note that the DUL and OSDUL tests should NOT # be used to block outgoing mail! # WEIGHT10 DELETE --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com. -- --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
[Declude.JunkMail] Re: Outbound weight
Are you sure your scanning outbound mail? Their is a directive that needs to be turned on for it to work. By default its off. Yes, I do have that line turned ON Do I have my weight defined correctly in the global.cfg that I have defined below? David Dodell wrote: I know I'm doing something wrong ... I have the following in my global.cfg at the end WEIGHT10weightrangexx1039 WEIGHT40weightxx400 #CATCHALLMAILS catchallmails x x 0 0 # # The actions listed below only apply to outgoing E-mail, and only if you # have the Pro version. Note that the DUL and OSDUL tests should NOT # be used to block outgoing mail! # WEIGHT10 DELETE --- This E-mail came from the Declude.JunkMail mailing list. To unsubscribe, just send an E-mail to [EMAIL PROTECTED], and type unsubscribe Declude.JunkMail. The archives can be found at http://www.mail-archive.com.
