If you have recently upgraded to MailStore version 9 you may not be aware that the new maximum number of messages that an archive can contain has now been increased from 500,000 to  5,000,000 messages. If you are like me and you have found yourself with a collection of much smaller MailStore message archives it is now much easier to merge these together into a smaller number of larger archives.

As with a lot of new technologies the real power comes from when they are used by the masses. Sender Policy Framework or SPF is no longer a new technology and is generally widely used to help preserve email domain reputation for large organisations, but it's as well-known about in the Small to Medium sized business end of the email market. Spammers know this and have started to target domains that do not have valid SPF records as they can most easily be used to spoof and send spam claiming to be from valid companies. Often these types of spoofed email are used in phishing attacks to then harvest more valuable data, so the smaller companies that can adopt the use of SPF the better.

You've probably picked up in the IT press that the developers of TrueCrypt, currently integrated within BackupAssist, are no longer actively developing the software. A recent independent audit published by iSEC has not identified any security flaws in TrueCrypt, however at some point in the future, it's likely vulnerabilities may creep into it. DISCLAIMER: We're not suggesting you need to switch away immediately and ultimately fully expect to see a new encryption application integrated into BackupAssist. However....I like to tinker...

In most deployments of MailStore we recommend your journalling job is configured to archive a selection of journalled or 'copied' emails for all your users. This type of job is designed to interrogate each message that it archives and look for headers that it can match to decide which user's archive it should store the message under. In a perfect installation where all of your MailStore users have been setup correctly, every journalled message should find the correct corresponding users archive. But it is common to overlook some addresses and you may find email appearing in the general 'Unknown e-mail archive' instead.

If you're not already familiar with Rsync, it's the method (or 'protocol' to be posh about it) that BackupAssist uses to send data off-site to locations such as NAS boxes or to other servers. QNAP make a NAS device that's popular with our customers and this week I came across an issue with backing up via Rsync to it that I've seen before... ...cue helpful (hopefully) blog post!

It's a bit of a niche technical one this but as I've had several reports of it recently I wanted to share this one with you in case it helps. If you're an MDaemon customer you may have started to see the following errors in the SMTP (Out) logs when trying to send email to some specific external hosts... “SSL negotiation failed*,*error code 0x80090326” What this boils down to is an issue where MDaemon and the remote SMTP server cannot find a common set of SSL ciphers that they both have available to use.