Feed on
Posts
Comments

On Oct. 14, 2014, ITS instructed the Wesleyan community to remove Front Door Software from their computers and change protection by the end of December:

Wesleyan has discontinued licensing Front Door Software.  The product has had ongoing issues with staying current with Mac operating system updates which impairs its functionality, making location tracking useless in many cases.  Given the proportion of Mac users in our population, it was inappropriate for us to stay with this solution.   For those who have Front Door installed, we advise you to change your protection by the end of December.

In its place, ITS recommends configuring Find My Mac and/or using Prey Anti-Theft.  Prey is a free application for Windows, Mac, Linux, Android, and iOS devices. It will allow you to track your device’s location, report it as missing, gather information about connections or location route or running programs, send an instant message to the thief, play a loud sound, lock the computer, take a screenshot, or even snap a discreet picture of the suspect with the device’s camera.

Recent alumni might have Front Door Software, a mobile security and theft protection software, installed on their computers. Please follow these instructions to remove the software from your computer:

You need to run the SetLicense program. If you can not find it, just use any download button and try to re-install it. Your computer will know that it is already protected and take you to the SetLicense program. You will need to know your uninstall code, which is also your connection code. You can find that by signing into your account, and select the STOLEN/LOCK tab.

More information can be found in the Front Door Software FAQs.

[Email Fwd]One of Wesleyan’s email servers experienced delays this morning between 2:00 a.m. and 6:00 a.m. affecting roughly 20% of alumni accounts on the affected server (Cyrus). Some users may have noticed that actions to move or delete mail failed during this period, and that mail was not being delivered. Full service has now been restored, and no mail was lost during the outage. Note that this issue only affected some legacy alumni email accounts—from the Class of 2008 and earlier. Alumni from 2009 and later were not affected. If you have any questions, please let us know.

[Email Fwd]Late last week, based on additional feedback from WesChat list members, we reverted the recent change to WesChat’s headers. Several regular readers/contributors noted that the changes made the list harder to use: to such an extent that it was worse than the original problem.

When we made the header change a few weeks ago we were concerned about message non-delivery, so we prioritized delivery to the maximum number of subscribed members, following the guidelines to listserv administrators issued by Yahoo and AOL.

With last week’s reversion to the original configuration, the priority for how WesChat works is now usability. Unfortunately this means that the original problem—messages not being delivered or going to spam for some recipients—has returned.

What this means

If you are subscribed to WesChat from an AOL, CS or Yahoo! address your messages will not be delivered to all users and may go to spam for some users. This is an email service problem on the sender side. Our suggested workaround is to resubscribe to WesChat from a non-AOL/CS/Yahoo address. The following table describes which senders and which recipients are known to be affected.

Affected Senders
Messages may not be delivered to services at right when sending from: 
Affected Recipients
Messages may not arrive from services at left when receiving at:
AOL (incl. Compuserve) AOL (incl. Compuserve)
Yahoo Comcast
Gmail
Hotmail (incl. Outlook.com)
Yahoo

Source: PCWorld.

We’re sorry that we weren’t able to resolve this problem in a more satisfactory way. Despite working with ITS staff we were unable to improve the way that Lyris notified recipients of the sender’s identity under the new header system.

Getting help

If you need assistance with WesChat, including resubscribing, please submit a support request and we will get right back to you.

Update (Oct. 7, 2014): WesChat header configuration has been reverted to its original setting.

[Email Fwd]Back in the spring some WesChat members who use Gmail began reporting increased cases of emails from some list members going to their Spam folders.

In late summer, with help from ITS, the Alumni Helpdesk made some technical changes (by activating DKIM on Lyris) to increase “deliverability” for messages passing through the WesChat list. Unfortunately the changes didn’t address the core problem.

After receiving more examples from list members, we narrowed it down to stricter sending policies adopted by AOL in April to combat email spoofing:

In our ongoing effort to protect your AOL Mail address from being used in connection with email spoofing, AOL Mail is immediately changing its policy to help mail providers reject email messages that are sent using forged AOL Mail addresses. [...]

By initiating this change, AOL Mail, along with other major email providers will reject these spoofed email messages, rather than deliver them to the recipient’s inboxes.

Where a sender’s email provider adopts a strict DMARC policy as AOL has done (and which Gmail honors) then messages relayed through a listserv that preserve the original sender’s From header will be rejected as Spam (or outright blocked, as Yahoo is doing). From AOL:

Today we moved to change our DMARC policy to p=reject. This helps to protect AOL Mail users’ addresses from unauthorized use. [...]

We recognize that some legitimate senders will be challenged by this change and forced to update how they send mail and we sincerely regret the inconvenience to you.

The reason is that a strict DMARC policy adopted by AOL and Yahoo essentially breaks listserv behavior. To a server configured to honor the strict policy, forwarding through Lyris looks just like email spoofing as used by spammers. From the same technical article by AOL:

What should you do?

[...] For mailing lists, also known as listservs, we recommend configuring reply behavior to fill the From line with the mailing list’s address rather than the sender’s and put the actual user/sender address into the Reply-To: line.

Yahoo recommends the same thing. So this is what we have done on WesChat. Yesterday we changed the From and Reply-To header pattern to:

From: weschat-l <weschat-l@lyris.wesleyan.edu>
Reply-To: Author <author@domain.com>

This means that to reply to the entire list you need to use the Reply All feature of your email program, otherwise you will only be replying to the author. Your new reply message would then look like this:

To: Author <author@domain.com>
CC: weschat-l <weschat-l@lyris.wesleyan.edu>

However, as one user reported today, Reply All doesn’t populate the CC field in Outlook, which means that yesterday’s change is going to be onerous for some members. Also, the new header pattern makes it more difficult to know the identity of the sender, and in most cases you cannot determine the author by glancing at your Inbox—you need to open the message first.

It seems best for list members to decide collectively how you prefer the list to function. Judging by the feedback so far, a number of list members like the change, others have pointed out its limitations, and one member  has suggested reverting to the original behavior with the idea being that members would need to check their Spam folders (however, this would not resolve the issue where providers like Yahoo do not deliver the message at all).

Your feedback is welcome so please share your thoughts on the list.

Meanwhile, if we discover any better Lyris configuration solutions we will post them here for you to consider.

DMARC-affected services

When sending via mailing lists such as WesChat:

Affected Senders
Messages may not be delivered to services at right when sending from: 
Affected Recipients
Messages may not arrive from services at left when receiving at:
AOL (incl. Compuserve) AOL (incl. Compuserve)
Yahoo Comcast
Gmail
Hotmail (incl. Outlook.com)
Yahoo

Source: PCWorld.

howto_alert_751:05 p.m.: iModules has provided this update in an email to clients:

Earlier this morning, between 10:55 a.m.–11:05 a.m. Central time, U.S.-hosted iModules clients experienced an unscheduled, 10-minute outage affecting access to non-admin, secure servers. The outage was caused by a dropped connection during a routine network review. All sites are now fully operational. We apologize for any inconvenience this outage may have caused.

12:10 p.m.: Wesconnect experienced a brief outage today between 11:55 a.m. and 12:05 p.m. Eastern. We’ll provide more information once we have it. Apologies to the inconvenience caused by anyone using the site at the time. Status information can be found at status.imodules.com.

[email]

Wesleyan email will be unavailable on Saturday, June 21 from 7:00 a.m.–noon for scheduled maintenance. Access to the alumni E-Portfolios (WesNet and Wescareer) will also be unavailable. During this period ITS will be performing hardware maintenance in Wesleyan’s data center. ITS advises that any information that needs to be communicated during the maintenance window will be shared on their Facebook and Twitter streams.

Neither Wesconnect nor the Alumni Mobile App will be affected by this outage.

If you have any questions about the outage please let us know.

[lock]

What is Heartbleed?

Many Wesleyan alumni have probably heard about the Heartbleed vulnerability which was announced on April 7. “Heartbleed” is a nickname that refers to a serious flaw in a popular open source security component known as OpenSSL. NPR’s story from April 8 provides an overview of the problem. For a more technical angle see the blog post on Heartbleed by security expert Bruce Schneier. (A popular web comic called xkcd explains the bug visually.)

Wesleyan systems

On April 9 Wesleyan ITS sent an update to the campus community with information on how Heartbleed relates to Wesleyan:

ITS reacted swiftly to the announcement of this threat. We swept all servers and, within 24 hours of this coming to light, completed patching systems by noon on April 8. Our concern for Wesleyan usernames and passwords is very low.

You can read the full text of the message on the ITS System Announcements blog. This response prevents the possibility of information leaks due to Heartbleed in future.

Wesconnect is unaffected by this vulnerability because iModules does not use OpenSSL in its product.

Recommendations for alumni

1. Change your Wesleyan email password

We recommend that alumni change their Wesleyan email passwords as a precaution. Changing your password ensures that you’re no longer vulnerable to any information leaks that may have occurred due to Heartbleed prior to April 8. It is not necessary to change your Wesconnect password, though it never hurts to do so!

2. Change other important passwords

As well as updating your Wesleyan email passwords, everyone should consider updating other important passwords such as other email accounts, online banking accounts, social media accounts, etc.

Update (April 18): software company AgileBits released a handy tool called 1Password Watchtower that helps you check how vulnerable any website is to Heartbleed.

3. Consider using a password manager

We know that choosing and remembering passwords is universally unpleasant to humans! So consider using software that will suggest and remember your passwords for you. This will increase your security and make it easier to use services on a daily basis.

Modern versions of web browsers such as Firefox (how to), Chrome (how to), Internet Explorer (how to) and Safari (how to) have password management features that you can turn on in Options/Preferences.

You might also like to check out dedicated password management tools like LastPassPassword Safe and 1Password.

Get in touch

Let us know if you have any questions and we’ll point you in the right direction.

[lightbulb]The CAPTCHA widget that appears if you mistype your login credentials has been updated and moved closer to the top of the page. The new version asks for two numbers instead of two words. We think these changes will make it easier to notice the CAPTCHA if it pops up, and to provide the correct answer. Here’s what it looks like:

[Wesconnect login page]

New CAPTCHA widget (click for a larger version)

[wrench]

Wesleyan Webmail (also known as Squirrelmail) will be undergoing scheduled server maintenance on Tuesday, February 25. The maintenance window is 5:30–6:30 a.m. Users should not notice any major disruption to their email service, however it is possible that the system will be unavailable at some points during the maintenance window. Alumni from the classes of 2009 and later will not be affected. As always, if you have any questions please let us know by submitting a ticket or writing to alumnihelp@wesleyan.edu.

RESOLVED — February 21, 2014

[gear]

This issue is resolved. Wesconnect is working normally. We experienced typical traffic volumes this week and the site has performed as expected, with no further outages. For more information on the recent outages please see Moving Forward by iModules President Fred Weiss (Feb. 18), and A View From the Trenches by Director of Product Development Steve Williams (Feb. 21).

February 17–20, 2014

Wesconnect is working normally. We will keep a close eye on site performance and mark this issue as resolved once we are confident that the website is functioning normally under typical weekly traffic volumes. Please send any questions via the Alumni Helpdesk Support form, by email to alumnihelp@wesleyan.edu or ask us on Twitter or Facebook. We apologize for the inconvenience to our alumni, students, faculty and staff caused by these connection issues.

February 16, 2014

10:01 a.m.: We pointed DNS for wesconnect.wesleyan.edu back to iModules’ servers yesterday afternoon and Wesconnect appears to be operating consistently since that time. We will keep a close eye on availability and performance and mark this issue as resolved once we are confident that all Wesconnect traffic is successfully reaching iModules’ servers, and that the website is functioning under typical weekly traffic volumes.

February 15, 2014

5:21 p.m.: iModules has identified the root cause of the outages that have affected Wesconnect availability since the DDoS attack on their servers on February 3. We will soon switch DNS for wesconnect.wesleyan.edu back to iModules’ servers. Here’s part of the resolution announcement:

We have successfully identified and corrected the issue causing the outage during the last few days. While a more in-depth report on the issue will follow, to summarize, we had networking environment configurations that were sensitive to traffic volumes coming from individual source IP addresses. When we made the emergency switch to our DDoS filtering service, we essentially consolidated source IP addresses, and there were downstream configuration issues that blocked most traffic and caused the outage. We have been able to recreate the issue and confirm that our change resolves it.

iModules plans to monitor their new networking configurations closely but they are confident that this issue is now resolved. We will also monitor closely and will mark this issue as resolved once we are confident that all Wesconnect traffic is successfully reaching iModules’ servers and the website is functioning normally, under typical weekly traffic volumes.

8:45 a.m.: While Wesconnect availability has improved since Friday morning the root cause of the outages has not yet been identified. iModules continues to investigate. We are passing traffic through to the iModules webserver, but if their host does not respond after 30 seconds we are rerouting traffic to the Wesconnect Outage page. iModules will send an update on progress later today.

February 14, 2014

Please send any questions via the Alumni Helpdesk Support form, by email to alumnihelp@wesleyan.edu or ask us on Twitter or Facebook. We apologize for the ongoing inconvenience to our alumni, students, faculty and staff.

1:11 p.m.: After a period of consistent uptime this morning, yesterday’s intermittent Wesconnect access problems have returned. iModules continues to investigate. We are currently trying to pass traffic through to the iModules host, but if the host does not respond after 30 seconds we are rerouting traffic to the Wesconnect Outage page.

Here is some additional detail from the most recent iModules status communication:

We are proceeding down parallel paths to resolve the situation. The first path is that we have engaged additional resources and expertise to evaluate the situation and ultimately, resolve the outage in our current environment. The second path is looking at creating an additional environment for our U.S. client sites to transition to in the situation that the current issues are not solved in the near term.

We appreciate how frustrating this is for our users and apologize for the ongoing inconvenience.

10:04 a.m.: The Wesconnect outage continues. From the latest iModules status message:

After temporary site availability this morning, the outage affecting U.S.-Hosted Encompass sites continues as of 8:05 a.m. Central. We are actively investigating the cause and will provide updates as they become available.

7:33 a.m.: iModules technical staff believe they have resolved the problems leading to the outage and maintained consistent uptime on their hosts for several hours, so we are now routing traffic back to the main website. Here’s part of a recent email from iModules describing their work overnight:

Yesterday’s outage appears to be due to a particular mix of the load put onto the system between our firewalls, the public internet, and the devices that sit between them. We worked closely throughout the day yesterday and into the evening with multiple partners – our co-location facility, attack mitigation vendor, fire-wall provider, and load-balancer vendor, to review traffic and configurations among and between the systems. We ran sustained tests overnight that exceeded our typical traffic and are no longer able to recreate the circumstances that caused the outage. We are bringing in additional expertise to assess and evaluate the outage.

We will continue to monitor throughout the day and will provide any further updates here, as needed.

February 13, 2014

10:36 p.m.: iModules continues to work on the problem. No resolution as yet.

4:14 p.m.: We are now redirecting all Wesconnect traffic to an information page explaining the outage. When we are confident that service has been restored at iModules end we will re-route traffic to the usual website.

2:30 p.m.: We don’t have any additional information to report except that iModules continues to investigate. Here’s part of a recent email from iModules on the outage:

There are many potential scenarios that might be causing the current outage and we are actively working with our DDoS mitigation provider, firewall provider, and hosting facility to narrow down the problem and a resolution.

Please send any questions via the Alumni Helpdesk Support form, by email to alumnihelp@wesleyan.edu or ask us on Twitter or Facebook. We apologize for the ongoing inconvenience to our alumni, students, faculty and staff.

11:30 a.m.: Wesconnect, the alumni website, is responding sporadically. On campus we are seeing persistent “connection dropped by server” messages. Our platform vendor iModules is aware of the problem and is working to resolve it. We’ll post an update here when we know more. In the meantime, more information may be available at status.imodules.com.

Older Posts »

Log in