Strategy month

[fanf]

According to Our Glorious Leader the Computing Service's director, March is "strategy month" and we are supposed to come up with ideas. So, this is my long-term wish list. No restraint has been exerted in its compilation :-)

• Get the Chat service deployed!
  
• Hermes projects:
  
  • Re-do and improve the anti-spam and anti-virus infrastructure. This has three parts:
    
    1. Replace MailScanner with exiscan, so that we can scan messages at SMTP time, and reject those we don't like instead of discarding them. If we don't want to rely totally on ClamAV we'd need to replace McAfee with a better commercial AV scanner, because McAfee is not fast enough for non-batch-mode scanning; it's also pretty bad at promptly issuing new signatures. This would allow us to have a default SpamAssassin threshold (without the lost-email consent problems caused by the way MailScanner works) which in turn would help with our AOL problems.
       
    2. Allow per-user options at SMTP time, e.g. spam threshold, stricter sender verification, greylisting, etc. This requires some data-shifting infrastructure which I have made a small start at, and user-interface extensions to Prayer.
       
    3. Add a new component for per-user statistical spam filtering. This would live on the message store (with other per-user state), and hook into message delivery for initial filtering, and copying to or from the spam folder for training. Again we need user-interface changes to Prayer to present the results of the filter and allow users to train it - similar functionality to full MUAs like Mac OS X Mail or Thunderbird.
       
  • Shared folders. Requires a new IMAP proxy (like the Cyrus Murder) and changes to the replication system. Does Cyrus 2.3 have the necessary functionality?
    
  • Internationalized webmail. Replace (or run alongside) Prayer with some better-known software?
    
  • Finish the ratelimit project. Will require time to work on a user interface, so that it is sufficiently friendly. My current idea for how it would work requires the double-bounce patch mentioned below.
    
  • Deploy DKIM (server-side message signatures for anti-spam).
    
• Exim projects:
  
  • Improved hints DB infrastructure. The aim is to remove the performance bottleneck caused by whole-table locking, and make the back-end more pluggable so that we could have distributed hints databases. PPswitch would then act as a cluster with the machines sharing knowledge about other hosts on the net.
    
  • Concurrent DNS lookups during routing, to improve mailing list performance. I've done some work on this already.
    
  • Better handling of double bounces. If we can't deliver a bounce to recipient@domain, try postmaster@domain then postmaster@cam instead of freezing the message.
    
  • Finish the bounce address protection code.
    
• Service integration:
  
  • Kerberos. Proper single-sign-on! Users really hate typing in passwords.
    
  • Raven-authenticated webmail for more single-sign-on.
    
  • Mailing lists generated from Lookup groups. Lookup groups generated from data in CamSIS/CHRIS.
    
  • Web presence: an extension to the chat service which allows other Raven-authenticated sites (such as lookup and webmail) to display a presence icon next to a username. If I am looking at your lookup page and you are on my chat buddy list, then I can see whether you are currently on-line and I can click on the presence icon to chat with you. Depends crucially on transparent single-sign-on. In particular, the default for Raven at the moment is confirmed sign-on, which isn't transparent enough.
    
  • Short URL service, like go.warwick.ac.uk, which doesn't host content but instead redirects to full URLs. Mainly for use on printed material such as business cards, academic papers, posters, press releases, etc. Namespace divided into ~CRSID for homepages (using data from lookup) and ad-hoc names managed by user-admin. Could include societies.
    
• Web stuff, etc.:
  
  • Blogging service.
    
  • Web forums.
    
  • The two could be aspects of the same thing (e.g. Livejournal's blogs and communities).
    
  • Society information in Lookup, similar to the institution information.
    
  • More effective use of talks.cam.ac.uk.
    
  • Shared calendars / meeting manager.
    
• Networking:
  
  • Make it easier for depts and colleges to host conferences. e.g. at the Durham UKUUG I was given a short-term uid which gave me access to their PWF and wifi.
    

Comments

[mouse262.livejournal.com]

Raven-authenticated webmail for more single-sign-on

May as well, no point having a significant number having to type the same password in twice at the start of each day.

Do you get to spend all of April discussing each others stratergy lists.

[fanf]

It will be interesting to see what the result of this exercise is.

[http://users.livejournal.com/_nicolai_/]

That which passes for minds in the unwashed masses cannot comprehend ~

[sjmurdoch.livejournal.com]

Namespace divided into ~CRSID for homepage

Please don't use "~". I shudder to think how many times I have tried to explain what that character is over the phone and where it is on the keyboard (it varies).

[fanf]

Good point. However, remember that (in the words of OGL) this is "strategic vision" and therefore I can say what I like regardless of feasibility.

[rao.livejournal.com]

Just to provide an extra datapoint regarding AV scanners, we've had memory leaks and deadlock issues with SophosAV/Sophie under Linux. No issues with ClamAV.

[fanf]

A good point, and something I am worried about.

One of the nice things about MailScanner is that its batch proceccing model is very robust. Any SMTP-time replacement is going to need a lot of operational tuning :-(

[rao.livejournal.com]

We're handling ~1.4M messages/day with exiscan and ClamAV across six frontend servers and have capacity to spare. Minus some magic regarding distributing ClamAV updates within our cluster, our ClamAV configs are stock. We're considering new commercial scanner options as well to augment ClamAV.

[alsuren.livejournal.com]

The Chat Service is something I would quite like to get involved in.

BSD(?)+Jabber+Python == Great learning opportunity

There are also a *lot* of GoogleTalk users floating about Cambridge, and a few of them have even expressed an interest in getting @cam.ac.uk addresses. I've told them to wait and that I'd give them info about it when it was going into a testing stage, but the project seems to have stagnated. Would an extra pair of hands be of any use?

[fanf]

Yes, it has been stalled for a while, partly because of depressing delays waiting for management and partly because I have been busy with other things. I hope to get back to it soon. Anyone who is interested is ancouraged sign up to the mailing list via http://lists.cam.ac.uk/mailman/listinfo/cs-chat-users

[cesy.livejournal.com]

This does sound exciting, particularly the service integration and web stuff, and the chat thing will be very useful. When might some of these things be likely to happen?

[fanf]

Probably not for years. This is "strategic vision" and therefore not to be believed.

[bens_dad]

* Replace MailScanner with exiscan
Reject at SMTP time is good.

* Kerberos. Proper single-sign-on! Users really hate typing in passwords.
* Raven-authenticated webmail for more single-sign-on.
* Make it easier for depts and colleges to host conferences. e.g. at the Durham UKUUG I was given a short-term uid which gave me access to their PWF and wifi.

JRS (neé nee Lin) http://www.ja.net/services/network-services/roaming/ (and EduROAM) seems to be the way to do this.

* Kerberos. Proper single-sign-on! Users really hate typing in passwords.
* Raven-authenticated webmail for more single-sign-on.

I guess I'm scared off Kerberos by Kerberos-4 (and the fact that Microsoft have picked up Kerberos). I'd by much more interested in a Radius server which authenticated against the Raven password database. Linked into JRS I see this as solving a lot of my authentication issues.

[fanf]

The whole point of Raven is to reduce password promiscuity. Radius would be going in completely the wrong direction. Kerberos support is much better now than it used to be.

[bens_dad]

Reducing the number of times a password is entered is certainly not the whole point of Raven, if that is what "password promiscuity" means. It isn't even a necessary feature of Raven, I can make Raven ask for my password for every site I visit, should I wish.

Sorry, I should have said 802.1x + Radius, which does restrict the applications for which it is a solution, but does mean that, as I understand it and with suitable EAPs, the service provider (web site or access point) doesn't get its hands on the unencrypted password. I'd forgotten that this last point may not be true without dot1x.

[fanf]

No, I mean giving the same password to multiple services. And .1x is network access authentication not application authentication, so it isn't comparable.

[bens_dad]

The way I see it Raven *encourages*, or even forces, sharing of passwords between services.

From best to worst for *technical* security:
1 Every service has a distinct password
2 Every password database has a distinct password
3 The same password appears in multiple password databases

In reality maintaining lots of distinct databases has risks to so 1 may result in more breaches than 2, although the damage from a single breach is much greater in 2.

Raven stops 3, which reduces password promiscuity, but it also stops 1, so it is anti "password monogamy".

Your experience is probably better than mine, so if you think that there is very little monogamy left to protect, Raven is good.
--
My authentication world is more about network access than about applications (although I concede that login *is* an application).

[fanf]

People use the same password all over the place. Building your security model on the assumption that the weakest parts (people) are behaving like security-paranoid geeks is foolish.

The effect of your model is that each person's password is separately transmitted to all places. (This is what I mean by promiscuity.) A security problem in any place compromises all of them. The problem is not just the database: an application compromise can allow password sniffing.

The Kerberos/Raven model is that there is one password which is transmitted to one place. A compromise in any place only compromises that place and does not compromise any passwords, unless the authentication server is compromised.

Furthermore, single-sign-on is attractive to users because they have to log in far less frequently. If more users were aware of the Raven unconfirmed login option, they would use it. People want convenience more than security, so you need to make security convenient if you want to make it popular. This is one reason that ssh took over from telnet: more functionality as well as more security.

[(Anonymous)]

> Short URL service, like go.warwick.ac.uk, which doesn't host content but instead redirects to full URLs

Please, no.. multiplicities of namespaces will only encourage people to be even lazier when implementing URL structures.