Having completed an investigation on this matter and all your questions, I can post the following information (warning, its a long one):
The issues with the Zane server being blocked by AT&T were caused by a phishing scam that was being operated on the server.
Generally, when this sort of incident occurs, the abuse team is notified by the party that discovered the phishing scam and they promptly remove the scam and deal with the issues on the account that caused this to occur. However, it appears that AT&T did not follow that generally accepted practice and instead decided to place a block on the IP address of the server. This could have been done for any number of reasons, most likely to ensure their ISP customers were unable to be scammed via the site.
This case is an example of why it is extremely important for any customer on a shared server to update their scripts frequently. Belonging to a mailing list for the script they are using, checking the script's site, etc are important ways to find out about security related issues with an installed script. Had a customer's script not been exploited, the server would never have become blocked (Please do not ask who it was, we cannot reveal private customer information).
Once the reason for the block was relayed to us, the scam was quickly removed and the remainder of the time was waiting for AT&T to remove the block. This frequently happens to servers for email related abuse, though the block is restricted to email service to the blockers network. These types of blocks are generally removed in less than 24 hours. This was the first time in my ~3 years here at Lunarpages that an entire server IP had been blocked by a router on the internet backbone. Once we request the block be lifted, all we can do is wait until the blocker lifts the ban.
It has been asked why the server of the IP was not changed. A server's shared IP is tied into every domain hosted on the server in apache configuration files that must be updated, cpanel data that must be updated, email and ftp daemon configurations, etc. It is also tied into every DNS entry for every domain, subdomain, addon domain, and parked domain on an account. It must be updated on both nameservers in addition to the server. It is not a simple task and requires a great deal of planning to ensure that all changes are made in an appropriate sequence and that no configurations are screwed up by the change, missed in the process, and that they actually take hold.
It has been asked what will happen in the future. Since this is the first time this has occured, there is no way to know. Most companies report the offending site to the admin of the server it is on so it can be handled internally. If companies continue to follow the example of emailed each others abuse teams, this issue should not occur again. However, there is always the possibility that it will. This cannot be helped in a shared server environment and we cannot control every aspect of what each account has installed. That responsibility falls to the owner of each shared account.
It has also been asked why we don't scan servers for this type of issue and resolve them auto-magically. Quite frankly, this is impossible. There are so many 3rd party and custom written scripts out there that it would be inconceivable to try and manage what is and what is not permitted to be installed or in use. To even begin to consider this, we would have to have a list of scripts that are permitted. Any script not on the list would be disabled. This is impractical because new versions of scripts come out, so versioning would have to be used. This means we would also have to disable older versions when new ones came out, which would undoubtedly cause customer complaints. It is also far too limiting for our customer to be confined to a limited set of scripts, say no more than 5 installations per account and they have to be chosen from this list of say 15 allowed scripts.
Finally, compensation has been requested in a couple of posts. There are no plans for any form of compensation as there was no actual issue with the server or our network. Sparing you all more analogies, it would not be appropriate to demand that company A compensate loss due to the activities of company B when the services offered by company A have not been diminished by its own activity, or lack thereof. This block effected us as much as it has effected our customers. Several members of our own support staff were unable to access the server for customer services related issues.
The statement in the move email, 'this is a one time offer only', has also been criticized. Quite frankly, we cannot expend the staff to move every effected account off a server any time a block occurs. There is much more to a server move than clicking a few buttons. Account information must be updated, the old account must be compared to the new to ensure that all data and databases moved correctly, DNS entries must be checked to ensure they have updated, etc. It is a time consuming process.
It should again be noted that there was nothing wrong with the server itself or our internal network, the majority of people could still access the server without issue. This would mean that changing the shared IP of the server or moving all accounts to another server would cause the server to appear offline to everyone. In shared server hosting, a balance must be struck. We offered moves to those of you that could not reach the server out of generosity, we understand what it is to not be able to get to your site.
I hope this has been informative and should address all questions or concerns raised in this thread.