Categories
Announcements Q&A

Mail Mirroring as “Email Insurance”

On a semi-regular basis we receive a call or email for help because something has happened to someone’s email: messages were accidentally deleted, their mail server had a config change and rejected everything or accepted and silently discarded messages. Although we do maintain disaster recovery backups, we charge for staff time hourly to try and find and restore a few files without any guarantees to how far back we can look, and that’s only for IMAP; with POP3 the client can remove messages as they are received which never make it into a backup window. Then there’s the SMTP queue: the queue is constantly changing, but since we’re not secretly storing copies of messages just in case, there’s almost no chance to recover anything. In the end, the messages are gone and there’s no simple way to recover them, if at all.

That’s where the Mail Mirror feature comes in. included with every account. A mail mirror uses hosted mail boxes to store copies of messages that pass through our system. Mail Mirror allows you to define addresses or domains to “mirror” to a hosted mail box by storing a copy for backup or emergency access purposes. It uses the independent storage of a normal hosted mail box, which is not affected by the constantly changing mail queue. Once a message goes into a mirror it remains there until it expires based on how long you configure it to keep messages or is manually deleted by logging into the mirror box. This way, a mirror is self-maintaining and won’t keep growing in size. Mail Mirror is available to all accounts and only counts as hosted mail box storage, but for it to work it needs to be enabled before there’s a problem, not after.

Mail mirroring works with all types of mail configurations. You may never need to access your mail mirror, but just like insurance, it’s there just in case.

We’ve also posted a topic to our forums for any questions or discussion on this feature: Mail Mirror – A Helpful Safety Feature

Categories
Status

SA 3.4.0 on mail

Updates have been applied to mail.rollernet.us which include bringing SpamAssassin up to version 3.4.0. No issues were observed with mail2.

Categories
Changes

Secondary DNS Feature Realignment

We are working on feature realignment for Secondary DNS. Since it’s recently been migrated to paid-only, some options may still refer to requiring a paid account. Some of the paid vs. free features are are in the process of reevaluating are: TSIG support, master server settings, and zone file commands.

UPDATE:

  • DNS TSIG key support for zone transfers are now available on Basic level accounts.
  • A second master server is now allowed on Basic level accounts.

These features previously required a paid account of Personal or higher and were not available on free accounts. Since all Secondary DNS use now requires a paid account, these features have been realigned to an account level of Basic or higher.

Categories
Status

SA 3.4.0 on mail2

Updates have been applied to mail2.rollernet.us which include bringing SpamAssassin up to version 3.4.0. We’re going to wait before doing the same thing to mail.rollernet.us in case there’s any underlying problems that show up outside of testing.

Categories
Announcements Changes

Migration to HTTPS and Why HTTPS Everywhere

We’ve recently migrated all of our sites to HTTPS. The account control center and webmail will continue to use Extended Validation certificates like they always have, while everything else will now be using certificates from Let’s Encrypt.

Let’s Encrypt is a free, automated, and open certificate authority (CA), run for the public’s benefit. This helps create a more secure and privacy-respecting web.

Why HTTPS Everywhere?

Recently there’s a lot of buzz about moving to an HTTPS-only web. Previously, the cost of obtaining lots of HTTPS certs, having to manually install them, renew them, and pay fees for them discouraged using HTTPS unless needed. Let’s Encrypt solves many of those problems. Deploying HTTPS does take a little more effort, but there’s another reason why you should do it even if you think your site isn’t really that important to go encrypted: to help protect your visitors from their ISP.

We’ve personally experienced content hijacking with Charter, the local cable provider in Reno, NV (that now likes to be called Spectrum but we’re still going to call them Charter). Charter, for example, will hijack HTTP requests on residential and business coax service to provide content other than what you’ve requested. This is not the same as DNS redirection. HTTPS not only protects your privacy, but encryption ensures that the content you’ve requested passes between you and the site in its original, unaltered form without being rewritten or hijacked by your ISP, in addition to preventing eavesdropping. This is also known as a “man in the middle” attack. References: here, here, here, and here (plus we’ve seen it ourselves on home cable).

It is our opinion that an ISP altering content is entirely unacceptable for any reason. The only way we can truly protect ourselves is with encryption, not laws or depending on ISPs to “do the right thing”. Read more at EFF: Encrypting the Web.