24
Aug
Are your files too big to send via email? Three possible alternatives…
It's generally accepted that a message size of around 20MB is too large to send via email, and you'll find in lots of cases that mail servers will actually refuse to accept files that are this big.
There are, however, many servers that don't limit the message size, which means if you try and share that high-quality 150MB video of your cat performing Dancing Queen, both your network and the recipient's will work overtime trying to deal with it.
12:13 /
MDaemon
Another week, another set of new features to look at in the beta version of MDaemon version 13.
Let's look at one of the more useful business features of MDaemon, the ability to capture email arriving on group email address such as sales@ and support@, and storing them directly into public folders. This feature allows a group of sales or support staff to monitor the public folders and take ownership of the emails, sharing the workload.
One of the more common customers support calls i get relates to MDaemon suddenly sending vast amounts of spam email. This floods the outbound Internet connection and everything crawls to a halt.
Secondary to this the server's public IP address can get listed on various external SMTP blacklists which the customer then has to request removal from.
I mentioned ActiveSync policies in 
Over the last few weeks I've been experimenting with the latest Beta editions of MDaemon version 13 and thought it'd be beneficial to share some of the great new up and coming features you can expect to see in the release.
Just before I wet your appetite with the first of them - don't forget, if you're interested in getting involved in the MDaemon beta test process you can apply to join the community by registering 
We have recently seen an increase in customers wanting to bring a large selection of PST files into their MailStore archive. It's quite common for people to create local PST file archives of their own email and historically this was a common way to reduce the data within the mailbox on their mail server. The problem we see is that over time many users build up multiple local PST files and as these are scattered around on various client machines it gets very difficult and costly to keep them all backed up. If you also consider in this scenario there is also no way for users to search each others archive it makes it very difficult to meet compliance requirements.
As part of ongoing improvements to our own network, I recently revised the way we approach backing up the SQL database that underpins our main company Web site. We currently host the web and SQL server in a local data centre and were taking off-site daily backups using a combination of BackupAssist and the Rsync add-on. This was adequate for restoring a snapshot of the website or database to the previous day, but I wanted to improve the frequency of our backups given how often the database is changing as we take orders throughout the day. Luckily BackupAssist was there to help!
I came across an issue on a support call the other day I thought worth sharing as it's bound to be something a few of you will see too.
In the last couple of weeks I've come across a few customers with MailStore installations where they've experienced corruption of their archived data due to either a damaged disk, RAID failure or power outage for example.
All of these situations are of course completely outside of MailStore's control but they're ones where the only practical recovery method is to rebuild from a previous backed up version of the MailStore data.