Feed on
Posts
Comments

[info]This week’s winter storm may cause power disruptions in Middletown. In the event of a power outage Alumni Helpdesk staff may need extra time to resolve support requests. Please check the Wesleyan homepage for updates about campus conditions. We’ll do our best to keep you informed of any developments here on this blog, and on the Wesconnect Twitter feed.

[wrench]

The server that provides email for alumni from the classes of 2008 and earlier will be undergoing scheduled server maintenance on Tuesday, January 20 from 5:30–7:00 a.m. EST to perform system maintenance. Users will be unable to access their mail (whether by webmail, desktop mail client, or phone) during this 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.

[mobile device]Yesterday, Wesleyan launched a redesigned homepage at www.wesleyan.edu. The new design adapts to the screen size of the device loading the page, making it much friendlier on mobile devices. Main landing pages such as About Wesleyan and Academics have also been redesigned and the navigation bar from these new pages is in the process of being deployed across the main Wesleyan website. The project was a collaboration between the Office of Communications and the Department of Information Technology Services. In a separate but related project University Relations is also working on a mobile-friendly (“responsive”) redesign of Wesconnect that will launch later this spring. More information about the new Wesleyan homepage design is available on News @ Wesleyan. If you experience any issues with the new website pages please let us know and we’ll pass on your comments to the ITS New Media Lab.

2009 design

Fixed width

[screenshot of 2009 design]

2015 design

Widescreen view

[widescreen shot of 2015 design]

Narrow and medium views

[medium and narrow views of 2015 design]

[alert]Our users might have heard about the “POODLE” security bug that was recently discovered in the technology that helps to secure web pages (specifically in SSL 3.0, which provides the s in https:// on older web browsers).

To protect users’ personal data and transaction details University Relations’ vendors are disabling support for older browsers that use the affected technology. This includes IE6 (Microsoft Internet Explorer 6), IE7 (Microsoft Internet Explorer 7), and Windows XP.

Most users won’t notice a change, but anyone using the affected technologies will be unable to access Wesleyan’s secure pages for actions such as logging in to Wesconnect, registering for events, making donations, etc.

As an added precaution, we suggest that all members of the extended Wesleyan community (alumni, parents, and friends) test their web browsers and take the recommended steps to disable SSL 3.0.

If you have any questions or concerns please let us know and we will get right back to you.

Further information

Resolved as of November 17, 2014: with the release of Wesleyan Alumni 3.2.1 on Google Play today, this issue is now resolved. We tested on a Nexus 7 running Android 4.4.4 and were able to log in using LinkedIn. We could to set a PIN without any keyboard issues. (We had to clear the app cache and app data in Settings → Apps → Wesleyan because we were seeing the “Unfortunately Wesleyan has stopped” error after upgrading.) Please update your Wesleyan Alumni Android app to the latest version.

howto_wrench_75Keyboard issue

Some Android users who log in to the Alumni App using LinkedIn are unable to proceed on the PIN screen because of a keyboard bug. Developers are working on a fix and estimate that the update will be available in early November.

Work-around

Affected users can work around this problem by logging out of the app, and logging back in using the Email and Password method instead (see instructions).

Get some help

If you are affected by this issue and would like assistance, please let us know and we will get right back to you.

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.

Older Posts »

Log in