The tactic is used primarily because mail with a legitimate From address is more likely to get through spam filters.  In general, the spammers are not targeting any individual or institution; they’re just doing whatever they can to improve their chances of having their messages delivered.

Users who are victimized by large amounts of backscatter often worry that their computer was broken into, or that they  have a virus.  Generally, backscatter does not indicate any problems with your own computer or mail server.  There have been some cases where a virus sent out messages designed to look like backscatter, with the virus payload as an attachment to the message, but even these cases were not a problem for users unless they clicked on the attachment.

As with most spam issues, backscatter is a pernicious problem.  When we send out a legitimate email that doesn’t get through, we want to get a bounce message that informs us of the problem, so we can resend or readdress the message.  It’s quite difficult for mail servers to tell the difference between a legitimate and an illegitimate message, so as long as mail servers are configured to deliver bounce messages, and as long as spammers are still spamming, backscatter will continue to occur.  We are looking at moving more of our mail services to the CalMail domain hosting environment; CalMail has better spam protection than we can easily implement at the departmental level, including better protection against backscatter.  Unfortunately, there is no magic bullet; CalMail users also experience spam and backscatter problems, though generally with less frequency than our other mail server users.

For now, our best weapon in the spam wars  remains the same; take a deep breath, let it go, and hit the delete key.

To ease the transition for our users, we have devised a way to allow two web servers to co-exist on the same machine.  (Geek aside: to do this, we’re using Apache’s reverse proxy directive, ProxyPass).  Our current plan is to put the PHP 5 -based server into production on Wednesday, April 23 at 5:00 PM; we will continue to keep the old server running so that any sites which have problems under PHP 5 can continue to run until their code is fixed.

In most cases, code that works with PHP 4 should work with PHP 5, but there are exceptions.  We know that the development framework LSCR has been using for our web team’s internally-developed applications (such as our department directory, news+events system, and course listings) does not work under PHP 5; we are in the process of migrating our code to the Zend framework.  If you are one of our web customers, we will be contacting you about migrating your department’s applications to the new framework.

If you are managing your own PHP code, or your own installation of a PHP tool like WordPress or drupal, it might be a good idea to test your code on our development server, which is already running PHP 5, sometime before April 23.  Mail sysadmin@LS if you’d like to get set up on the development server.

If you do nothing, your site will be migrated on April 23, and it’s possible that it will work just fine, but we would recommend that you check and test for problems.  Most problems should be minor and quickly fixable; if you have major problems after the migration, contact sysadmin@LS and we can temporarily put your site back on the old server to give you time to deal with the issues.

Many L&S academics are still using socrates, usually as a place for simple web hosting for their individual or lab home pages.  It does not appear that there will be a simple migration path for those users; IST’s announcement of the abatement, and the lack of a clear migration path, generated a lively discussion on the campus Micronet mailing list.

In response, IST will be holding a Socrates Customer Forum on  Tuesday, April 8, at 10:00 AM in Sibley Auditorium (Bechtel Engineering Center).  If you are invested in web hosting or other services provided on socrates, especially web hosting, it may behoove you to attend that forum.

If you simply need to be able to use a Unix command line, there are probably reasonable alternatives for you; Mac OS X is a full Unix environment, and if you use Windows you can install the Cygwin environment to be able to work in a Unix-like way.

The final version of PHP 4, version 4.4.8, was released in January and was recently installed on our main web server. The PHP development team has committed to providing security patches for 4.4.8 until this August; after August, using PHP 4 will be a violation of the campus minimum security standards. That situation gives us a fairly hard deadline for migration, and we’d like to be migrated well before then.

We have set up a development web server running Apache 2.2.8 and PHP 5.2.5 to allow departments to test their sites with PHP 5. Contact sysadmin@LS if you are interested in getting set up on the development server.

Our target date for cutting over to PHP 5 will be May 1, 2008. At that time, we’ll put PHP 5 in production on our main server, and any of your PHP code which is incompatible with PHP 5 will break. I expect that most sites will continue to work fine, with perhaps some small glitches, but it’s impossible to know unless you test your code beforehand.

We’ll be sending more communications about this change-over as it approaches.

Due to the aging of the technology, AWS is going to be replaced by Central Authentication Service (CAS); the tentative date for the deprecation of AWS is December 31, 2008. Moving from AWS to CAS will require some changes to all the applications currently using AWS; the changes should be fairly simple to implement.

The biggest advantage of CAS is that it provides single sign-on to all applications using CAS; that is, once you’ve logged on through CAS once, if you visit another web site which uses CAS, you won’t have to retype your password. This will be a boon for most users, especially those coming in through AirBears who’ll have to use CAS to get on the network in the first place.

If you have an application that’s currently using AWS, you should look at the links above to start working on migrating to CAS. Both services will run in parallel for at least the rest of this year; you can move to CAS at any time. It probably makes sense to move sooner rather than later, since CAS provides better functionality.

All of these alternate addresses have been basically equivalent until now; you could use any of them in your From: address, and anyone sending you mail could use any of them to address you. They all wind up in your CalMail inbox. Going forward, most of this will still be true; mail sent to user@uclink will still be delivered to user@Berkeley.EDU. The change is that, due to anti-spam provisions in the mailing list system, you will need to subscribe to the mailing list with the same address you use in your From: address in your email client. There are mailing lists which have been in existence for many years which are filled with @uclink and other legacy addresses; CalMail’s current plan is to replace those email addresses on mailing lists in bulk. (Scheduled for February 28).

What that means is that if you currently have your From: address set to be user@uclink, on February 29 (happy leap year!) mail you send to (most) mailing lists on lists.berkeley.edu will not be delivered–it will be held for approval by the list owner.

The easiest thing to do is just to set your mail client to use user@Berkeley.EDU as your From: address. It looks nicer that way, anyway. Bernie provided rudimentary instructions if you want to do it yourself, or you can contact your LSCR support team for help. Note that if you do this before February 28, you may have the same problem sending to mailing lists until the change is made, so it’s best to wait until the end of the month.

If you have public mailing lists, you’ll have to update the instructions you publish about how to sign up for the list. You’ll also want to familiarize yourself with the new interface for approving subscriptions and moderating postings, if you use those features. You will find it a lot easier in the new system once you get used to it.

The team has been working on this migration for over two years; the fact that it is now here will enable a number of other projects to move forward. Most importantly, Calmail is now very close to being able to realistically replace the functions of most departmental mail servers. CalMail is much better positioned to be able to deal with anti-spam and anti-virus protection schemes, and there is no way we can compare with the 24×7 support the service is offered. There are a few more technical details to work out, but we expect that we’ll move most of the email domains that we currently run on L&S hardware or departmental hardware over to CalMail’s departmental domain service over the next year or so. I encourage any of you who are still running your own mail servers to consider whether CalMail can meet your needs.

Unfortunately, there are some compatibility issues with Leopard which could be fairly significant, at least at first. The most significant issue for the campus is that Tivoli Storage Manager (TSM), the software which powers UC Backup, is incompatible with Leopard. IBM is planning to release an updated version in the first quarter of 2008–it looks like Leopard users will be without campus backup for several months at least.

FileMaker also has some problems with Leopard; FileMaker Inc. announced a free update to FileMaker 9 which fixes the problems, but has also said that it will not certify or update previous versions of FileMaker. Most campus FileMaker users are using versions earlier than 9, so this will likely be a problem if you can’t upgrade to FileMaker 9 right now. (See my post from July 27 on the need to migrate to a modern version of FileMaker).

Several Adobe applications, including Acrobat Professional which is in use by many departments, also have problems with Leopard. The MacOS Rumors site has a list of reported compatibility issues.

Because of these problems, especially the problem with TSM, at this time we are recommending that users not buy upgrades to Leopard. and if possible, buy new computers with Tiger installed instead of Leopard. If you have Leopard, contact your computing support team to see if we can work around the problems.

Leopard should be a good operating system, but it will take some time for all these applications to catch up with it.

The former are far more prevalent. A typical attack vector is to search Google for sites which are running known-insecure versions of a package, break into those sites, run malicious code (often leaving “zombies” in place to participate in spamming), and try to leave back doors to get back into the machine. Usually these attacks are not directed at the department in question; the hackers are just looking for a machine to use for their own purposes.

The latter are less prevalent, but can be more problematic, as they are more likely to represent an attack directed at the department or the application in question. However, I’ve also seen some examples of hackers attacking a departmental application simply because it was easy to find holes in.

In either case, you want to follow good coding and administration practices to reduce your risk. Never have world-writable directories within the web hierarchy. Any time you get input from the user, test that input for validity, ideally with a positive rather than a negative test (that is, test “does the input contains only A-Z and 0-9″, rather than “does the input not contain |’”/\, etc.”) If you install someone else’s software (open-source or not), put yourself on the mailing list for security updates, and install those as soon as they are available. If you customize someone else’s software, realize that upgrading it will be challenging in direct proportion to the extent that you’ve customized it.

Breaking into computers is no longer the province of 14-year-olds with too much time on their hands; it’s now a huge business with ties to organized crime. Access to compromised machines and applications is sold on the black market. Attacks continue to become more sophisticated, and our practices need to change to keep our machines and data safe.

I should remind you that PHP 4 has reached the end of its support life; we currently have a PHP 5 server up and running if you want to test your code before we go live with the new version around the end of calendar 2007. Mail sysadmin@LS if you are interested in getting a test directory in the PHP 5 installation.

We recently had a hard disk drive failure in a customer’s machine that was not backed up. She lost years of stored email, along with a database and other documents which took uncountable hours to create. We’ve all heard similar horror stories, or lived through them, yet we still seem to make the same mistakes.

Some people back up their files to writable CDs or DVDs; removable media are cheap and it just takes a couple of minutes, right? That’s my backup scheme on my personal machine at home. Now ask me, how long has it been since I actually backed up my home machine? (Answer: No idea, but it was at least 6 months ago, probably a year or more. But thanks for reminding me–I’ll go do it tonight.) For backups to be effective, they really need to be automatic and invisible to the user.

Fortunately, the campus has an inexpensive automated system: UC Backup, which is based on IBM’s Tivoli Storage Manager. For just 30 cents per gigabyte of data stored, you can install the TSM client on your machine and be protected in case of data loss. The office of the Vice Chancellor for Research provides an additional subsidy; researchers can get their data backed up for only 15 cents per gigabyte while funds allow. (See UC Backup’s page for information on signing up for the service and the research subsidy).

LSCR would like to see all of our customers’ files (both staff and faculty) regularly backed up by UC Backup or a similar system. I’d recommend the same for all computer users in L&S departments. The cost is low and the benefit is large; our institution has a huge liability out there due to irreplaceable data not being backed up. We’ll be contacting our departments to encourage them to sign up all their users with UC Backup, if they’re not already. (Over half of our administrative staff users are already being backed up through UC Backup, but for our faculty it’s a very low percentage).

Side note: The campus-wide IT Strategic Plan identifies backup as a critical issue, and sets a goal of having 80% of faculty and staff backed up by July 2006. [Obviously the plan needs some updating.] Personally, I think that the current UC Backup model doesn’t put the campus in position to accomplish this goal; the low cost is OK, but the administrative overhead required to manage the billing, even for that small a charge, creates a barrier significant enough to keep many departments and individuals from rolling out this professional backup service. I would like to see the service be free of cost to the user up to some reasonable threshold of data storage; 10GB or so. It’s really not worth generating hundreds of BFS transactions for $1.50 each.