Thursday 15th January 2009: It's been some considerable time since we last updated the way that scores are calculated. As this affects your ability to compare your site over time and how you stand in any of our surveys that your site might be part of, it is not something we would consider doing on a regular basis.

Reclassification of failures

These items have been changed to the severity of a "Functional" problem (i.e. the system has a low tolerance for these types of problem and they will affect your score)

• "Compromised" (red) email server problems
• Broken "mailto" links
• Pages with no title
• file/html/noframes
• url/fetch/badcookie***

*** url/fetch/badcookie now always counts as a Function problem, but it is not checked on external links, so the issues we encountered with Nedstats, Doubleclick, etc, should be removed

These items have been changed to a lower severity, similar to a "Code Quality" problem (i.e. the system has a higher tolerance for these types of problem and they will have a limited affect on your score)

• "Impaired" (amber) email server problems***
• Pages with no meta "description"
• Other meta-data problems (e.g. longtitle, badmeta, etc)
• "bad character in URL" type problems (e.g. file/url/badpath)

*** the issues we encountered with some email security services such as MessageLabs previously caused scores to be impacted negatively due to the email server configuration on their backup servers being non-standard. The new email service assesses these types of problems as "impaired" rather than "compromised" so the impact on scores will now be negligible.

Performance

We have introduced a new calculation to better represent the actual download speed from a website. The new data shows higher download speeds for most sites.

To take account of this we have increased the speed thresholds in the benchmarks used to calculate the Performance score. Most sites will not see dramatic changes in their Performance scores but when looking at the detail there may be a significant increase in the download speed figure.

Email testing

The new features of the service look at the email server infrastructure behind your email addresses to make sure that they are configured correctly and that the servers will receive emails.

We have come across numerous email server infrastructures that have either been incorrectly defined to DNS or are mis-configured and wont actually receive emails. Email servers can have different roles, e.g. they may be primary servers, secondary servers, load balance servers or fail-over servers. Each would be defined and configured differently.

This adds another layer of sophistication to our audits and ensures that you are confident that your email infrastructure is defined correctly and configured correctly. We'll also report any availability issues or intermittent type problems if they occur during one of your audits.

Site enhancements

The Directory map feature of the Inventory section is now "clickable". By default it loads as a collapsed list of directories, each sub directory can be expanded to display its contents. By making this change we have resolved a problem where sites with a deep directory structure extended off the page.

Based on customer feedback, we have made the font colour on our web site darker, in order to improve readability through greater contrast.

Sitemorse testing of email addresses that are handled by MessageLabs often produces problem diagnostics. These are due to the way MessageLabs' servers handle mail transactions. We are not saying we agree with the outcome of our discussions, or the individual setup at MessageLabs we are merely seeking to explain why the errors occur.

When an email is sent to your domain, the sending server uses the Domain Name System (DNS) to look up your mail servers. Usually, there are two or more servers listed, with associated priority values - typically a "primary" server and one or more "backup" servers.

The DNS will always send mail to the primary server. The backup servers are there to accept email when and if the main server is unavailable for any reason, and to forward it on to the main server when it returns to service. The backup servers will, in a conventional setup, accept incoming email which they then forward to the primary server. This conventional setup allows Sitemorse to check that both the primary AND backup servers are available, functioning correctly and are configured correctly. Your primary and backup servers are integral parts of your email service which is why we check both of them.

The servers that MessageLabs list in the Domain Name System as "backup" servers are not true mail servers. They never accept email, but simply always return a "temporary failure" error code. (this allows them to reduce the amount of Spam they have to handle) This error code is what is shown in the Sitemorse diagnostics.

If you require further information, you should contact your MessageLabs account manager to discuss your specific setup.

We have further details of mail setup online at http://www.sitemorse.com/d/howto/emailtests.pdf