Version: $Cambridge: hermes/doc/talks/2006-01-techlinks/talk.html,v 1.8 2006/04/24 10:22:42 fanf2 Exp $

Most of what I will cover is described in more detail elsewhere (links will appear below); I'll try not to repeat too much of it here and instead concentrate on the whys and wherefores.

Old news - basically the same as the talk I gave in October 2004, so you don't have to think back as far as Hague's baseball caps.

Recommended email software configurations for Hermes, including specifics for common clients. Contact mail-support@ucs.cam.ac.uk if you have questions about less common clients and we'll try to help.

Our recommended settings are designed to work anywhere, which is why they are different in many respects from MUA defaults - which have not yet caught up with RFC 2476 (but then neither have many email service providers). SMTP in particular is fiddly to configure correctly, which is a real pain in the neck.

Port 587 conforms with the official protocol specification, and should be used for most software. Port 465 has been obsolete for many years but is still used by MICROS~1 Outlook and Outlook Express.

Do not use the "optional security" setting, because that makes you vulnerable to password snooping.

Authenticated SMTP is necessary for remote access, and future anti-spam protocols are likely to work better for users that are properly authenticated.

Some MUAs default to insecure settings despite the fact that TLS is a mandatory part of IMAP, so don't trust them to guide you.

Most people who lose their email use POP.

Even though we don't like POP, we aren't going to require people to switch from POP to IMAP, just encourage it. Sadly switching is often awkward and not well supported by email client software.

Just for completeness.

Some potential problems you might encounter.

Beware excessively strict personal firewalls. You may have to give your MUA permission to make outgoing connections on unusual port numbers.

Do not configure anti-virus software to scan outgoing email, because this often causes them to stomp on encrypted (i.e. unscannable) connections. (I think Norton does this.)

Ensure you have the latest Office Service Pack and are patched up to date. Early versions of Office simply do not work. In particular for Office 2002 you need SP3.

Another thing to note is that you don't want "Secure Password Authentication" which is a MICROS~1 specific protocol.

You need the SSL plugin, which has not been universally distributed in the past. However it does come with the most recent version, 4.0.

Sadly Cyrusoft have gone bust so getting old versions of the plugin may not be possible. Talk to help-desk@ucs.cam.ac.uk to get more information.

This is something I didn't cover 15 months ago.

The folder path setting was necessary on the old Hermes system because the IMAP server's translation from folder names to filesystem names was very simple. It needed to be told where to store each user's email within their home directory.

The new Hermes system is much more intelligent and doesn't need the folder path setting. When it was deployed we added a backwards-compatibility hack so that it ignores an old-style folder path setting.

At the same time as the withdrawal of insecure access, we're withdrawaing this backwards compatibility support, so that we will not have to maintain the hack in the future.

The mua settings page explains exactly where to find the relevant setting. The terminology varies from client to client - folder path, path prefix, mailbox location prefix, server directory, root folder path, etc...

Increasing mobility of users, which we want to support, hence the need for secure authenticated SMTP. But also increasing use of insecure networks, especially wireless networks. No use protecting the SMTP session if we aren't also protecting IMAP! And since users tend to use the same password everywhere, a compromised Hermes account may lead to more serious compromises.

In this part of the talk I'll explain our plan for dealing with the reconfiguration campaign. I'll have a little to say about the last point in the next section of the talk.

The way we deal with the different classes of user is with a couple of lookup tables which list those users who are permitted to have obsolete configurations. The aim is to make these tables empty.

We're trying to minimize the amount of panic and disruption, so we aren't just cutting users off, and we're trying to put tools in the hands of support staff to make the job easier for them.

The simple part of the process is the ratchet. This identifies people who have not used insecure access to Hermes or the obsolete folder path setting in the last four weeks and removes them from the permission tables. This deals with people who have changed their settings but not told us; it also means that people who stop using Hermes for a long time will have to fix their configurations when they return.

This is the user interface to the audit software that I have written to help with this process. It is authenticated using Raven. It provides two views of the data: normal users can only see their own information, whereas IT support staff can see all the data so that they can help with the process.

Note that the information we are providing to you is personal data, so it should be treated with some respect.

The idea of the per-institution summaries is to see if computer officers will race to get their institutions to the bottom fastest :-)

The bottom part of secure.hermes.cam.ac.uk is the output of the audit script. Above this is a list of (most of) the tables that it manages.

There are some aspects of the way the audit script works that might not be immediately obvious.

We can't be sure when a user has fixed their settings - they might just be away from email for a few days. This is why the ratchet is fairly loose. It's also why we allow a few days to be sure that a user's claimed fix is correct (in line with trying not to cut people off).

The daily run means that its view is fairly coarse, so it's not great for getting useful feedback about the effect of configuration changes.

Because the audit script runs once a day, it's possible for it to send a reminder to someone the morning after they fixed their settings because of insecure activity before the fix. Therefore the "I've fixed my settings" link on secure.hermes.cam.ac.uk suppresses the next day's notification.

Delays to notifications may be indefinite if the user's settings have been fixed. The ratchet will eventually remove them from the permission lists.

If a user claims to have fixed their settings and it turns out they have made an error, then they are moved to the irritating end of the schedule.

We are planning to add users to the schedule an institution at a time, with a few days warning if we have a useful contact address (e.g. from probing.csx). This was suggested to us as being more convenient than adding users randomly. I.e. so that you get it all over and done with quickly rather than in dribs and drabs. (Though that may still occur owing to users having multiple affiliations.)

I haven't yet decided what to do with people who ignore reminders. I may escalate them to every half hour of insecure activity for a bit, before disabling insecure access anyway. Or perhaps I'll just send a tailor around to cut off their thumbs.

People keep coming up with ways to improve the process so if you have any suggestions, please email us. We haven't had much feedback yet.

Our aim is that by the end of summer, all access to Hermes will be securely authenticated. This includes all email sent via smtp.hermes. ppsw.cam will remain as an unauthenticated outgoing relay for the CUDN.

In the past we have not been clear about the difference between smtp.hermes and ppsw.cam, and this didn't matter much since they both offered pretty much the same service. However this has obviously changed, so I have written a document which should make things clear.

This was announced last term, and there is an entry about it in the CS newsletter.

We explicitly allow people to use other addresses with Hermes, such as departmental addresses or personal addresses. Hermes ensures that the sender is properly identified.

Example users of ppsw.cam.ac.uk include CUS and lists.cam.ac.uk.

I have made an annoucement about my plans for rate limiting, but at the moment I am still in the planning stage. It is not yet deployed.

The aim is to deal with spews of email from compromised web servers, or in case a Hermes account is compromised and used to send spam. (They're a juicier target now that they can send via Hermes from anywhere.)

The original plan was to set the limit to cover most uses and have a manually-maintained exception list of known bulk senders. However there turns out to be MUCH more bulk email than I anticipated. Theatre publicity, alumni offices, tutorial offices, etc. Our server's reaction would also not have been very forgiving of crappy software.

Instead I am designing a user interface to deal with the odd cases, so that we can distribute maintainance of the exception list, and I'm investigating ways of quarantining instead of trying to delay bulk email.

More news when I have made more progress.

Bulk email sent through the list.cam.ac.uk won't be affected by the rate limiting :-)