That's what I'm afraid of. I guess I'll buy another board. Perhaps this board will work ok as a Linux box. I won't be using all the fancy features in a Linux server. Now I just have to figure out what board to buy. Decent overclocking would be nice. Decent onboard features would be nice too. No Via anywhere please.
Sure there is. If it passes I'll be blacklisting every RIAA and MPAA netblock I can find. I'd also nominat the for an RBL listing due to the DoSing attempts from their netspace and their disregard for abuse@ mailings. They can't DoS my customers if they can't get past my border router. If they still flood me as a business, I'll sue for damages.:-)
I bought an Asus A7V333 with the onboard RAID. Once per minute regular as clock work the load spikes to 30% on top of what's already running. Once a minutes, regular as clockwork. Up and down real quick. Games stall, MPEGs stall, etc... The problem is apparently the RAID. I have 4 120GB WD 8MB cache models. 2 as regular drives. 2 as a stripe on the OEM Promise FastTrack133 builtin controller. If I disable RAID with the jumper, no spike. If I re-enable, regular spike. If I leave enabled and disconnect the 2 striped drives, no spike. It's got to be the RAID. Asus won't return my calls. I guess this means I'll never buy an Asus again and probably never buy a board with onboard RAID again. A buddy of mine blames it on the Via chipsets. Could be.
That said, I'm not so sure you want to buy anything with onboard RAID. Perhaps you should look at a speedy Firewire drive.
...when suits make decisions and don't believe what their own highly trained, highly experienced, and usually certified staff tell them. Believe me, I'm experiencing this first hand.
Yep, that's right. They're already inside you campus firewall. That's why you never trust the local wire. We're rebuilding our network over the next year and I'mm taking a lot of things into account to make it more secure. The ISP I consult for will also get some improvments. You can never be too paranoid.:)
True. A lot of Unvs aren't permitting wireless though. I've heard of some cases where they send a tech and a sniffer to locate a rogue wireless AP and then they bring the owner before the Unv's security committee. D'oh! The bad part about the 100Mbps is now they have to maintain to seperate networks, which might add overhead. Personally I think 10/100 for an access port is more than enough and will be so for 5 or more years. 10Mb is still world's to 95% of the users out there. Practically no user can fully utilize 100Mb. Installing 1000Mb just isn't worth it unless the cost is nominally more than 1000Mb, as it is in some distribution cases. I'm interested to see what they turn up. This could be quite an interesting project to follow.:)
The worst thing about going all MMF is that they eliminate the ability for a student to have a laptop, unless that laptop comes with GigE and the student wants to foot the bill for a 1000Base-SX to 1000Base-T converter. Canary makes some. LanCast makes one and it lists for $440. A simple MMF to UTP convertor WILL NOT WORK.
...what the hell for? I'm the netadmin at Unv and I'm fighting to not run GigE to all my buildings. It simply isn't needed here. I can't imagine running GigE to the desktop. They must have a helluva lot of grant money to waste. The nic cards along aren't cheap. A 3c996 SX card runs about $475 at discount. Are they expecting the users to go out and buy them? That card doesn't have Mac drivers either. I wonder if they expect new Mac users that already have 10/100/1000 to waste a PCI slot for a 1000Base-SX nic. This is just plain weird. I wonder what they connect the building to the campus with... One thing it does do is give the users more than enough umph to DoS most modern processors. It also gives them more than enough umph (if they connect to the campus LAN at say 10GigE to DoS their server farm firewall or worse yet, the actual server. Wanna fill the queue on their I1/I2 border router? Here GigE kids; go have fun.
It was built for the construction of Hoover dam. The dam slowly went up in 8 foot sections to allow time for each section to cure and cool before putting more concrete on top of it. It was calculated that if the dam had been poured at once in one big pour (yeah, impossible but they calculated it), it would have taken 125 years to cure. Set aside the fact that the concrete would have been extremely fragile... Ah the joys of the Discover Channel. Gotta love it.
What I would like to see is Government "grants" to better security at other federal and state agencies like universities, police departments, DMVs, etc. Then open it up to businesses and whatnot. My Unv would love to find a grant to help offset the costs of a good security solution. Our physical security is a joke. Odds are, you can walk right through our office, into our server farm, take a server, and leave with it with minutes, hours, maybe even days to spare before someone even notices it's gone. A grant to help pay for a keycard system and remodeling to accomadate heightened security would be great.
Isn't this what kicked Rambus in the junk though? Didn't a ruling against them revoke the patent because Rambus let their patent be widely and freely used everywhere (even if it wasn't officially acknowledged) and then sprung fees on the patent user? That was my take anyways.
The newsforge article and the comments above are from two very different camps. Which one is in the right? Is there a right? Many at my job dislike my youthful ambition and tendency to move quickly on jobs while I dislike the lathargic movements of those that have been here a while, those same people that end up making PHBs and believe that all decisions must be funneled through a committee or 3. Is the difference between these two camps possibly age related? I guess what I'm think is that in my experience age usually dictates temperment. Is that what we're looking at?
I ran into this very problem a while back and solved it last week. Have have a Packeteer PacketShaper 4545. We use it at my Unv to slow down P2P and speed up interactive traffic such as SSH. I also use it to limit the amount of bandwidth an application or set of applications can consume. One of these sets is Games. I limited them to a slice of bandwidth during the day and raised that after hours (neither limit has ever been reached). After hours I also garuntee a small slice to help kick start apps. I also use dynamic partitions to garuntee each flow a certain amount of BW within the garunteed slice. I've made various changes to the Games class over time to try and make it better. It's been a bit of a guinea pig to test settings on for other types of traffic. One of the things I've done is raise the classes Rate Policy after hours to something slightly higher than most other traffic. None of the things I tried helped. Users still complained of exceptionally high ping times (ie, 9999ms) even during after hour times. Most of these corresponded to bursts of other traffic, not usually with a higher rate policy. Finally I called tech support. One of their techs had me switch the Rate Policy (default) to a Priority Policy. He also explained the difference between the two. Using a rate policy to slow TCP traffic means that the ACKs are delayed to slow responses down. This isn't possible with UDP though. Using a rate policy on UDP resulted in either dropped packets or an entire datgram being delayed. There is no backoff implementation in UDP so the queue would fill with these UDP datagrams. Using a simple FIFO, the 1st delayed datagram would be delivered considerably late. The another and another. If the queue was full and a datagram was received, it was dropped. Bad news. The client would experience really crappy performance. Video and audio would be extremely choppy. It would just suck. A Priority policy works differently though. Let's say a UDP Quake packet and a TCP HTTP packet arrive at the same time. The Quake packet has a higher priority. The Quake packet goes 1st. No queuing, no delay. There's other technical stuff that goes along with this but I won't bore you with it. All in all, because this traffic was UDP, the policy method I was using (again, the default) caused horrible service. Does UDP have it's uses? I'm sure. Does UDP have benefits over TCP in some cases? Sure. Would I consider switching everything to UDP? Hell no.
I don't think brave is the right word. Dumb or ignorant might be a better choice.;-)
When I was much younger a bunch of my friends and myself would sneak into our Wal-Mart electronics area and install Doom on all the machines. They were networked at the time. When no one was looking, we'd have a fragfest. Lots of fun. I think we actually sold more Wal-Mart machines then they actual paid employees did!
...is using RH 5.x with 2.0.36 on their DNS servers. Of course we're also using Bind 4.9.7. Apparently they have (well, had) no ambition to upgrade. My network project requires a new DHCP setup and dynamic DNS. Now they have to upgrade. If it wasn't for that though, I wouldn't see them upgrading either system until a security problem cropped up and bit them on the ass. I keep all of my systems current to within a couple RH releases and my kernels are always to within a couple versions on a stable major release.
Honestly I don't much earthlink.net spam. In fact I can't remember the last time I got earthlink.net spam, even raping an open relay.
However I have gotten tons of broadwing.net spam. You (and I both) wouldn't believe the number if I could compile it. They ignore LARTs. They sign on known-spammers without regard. They simply don't care. Myself and many others blacklist them because of their in-action. I don't know if collateral damage is enough anymore though. The RBL was the best place to lay down some collateral damage. I wish it was used more.
I've always been of the opinion that filtering should be on the server side, for this and other reasons, but people make do with what they can get.
I more or less feel the same way. However I think that the obvious filtering should be done on the server. For example the DNS blacklists and the obvious spamming domains like "highspeedmailers.com" and "spamyouforadollar.net" should be filtered on the server. As well as the malformed messages; ie, the ones without properly formatted MessageIDs, malformed recipient fields, etc... I do think there is a benefit to spam scoring as well as this obvious filtering. I can't block an entire country at the MTA level. I can't block eudormail.com, yahoo.com, or hotmail.com either. I can't even blacklist amazon.com, ebay.com, or apple.com (all of which either spam (amazon & ebay) or run single opt-in lists (apple). My users would get pissed and I'd end up declaring a bunch of SPAMFRIENDs. That would defeat the purposes of filtering. As an ISP I'm filtering to reduce my consumed resources (bandwidth, drive space, processor time, etc..) and make my users happy (less spam in inbox). If I have to declare them to be SPAMFRIENDs because they want to buy from amazon.com, it hurts me. However, if I can pass the controversial filtering down to the user and let them filter it, I'm in the clear. I've used some of my resources that I wouldn't have used if I'd 55x the message, but I am keeping my users happy. For example, if I receive a message from Japan, I'll automatically add a couple points to the spam score. Then I'll run it through the rest of the spam scoring checks and let them judge the message as needed. In the end, I'll pass the message to the user and let them use the score I put in the header to decide on whether or not to keep the message. I've done my part by helping them filter spam. Now it's up to them to make the final call.
I think approach is best. Filter the obvious ones on the server, score the controversial ones & pass the final call on to the user's MUA.
Whoops. You showed the wrong syntax. Did you mean dada+slashdot@fatgeeks.com instead of dada_slashdot@fatgeeks.com? The underscore is a valid character in a user name. The plus sign however is called plus notation. I use it myself. Say I sign up for a demo of ProductX, I'll use the email address of userid+productx@domain.tld. MTAs are supposed to ignore everything between the "+" and the "@". Plus notation. It works pretty slick too. I use it for magazine subscriptions and what not too.
Something I've started using more is simple mail aliases. Since I run many MTAs, I've taken one of my own domains and create an alias for a mail recipient for when I need to sign up for something. Let's say I order some X10 stuff. I'll create a quick mail alias called "x10" and point it at my usual mail account. I'll add a comment with a date, maybe a URL, etc.. to it and rebuild my aliases.db. There are 2 upsides to this. 1 is that I can easily make that a real account someday and spamtrap all that junk if needed. It's also garunteed to be accepted on every web form I come across. Occasionally I'll come across a web form that only accept alphanumeric characters (and the @) in the email address. Some webmaster thought he was being security-wise and didn't follow the RFCs. Whoops. No biggie. This method gets you around that little problem. The only real downside is that it takes a couple extra seconds to create that alias and add some comments about it. Oh wait, there's another plus. Some mass mailers strip out the plus notation from email addresses. Giving your address to, say, Citibank or CapitolOne as joeblow+citibank@domain.tld might confuse the person or raise suspicion if you're entering your address in a spamtrap. With the email alias, you can use an acronym, gibberish, or whatever you want for your particular situation.
I wish there was a way to reduce the collateral damage caused by blacklisting. Then again, sometimes it's intentional. Take me for example. I've gotten more spam from Broadwing.net customers than I've ever gotten from anyone else. Broadwing.net doesn't give a damn about it either. I've LARTed them many times with spam. They don't even auto-ack you. Because of their in-action, I've blacklisted every broadwing.net netblock I can find. I want to get their attention by hitting them where it counts, their bottom line. I listed them with the intentions of a) stopping their spam, and b) getting their customers to complain about their inability to send mail to me and find out the real truth for themselves. There's no other way to get through to Broadwing unless your state has an anti-spam law that also finds fault with pro-spam ISPs. Then I have to sue which costs me time and money. This is really the only method of getting their attention. The collateral damage I'm creating by doing this is intentional. Most DNS blacklists don't do this. Some do though. The RBL will through a lengthy nomination process. SPEWS does it when all else fails. I use SPEWS. I also use their tactics. When I LART spam to an ISP numerous times and never hear back, or while researching spam I see that an ISP has been LARTed by other anti-spammers many times, I'll consider blacklisting them. I try to give them the benefit of the doubt though. Broadwing used up all their benefits and obliterated all my doubts long ago.
All that said, I think that collateral damage is acceptable in most cases. I think there's a reason behind it that some don't grasp right away. When you've LARTed an ISP a dozen times over one IP or one of their customers and they haven't done jack about it, you'll understand the usefulness of collateral damage.
I forgot to mention the repair/testing area. Large. Spacious. Seperate from both you admin area and your server room, physically and electrically. Multiple work areas so one is always free. Build network access into the picture.
Another excellent use for the back-side network I forgot is syslog! What an excellent place to put something like that.
Use raised floors. This helps you organize you cable plant. This is a neccessary evil.
Use full length racks (ie, racks that aren't just a single frame but are multiple frames to support the backs of large objects. Buy racks with builtin power management or install your own quality power management system with remote monitoring and control capabilities like APC's solutions.
While we're on the topic of power, the entire server farm should have conditioned power (ie, large UPS or battery solution) and should also have backup generator power. We're a small regents school in a midwest state. Even we have a natural gas generator for our server farm. Also put the admins' workstations on these protected outlets (mark the outlets well and educate the admins on not plugging in their refrigerators or space heaters into these outlets). Use multiple protected circuits in your server farm. You shouldn't have 10 machines and monitors on a single circuit. Never put a laser printer on the same circuit as a server.
Build an extensive KVM system and don't forget to utilize remote serial consoles too. Those two should always be built in parallel. All to frequently one is built without the other.
You need good cooling. Strike that, you need excellent cooling. You room should be very cool. Heat is the number 1 killer or electronic components. Keep the room cool and have you admins bring in jackets if they need to work in the server room. The room should be cold enough that a human feels very chilly, almost cold when they are in the room. This is another reason why you don't want your admins stationed in that room. They'll always be sick!
Your personnel should not be placed in the same room as the hardware. The background noise would drive them insane. Also consider possible medical risks from being around monitors and hardware all day long. Sure, it hasn't happened yet but I believe that someday some medical thing will be blamed on all those electronics. Better safe than sorry.
It sounds corny but strictly enforce a not eating/drinking policy in the server farm. Consider the room a psuedo clean room. An accident at your workstation might cost you a keyboard. An accident in a server farm might cost you a Sun Enterprise 10k (or a lot of parts and time).
Build your server farm with network storage and backup in mind. Build a SANs infrastucture into the design. Something I personally love to do is build a secondary server farm *only* high speed network that all servers are a part of. Each server connects to this network with a 2nd nic and uses RFC 1918 addressing. The network is not available from the outside world. You can use it for secure high-speed communication between your servers for LDAP, NIS, DNS, NTP, NFS, r*, whatever you need. Maybe you don't connect your servers to a SANs. Maybe you connect 3 NFS servers to it and NFS mount everything. Put those NFS servers on this high-speed network. It is an excellent way to provide high-speed and secure network access between your servers.
Always keep security in mind when you build it. "Do I need a DMZ?", "Do I need a partial DMZ or layered DMZ?", "Am I running any servers that only need to contact other in-house servers?", "Does one of my servers only need to be contacted from within my company or a small group in my company?", "Which servers are more of a threat to my other servers (ie, servers with user shell accounts) and what do I need to do to protect my other servers from this one?", "Is the network I'm connecting this server to secure enough for the data it houses?". The more of these things you think now, the less likely it is that you'll have to explain why one of these systems was hacked to a suit.
The best recommendation I can make for a server farm is to appoint (or higher if you're big enough) a server farm administrator. Make this person responsible for managing the power situation in the server room. Make them responsible for administrating the network in the server room. Give this person the authority to bitch slap people that eat and drink in the server room. If needed, give this person the authority to perform a remote security audit of a server to see if it is compromising the security of the other servers in the server room. Make this person responsible for the KVM installation, console server, and rack hardware in the server room.
For a admin room, I recommend having a conference room handy nearby in the office with a computer and project built into the room. Give you admins some privacy. Ideally they'd have their own offices. Maybe for some senior admins this more of a possibility. Give them plenty of space. Let them have multiple machines and monitors and give them the space to do so. Let them pick some of their office furniture, most importantly their chairs. Keep power management in mind in your cubicle farm just like you did in the server room. Allow them to have mini-fridges. Allow them to eat at their desks. Give them access to a kitchen area with a microwave, big fridge, sink, maybe cook-top but it's unlikely, and table to sit down at and eat if they want. Give them a lounge area where they can take their laptops and go sit in big comfy chairs and sofas. This could double as a room to nap in during an all-nighter or crisis. Provide wireless network access but HEAVILY secure that network. You admin network MUST, I repeat, **MUST** be kept secure! Encryption is a must. Physical security is a must. A firewall in front of your admin area is a must. If someone is using a Windows machine, FORCE that user to use a PRIVATE IP and STRONG anti-virus software. Don't let the lax security of a Windows machine compromise your admin network. If needed, give each of your admins their own subnet-based VLAN, say a/29 each. The other admins can use that to increase their own security. The admin area and server room must remained locked at all times. Utilzie keycards and PIN numbers. Perform a security check of all new employees prior to highering them.
Hell, I'm rambling now. You get the point though. Most of these things are achievable with ease and stubborn determination. Good luck!
The game isn't to blame. The parents of those 4 13 year olds are to blame. Do you want to prohibit rated R movies too because some damned parent is too lazy to keep tabs on their kids. Why don't we outlaw alcohol and cigarettes because some 16 year old junkie is working behind the counter a your local 7-11 and is selling kids the goods without checking their IDs? Might as well. Oh, and lets outlaw automobiles too because some minor stole a car and drove it into a tree. Might as well. You seem to think that parents aren't responsible for their kids. You're wrong there. That's why they are call "adults". That's why they are called "Mom" and "Dad". They are responsible for their children's actions because they are adults and know better.
Slashdot Mirror
That's what I'm afraid of. I guess I'll buy another board. Perhaps this board will work ok as a Linux box. I won't be using all the fancy features in a Linux server. Now I just have to figure out what board to buy. Decent overclocking would be nice. Decent onboard features would be nice too. No Via anywhere please.
Sure there is. If it passes I'll be blacklisting every RIAA and MPAA netblock I can find. I'd also nominat the for an RBL listing due to the DoSing attempts from their netspace and their disregard for abuse@ mailings. They can't DoS my customers if they can't get past my border router. If they still flood me as a business, I'll sue for damages. :-)
That said, I'm not so sure you want to buy anything with onboard RAID. Perhaps you should look at a speedy Firewire drive.
...when suits make decisions and don't believe what their own highly trained, highly experienced, and usually certified staff tell them. Believe me, I'm experiencing this first hand.
Yep, that's right. They're already inside you campus firewall. That's why you never trust the local wire. We're rebuilding our network over the next year and I'mm taking a lot of things into account to make it more secure. The ISP I consult for will also get some improvments. You can never be too paranoid. :)
True. A lot of Unvs aren't permitting wireless though. I've heard of some cases where they send a tech and a sniffer to locate a rogue wireless AP and then they bring the owner before the Unv's security committee. D'oh! The bad part about the 100Mbps is now they have to maintain to seperate networks, which might add overhead. Personally I think 10/100 for an access port is more than enough and will be so for 5 or more years. 10Mb is still world's to 95% of the users out there. Practically no user can fully utilize 100Mb. Installing 1000Mb just isn't worth it unless the cost is nominally more than 1000Mb, as it is in some distribution cases. I'm interested to see what they turn up. This could be quite an interesting project to follow. :)
The worst thing about going all MMF is that they eliminate the ability for a student to have a laptop, unless that laptop comes with GigE and the student wants to foot the bill for a 1000Base-SX to 1000Base-T converter. Canary makes some. LanCast makes one and it lists for $440. A simple MMF to UTP convertor WILL NOT WORK.
True (I was looking last night actually) but they aren't running copper. They're running MMF.
...what the hell for? I'm the netadmin at Unv and I'm fighting to not run GigE to all my buildings. It simply isn't needed here. I can't imagine running GigE to the desktop. They must have a helluva lot of grant money to waste. The nic cards along aren't cheap. A 3c996 SX card runs about $475 at discount. Are they expecting the users to go out and buy them? That card doesn't have Mac drivers either. I wonder if they expect new Mac users that already have 10/100/1000 to waste a PCI slot for a 1000Base-SX nic. This is just plain weird. I wonder what they connect the building to the campus with... One thing it does do is give the users more than enough umph to DoS most modern processors. It also gives them more than enough umph (if they connect to the campus LAN at say 10GigE to DoS their server farm firewall or worse yet, the actual server. Wanna fill the queue on their I1/I2 border router? Here GigE kids; go have fun.
It was built for the construction of Hoover dam. The dam slowly went up in 8 foot sections to allow time for each section to cure and cool before putting more concrete on top of it. It was calculated that if the dam had been poured at once in one big pour (yeah, impossible but they calculated it), it would have taken 125 years to cure. Set aside the fact that the concrete would have been extremely fragile... Ah the joys of the Discover Channel. Gotta love it.
What I would like to see is Government "grants" to better security at other federal and state agencies like universities, police departments, DMVs, etc. Then open it up to businesses and whatnot. My Unv would love to find a grant to help offset the costs of a good security solution. Our physical security is a joke. Odds are, you can walk right through our office, into our server farm, take a server, and leave with it with minutes, hours, maybe even days to spare before someone even notices it's gone. A grant to help pay for a keycard system and remodeling to accomadate heightened security would be great.
Isn't this what kicked Rambus in the junk though? Didn't a ruling against them revoke the patent because Rambus let their patent be widely and freely used everywhere (even if it wasn't officially acknowledged) and then sprung fees on the patent user? That was my take anyways.
The newsforge article and the comments above are from two very different camps. Which one is in the right? Is there a right? Many at my job dislike my youthful ambition and tendency to move quickly on jobs while I dislike the lathargic movements of those that have been here a while, those same people that end up making PHBs and believe that all decisions must be funneled through a committee or 3. Is the difference between these two camps possibly age related? I guess what I'm think is that in my experience age usually dictates temperment. Is that what we're looking at?
Make sure her area can get high speed Internet access. If not, dump the hillbilly.
I ran into this very problem a while back and solved it last week. Have have a Packeteer PacketShaper 4545. We use it at my Unv to slow down P2P and speed up interactive traffic such as SSH. I also use it to limit the amount of bandwidth an application or set of applications can consume. One of these sets is Games. I limited them to a slice of bandwidth during the day and raised that after hours (neither limit has ever been reached). After hours I also garuntee a small slice to help kick start apps. I also use dynamic partitions to garuntee each flow a certain amount of BW within the garunteed slice. I've made various changes to the Games class over time to try and make it better. It's been a bit of a guinea pig to test settings on for other types of traffic. One of the things I've done is raise the classes Rate Policy after hours to something slightly higher than most other traffic. None of the things I tried helped. Users still complained of exceptionally high ping times (ie, 9999ms) even during after hour times. Most of these corresponded to bursts of other traffic, not usually with a higher rate policy. Finally I called tech support. One of their techs had me switch the Rate Policy (default) to a Priority Policy. He also explained the difference between the two. Using a rate policy to slow TCP traffic means that the ACKs are delayed to slow responses down. This isn't possible with UDP though. Using a rate policy on UDP resulted in either dropped packets or an entire datgram being delayed. There is no backoff implementation in UDP so the queue would fill with these UDP datagrams. Using a simple FIFO, the 1st delayed datagram would be delivered considerably late. The another and another. If the queue was full and a datagram was received, it was dropped. Bad news. The client would experience really crappy performance. Video and audio would be extremely choppy. It would just suck. A Priority policy works differently though. Let's say a UDP Quake packet and a TCP HTTP packet arrive at the same time. The Quake packet has a higher priority. The Quake packet goes 1st. No queuing, no delay. There's other technical stuff that goes along with this but I won't bore you with it. All in all, because this traffic was UDP, the policy method I was using (again, the default) caused horrible service. Does UDP have it's uses? I'm sure. Does UDP have benefits over TCP in some cases? Sure. Would I consider switching everything to UDP? Hell no.
When I was much younger a bunch of my friends and myself would sneak into our Wal-Mart electronics area and install Doom on all the machines. They were networked at the time. When no one was looking, we'd have a fragfest. Lots of fun. I think we actually sold more Wal-Mart machines then they actual paid employees did!
...is using RH 5.x with 2.0.36 on their DNS servers. Of course we're also using Bind 4.9.7. Apparently they have (well, had) no ambition to upgrade. My network project requires a new DHCP setup and dynamic DNS. Now they have to upgrade. If it wasn't for that though, I wouldn't see them upgrading either system until a security problem cropped up and bit them on the ass. I keep all of my systems current to within a couple RH releases and my kernels are always to within a couple versions on a stable major release.
What a great way to promote Direct X. Make the other possibility too expensive to license. And the DOJ thought M$ was a monopolly.
However I have gotten tons of broadwing.net spam. You (and I both) wouldn't believe the number if I could compile it. They ignore LARTs. They sign on known-spammers without regard. They simply don't care. Myself and many others blacklist them because of their in-action. I don't know if collateral damage is enough anymore though. The RBL was the best place to lay down some collateral damage. I wish it was used more.
I more or less feel the same way. However I think that the obvious filtering should be done on the server. For example the DNS blacklists and the obvious spamming domains like "highspeedmailers.com" and "spamyouforadollar.net" should be filtered on the server. As well as the malformed messages; ie, the ones without properly formatted MessageIDs, malformed recipient fields, etc... I do think there is a benefit to spam scoring as well as this obvious filtering. I can't block an entire country at the MTA level. I can't block eudormail.com, yahoo.com, or hotmail.com either. I can't even blacklist amazon.com, ebay.com, or apple.com (all of which either spam (amazon & ebay) or run single opt-in lists (apple). My users would get pissed and I'd end up declaring a bunch of SPAMFRIENDs. That would defeat the purposes of filtering. As an ISP I'm filtering to reduce my consumed resources (bandwidth, drive space, processor time, etc..) and make my users happy (less spam in inbox). If I have to declare them to be SPAMFRIENDs because they want to buy from amazon.com, it hurts me. However, if I can pass the controversial filtering down to the user and let them filter it, I'm in the clear. I've used some of my resources that I wouldn't have used if I'd 55x the message, but I am keeping my users happy. For example, if I receive a message from Japan, I'll automatically add a couple points to the spam score. Then I'll run it through the rest of the spam scoring checks and let them judge the message as needed. In the end, I'll pass the message to the user and let them use the score I put in the header to decide on whether or not to keep the message. I've done my part by helping them filter spam. Now it's up to them to make the final call.
I think approach is best. Filter the obvious ones on the server, score the controversial ones & pass the final call on to the user's MUA.
Something I've started using more is simple mail aliases. Since I run many MTAs, I've taken one of my own domains and create an alias for a mail recipient for when I need to sign up for something. Let's say I order some X10 stuff. I'll create a quick mail alias called "x10" and point it at my usual mail account. I'll add a comment with a date, maybe a URL, etc.. to it and rebuild my aliases.db. There are 2 upsides to this. 1 is that I can easily make that a real account someday and spamtrap all that junk if needed. It's also garunteed to be accepted on every web form I come across. Occasionally I'll come across a web form that only accept alphanumeric characters (and the @) in the email address. Some webmaster thought he was being security-wise and didn't follow the RFCs. Whoops. No biggie. This method gets you around that little problem. The only real downside is that it takes a couple extra seconds to create that alias and add some comments about it. Oh wait, there's another plus. Some mass mailers strip out the plus notation from email addresses. Giving your address to, say, Citibank or CapitolOne as joeblow+citibank@domain.tld might confuse the person or raise suspicion if you're entering your address in a spamtrap. With the email alias, you can use an acronym, gibberish, or whatever you want for your particular situation.
All that said, I think that collateral damage is acceptable in most cases. I think there's a reason behind it that some don't grasp right away. When you've LARTed an ISP a dozen times over one IP or one of their customers and they haven't done jack about it, you'll understand the usefulness of collateral damage.
My $.02
Another excellent use for the back-side network I forgot is syslog! What an excellent place to put something like that.
Use full length racks (ie, racks that aren't just a single frame but are multiple frames to support the backs of large objects. Buy racks with builtin power management or install your own quality power management system with remote monitoring and control capabilities like APC's solutions.
While we're on the topic of power, the entire server farm should have conditioned power (ie, large UPS or battery solution) and should also have backup generator power. We're a small regents school in a midwest state. Even we have a natural gas generator for our server farm. Also put the admins' workstations on these protected outlets (mark the outlets well and educate the admins on not plugging in their refrigerators or space heaters into these outlets). Use multiple protected circuits in your server farm. You shouldn't have 10 machines and monitors on a single circuit. Never put a laser printer on the same circuit as a server.
Build an extensive KVM system and don't forget to utilize remote serial consoles too. Those two should always be built in parallel. All to frequently one is built without the other.
You need good cooling. Strike that, you need excellent cooling. You room should be very cool. Heat is the number 1 killer or electronic components. Keep the room cool and have you admins bring in jackets if they need to work in the server room. The room should be cold enough that a human feels very chilly, almost cold when they are in the room. This is another reason why you don't want your admins stationed in that room. They'll always be sick!
Your personnel should not be placed in the same room as the hardware. The background noise would drive them insane. Also consider possible medical risks from being around monitors and hardware all day long. Sure, it hasn't happened yet but I believe that someday some medical thing will be blamed on all those electronics. Better safe than sorry.
It sounds corny but strictly enforce a not eating/drinking policy in the server farm. Consider the room a psuedo clean room. An accident at your workstation might cost you a keyboard. An accident in a server farm might cost you a Sun Enterprise 10k (or a lot of parts and time).
Build your server farm with network storage and backup in mind. Build a SANs infrastucture into the design. Something I personally love to do is build a secondary server farm *only* high speed network that all servers are a part of. Each server connects to this network with a 2nd nic and uses RFC 1918 addressing. The network is not available from the outside world. You can use it for secure high-speed communication between your servers for LDAP, NIS, DNS, NTP, NFS, r*, whatever you need. Maybe you don't connect your servers to a SANs. Maybe you connect 3 NFS servers to it and NFS mount everything. Put those NFS servers on this high-speed network. It is an excellent way to provide high-speed and secure network access between your servers.
Always keep security in mind when you build it. "Do I need a DMZ?", "Do I need a partial DMZ or layered DMZ?", "Am I running any servers that only need to contact other in-house servers?", "Does one of my servers only need to be contacted from within my company or a small group in my company?", "Which servers are more of a threat to my other servers (ie, servers with user shell accounts) and what do I need to do to protect my other servers from this one?", "Is the network I'm connecting this server to secure enough for the data it houses?". The more of these things you think now, the less likely it is that you'll have to explain why one of these systems was hacked to a suit.
The best recommendation I can make for a server farm is to appoint (or higher if you're big enough) a server farm administrator. Make this person responsible for managing the power situation in the server room. Make them responsible for administrating the network in the server room. Give this person the authority to bitch slap people that eat and drink in the server room. If needed, give this person the authority to perform a remote security audit of a server to see if it is compromising the security of the other servers in the server room. Make this person responsible for the KVM installation, console server, and rack hardware in the server room.
For a admin room, I recommend having a conference room handy nearby in the office with a computer and project built into the room. Give you admins some privacy. Ideally they'd have their own offices. Maybe for some senior admins this more of a possibility. Give them plenty of space. Let them have multiple machines and monitors and give them the space to do so. Let them pick some of their office furniture, most importantly their chairs. Keep power management in mind in your cubicle farm just like you did in the server room. Allow them to have mini-fridges. Allow them to eat at their desks. Give them access to a kitchen area with a microwave, big fridge, sink, maybe cook-top but it's unlikely, and table to sit down at and eat if they want. Give them a lounge area where they can take their laptops and go sit in big comfy chairs and sofas. This could double as a room to nap in during an all-nighter or crisis. Provide wireless network access but HEAVILY secure that network. You admin network MUST, I repeat, **MUST** be kept secure! Encryption is a must. Physical security is a must. A firewall in front of your admin area is a must. If someone is using a Windows machine, FORCE that user to use a PRIVATE IP and STRONG anti-virus software. Don't let the lax security of a Windows machine compromise your admin network. If needed, give each of your admins their own subnet-based VLAN, say a /29 each. The other admins can use that to increase their own security. The admin area and server room must remained locked at all times. Utilzie keycards and PIN numbers. Perform a security check of all new employees prior to highering them.
Hell, I'm rambling now. You get the point though. Most of these things are achievable with ease and stubborn determination. Good luck!
I hope you never have children.