Re: Plusnet - praise where it's due

Mortimer wrote:
"PlusNet Support Team" <support@xxxxxxxx> wrote in message news:468382ec$0$8752$ed2619ec@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Mortimer wrote:
"PlusNet Support Team" <support@xxxxxxxx> wrote in message news:4683775b$0$8721$ed2619ec@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Alfredo wrote:
Is there a way of training your spam filter? Maybe by getting customers to forward spam which has not been trapped to a "this is spam" email address so the filter gets refined.
Yes, that's possible. Have a look here:-
http://www.plus.net/support/security/spam/spam_protection_guide.shtml?supportb=security_t5spam#5

Excellent. I tend to use Mailwasher to delete any received spam that has got through the filter, but I might start forwarding it. Is the address specific to PlusNet or will it also work for Force 9?

You use the PlusNet address regardless of the VISP you are on so no it's not specific to PlusNet:-

http://www.f9.net.uk/support/security/spam/spam_protection_guide.shtml?supportb=security_t5spam#5

When you say about "forward[ing] inline with the full email headers", does that mean that for Outlook Express I need to view the message source and paste that into a new message to spam@xxxxxxxxxxxxxxxxxxxxxx? I'd have thought that forwarding as an attachment would work equally well because the headers would preserved that way as well - wouldn't they?

Yes, but DSpam doesn't handle emails that are in this format particularly well.

It's a bit cumbersome at the moment but we're working on a SquirrelMail plugin that will give you a 'Spam' and 'Not Spam' button in webmail that will do all the hard work for you.

Now that sounds really good. Anything that can refine the spam filtering has got to be a good thing.

It should solve the problems encountered with forwarding using OE.

Where they could possibly improve is in the early reporting of faults: quite a few times I've encountered a problem, found that the status is still green and yet when I raise a ticket I get a response "yes, we know about this" or "we'll flag it as an issue when we know the scale of the problem", rather than flagging it *first* to forestall support calls and tickets and then providing timescale info as it becomes available.
Agreed, and we'd like to do this. There's a couple of deterrants, one of which is the somewhat lacking Service Status tool that takes a while to propogate and is a bit cumbersome to use. There's been a new on in development for a while but it's been in the making for some months now as it's not high priority. There's a prototype linked from the following blog post:-
http://community.plus.net/webportal/2007/03/06/new-service-status-tool/

As far as it's possible to tell from the mock-up, this looks good.

If I'm honest, we'd be flagging a *lot* of problems via Service Status if we opened a thread each time we saw one or two single user issues with customers' accounts. We need to be careful not to dilute the feed.

Good point. I suppose you could in theory do some fancy network traffic monitoring, looking for incoming traffic from customers *to your own servers* and matching against the corresponding response: if there's no response within a stated time, that may indicate that the server has failed.

We've got quite extensive internal monitoring. Most of which is based around NAGIOS (http://www.nagios.org/). We also graph most of our servers/services too. Some can be seen on the portal:-

http://www.f9.net.uk/support/network_performance/index.shtml

Going off at a tangent slightly, I think you need to look at the Help and Support pages and make a clearer distinction between "how do I configure things" which can be handled by stages of FAQs and "I think you've got server problems" which need to bypass FAQs and get straight to raising a ticket with as little faffing about as possible.

True, but in any help-desk environment most of the 'server problem' reports would actually end up being the result of end user misconfiguration or some other local issue. I know that sounds like a bit of a glib generalisation but generally speaking it is true.

The option to raise a ticket is only 4 clicks away from our home page which I don't think is too bad.

For email, you might also sub-divide into "customer cannot contact POP/IMAP server" and "customer can contact POP/IMAP server but no new email is arriving into mailbox from the outside world" in your reports. Likewise for Usenet.

Now there's an idea I like! We have a broadband fault troubleshooter for ADSL faults, but nothing quite as specific for email, ftp or any of our other services. It would be great if we could implement similar tools for those.

You mentioned about SquirrelMail. What are the long-term plans for webmail? Will you continue to use SquirrelMail or will you be replacing it with something else? If you change to something else, make sure it matches SM for speed and usability (eg ability to tag all messages for deletion in one go).

I'm not sure on the long-term plans for Webmail at the moment. Rest assured though we wouldn't want to take any features away that you've grown accustomed to.

For me, the only two improvements that you could make to SquirrelMail are:

1) Display time as well as date on the one-line-per-message view of a mailbox.

Couldn't see what you meant by this at first as both the time and date are shown. Then I realised that only recent messages appear to be displayed like this whilst older ones just have the day and year.

2) Allow entries in the address book to be imported from an OutlookExpress .wab file or else from .vcf files for each contact, so it's not necessary to retype from your own address book to SquirrelMail's.

Good idea. I wonder if there are any plugins that would help achieve either of these two things?

http://www.squirrelmail.org/plugins.php

Kind Rgds,

--
|Bob Pullen Broadband Solutions for
|Support Home & Business @
|PlusNet plc. www.plus.net
+------ PlusNet - The smarter way to Internet! -----
.