A recent rash of successful phishing scams has caused an unknown number of outgoing emails sent by faculty, staff and students to be temporarily blocked, sometimes for a day or longer.
The blockages are intermittent, but likely to recur even as the campus amps up its fight against the increasingly sophisticated frauds. Information and Educational Technology, fully aware of how much the blocks impede campus communications, has several countermeasures in the works.
IET Vice Provost Pete Siegel sent an email message to the campus on Jan. 8 outlining the problem, and advising faculty, staff and students how to spot and avoid the frauds.
Phishing scams start when spammers send email messages telling people to send in their account names and or passwords, to verify an account or investigate a problem.
The frauds might sound plausible, but the red flag is the request for your account name and password. UC Davis will never ask you to confirm or verify your computing account by providing your password via telephone or email. If you receive an email that asks for that information, delete it.
A warning to that effect is posted on the standard log-in page that protects dozens of campus services.
But a few people who receive the phishing emails, not paying attention, send their account names and passwords to the spammer. The spammer then uses the information to turn the victims' campus email accounts into fire hoses of infectious "greeting cards," "work from home" frauds, and similar junk. Internet service providers (ISPs), such as Comcast, Hotmail, AT&T and Yahoo, shield their email customers from the resulting torrent by blocking all UC Davis email as suspect. The ISP does this by putting UC Davis email servers on its RBL (real-time block list).
The outcome: email messages sent from thousands of UC Davis students, faculty and staff get blocked without warning. It happened in the week between Christmas and New Year's. Then it happened again at the start of winter quarter.
The killer combination for the latest phishers is an account name and password and Geckomail, the campus email system for faculty and staff. All of the incidents IET has traced so far have occurred through Geckomail. Sometimes the phisher has logged in with the user's credentials to ensure they were good, and then waited until the weekend to launch the spam run.
IET shuts down compromised email accounts and responds to RBL blocks as soon as it learns about them, but does not control the ISPs. That means IET cannot predict when a block will be lifted. An ISP might well remove UC Davis from its RBL, then return the campus to the list after a fresh outburst of spam. (ISPs don't all employ the same practices and policies.)
To thwart phishing, user responsibility is critical--faculty, staff and students must keep their account information safe. Any carelessness disrupts the user's account and affects the campus at large.
The campus is looking at several technical responses. Some will require buy-in from the campus community as represented by various campus oversight and advisory groups. Short term, IET's Infrastructure Systems Management staff is creating a way to directly check UC Davis's status with the major ISPs every hour. The results will be posted to a Web site, to display current conditions.
Other options:
--Speeding up the sunset date for students accessing Geckomail, the campus email system for everyone except students (student accounts moved to DavisMail, which uses Google's Gmail, last fall). Students have retained access to Geckomail so they could move their address books.
--Monitoring outgoing mail on the campus servers, looking for certai n key features to identify spam, and temporarily suspending activity from such accounts.
--Scoring (but not filtering) all outbound mail.
Phishing is not new--what is new is the scams' frequency and fine-tuning. They're more successful, and the phisher knows about Geckomail and is sending during quiet times of the work week. As a result, all campus email servers get blocked. It's common for one server or another to land on one or more RBLs, but usually not all the servers at once.