We know Apple users are passionate about their devices as much as we are passionate about offering high quality email hosting services. Our Imageway staff members have been long time fans and users of Apple based software and hardware. Since we have always appreciated the diversity Apple brings to the computer world, we wanted to provide the best email hosting services to the Apple community of users. We feel we have achieved this over the 20+ years we have been in business by consistently improving our services to support Apple based software in every way possible. The areas where we feel we offer the best email experience to Apple users are in the following areas:
Many companies package their services as free or low cost and then take your personal information as payment. Apple has treated privacy as a fundamental human right, and made it one of their core values. Since we respect and agree with this sentiment, Imageway has always been a company that takes your privacy seriously. Since we own and manage our own hardware computer systems, none of your data is stored on or shared with any 3rd parties. Our hardware systems run in a secured data-center, and not on any of the cloud services such as Amazon AWS or Micorsoft Azure. There are no 3rd party advertisements of any sort on our services. We do not obtain or track any data except for what is required to offer our hosting services to you. We will only release data to a 3rd party as is required by law. Our computer servers are located within the local geographic area, and not spread all across the world in various jurisdictions. Lastly, by using advanced security methods, we assure your data is hardened against illegal spying attempts. We offer SSL encryption for all of our service communication protocols to ensure secure transmission from point-to-point. We also provide the ultimate email security by offering end-to-end email encryption without the use of plug-ins (works with all devices, and all email clients).
To provide the highest level of reliability we start out by using the same rock solid operating system core that MacOS uses, UNIX. Our systems use enterprise hardware that was built with redundancy in the areas of power supply, firmware, memory, CPU, and I/O. For our data storage we use RAID 10 and ZFS for the greatest storage reliability and perform backups of this data nightly. Our hardware systems are housed in our own data centers with redundant UPS and network connectivity. Lastly, we have multiple data centers geographically separated, with all the data storage being sync’d between them. For more information about our service reliability please click here.
On top of our UNIX OS based foundation we use the most optimized software on the market for our email services to provide optimal speed. Read access to the stored data uses a combination of RAM, SSD, and HDD tiers. The filesystem RAM storage is very efficient due to using ZFS ARC caching. The ARC functions by storing the most recently used (MRU), and most frequently used (MFU) data within RAM for the quickest access possible. When the RAM cache becomes full it goes to the SSD, and then eventually to the HHD. This combination of highly optimized software and I/O access provides the highest speed possible when it comes to accessing email that is stored on our servers.
All of our supported email protocols support SSL/TLS to provide encrypted communication channels between clients and servers. For example, if you send an email to Gmail, our system will create an encrypted IMAPS/POP3S connection to your email client, and then the email will be sent using SMTPS between our mail server and the Gmail server. Additionally we provide free SSL certificates to all our customer email domains we host.
For login security we support two factor authentication (2FA). This requires you to use either “Google Authenticator” or “Authy” on your iOS mobile device to generate the code required for login. Additionally, we support 2FA for IMAP, POP, and SMTP that works with any email client. If you find it a hassle to manage the 2FA code entry using the email client, you can also create application passwords which can be used for specific applications. For more information about 2FA support please click here.
Instances where you require the highest level email security, we provide end to end encrypted email support that works in any email client without the need of plugins. For more information about our end to end email encryption solution please click here.
We have gone to great lengths to support the main methods used for communication by the included clients in MacOS and iOS (Mac Mail, iCal, and Contacts). When it comes to email synchronization support in Mac Mail for MacOS and iOS, we support IMAP(S), POP3(S), and SMTP(S). Calendar synchronization with our systems uses CalDAV(S). Lastly, contact synchronization with our systems uses CardDAV(S). Since iOS doesn’t support IMAP IDLE to provide push based email, if you require push based email then we provide ActiveSync(S) support which will also sync calendar and contact data. The “(S)” designates the availability of the encrypted version of that protocol.
If you don’t like the Mac Mail, iCal, and Contact applications included with MacOS then we can offer an alternative solution. We have partnered with the company that we feel provides one of the best email clients for MacOS called eM Client. If you sign-up for our standard or professional hosting package and pay using a yearly payment method, we will provide you free licenses of eM Client for your own use with our hosting. For more information about eM Client as an alternative email client please click here.
Lastly, we value legacy support for software and devices that use our email hosting. Just because your device is old shouldn’t mean your the services for that device have to stop working for it. We have supported email protocols that date back to 1982, and plan on supporting these methods of client communication into the future. Some companies will depreciate client communication methods that make your device obsolete on any given day. Rest assured, here at Imageway we want to make sure our services continue to work on your devices, regardless of how old they become. For more information about our legacy device support please click here.
Junk Mail (Spam) prevention
We utilize all the best spam prevention methods to provide the most spam free experience possible. This is accomplished by using SPF, SURBL, RBL, DKIM/DomainKeys, Virus Scanning, and ASpam content based message scoring mechanism. When an email is recognized as SPAM, it goes into your SPAM folder which is accessible via IMAP in your email client. If you get junk email in your INBOX, then you just move it to the SPAM folder, and this will add the email sender to your block list and train the system. If you get legitimate email in your SPAM folder, then move it to your INBOX and this will add the email sender to your friends list and train the system.
When you contact our support you will be in touch with a high level tech support agent that is based locally. You will not have to go through multiple levels of support to get someone with a high level of technical knowledge to get your email hosting working. We provide phone and chat support during normal business hours, and 24/7 email support. We have our own remote access system that allows our support staff to remotely pull up your MacOS or iOS device to help us provide the best support possible by actually visually seeing and interacting with your device.
We have tried to provide the lowest prices possible for the quality of services we provide. Instead of charging on a per email account basis like most high end email hosting services, we use a shared storage concept. You can create as many email accounts as you want, and they all share the same domain storage allotment. You can limit the storage usage on a per email account basis, and you can always purchase more storage if the total allocation for the whole domain is used. Since storage is the most costly thing for us to maintain and replicate, we found this as a better basis for our pricing.
You can see from all the above areas, we have went above and beyond just about any other hosting company has done to provide the ultimate email hosting experience for Apple users. Additional unique hosting features we offer can be viewed under the “FEATURES” header option at the top of our website. We welcome you to become part of our family and experience our high quality email hosting services for yourself. If your new to email hosting we can help you through the process of getting your own custom domain setup for your business or yourself. If you have an existing email solution in place and would like to move to us, we can help migrate all your existing email over to our systems without any downtime.
If you would like full information about our email hosting please click here. If you have additional questions or comments please contact us at one of the means available at: https://www.imageway.com/contact-us
Important changes are coming in 2022 to both Google Gmail and Microsoft Exchange Online (Office365) that can break the use of your current device applications that access either of these email services. Starting on May 30, 2022, your Google Account will no longer support the use of less secure third-party apps or devices which sign in each time using only your username and password. Following closely behind, your Microsoft Account will start to no longer support what they call basic authentication on October 1, 2022.
In both instances this means that you will no longer be able to login in to your Google Gmail Account or Microsoft Exchange Online account using proxy authentication which uses your username and password that is stored on your device for each communication request. Attempting to do so will most likely result in an error such as “NO [AUTHENTICATIONFAILED] Invalid credentials (Failure)”, “[AUTH] Username and password not accepted”, or “HTTP 401 error: bad username or password” being reported by your application when connecting to Gmail or Exchange Online.
These changes by both email providers are going to break the ability of email clients, software products, and devices (such as digital senders) that rely on those email protocols (IMAP/POP/SMTP/EAS) to no longer function unless they are upgraded to use OAuth for authentication. OAuth is a more complicated login method that requires you to get an access token from an authorization server, which is then stored and used by the application to access your account. The usual way to obtain this access token requires you to login to a webpage, and then approve the access permissions that are required. The OAuth requirement will additionally make it difficult for software to automate mass migration of email accounts away from their services.
Here at Imageway we plan on continuing to support proxy authentication for the foreseeable future so that all your old devices will continue to work without interruption. Legacy device support is a very important service feature we offer (https://www.imageway.com/legacy-device-support). Additionally, we like the simplicity of proxy authentication and feel we can secure this method of authentication using our unique blend of encryption (TLS), multiple factor authentication (MFA), and other various checks during login. Of course we always recommend you don’t make your email password easily guessable, and never reuse your email password somewhere else. That alone will go a long way for securing your email account.
If you would like full information about our email hosting please click here. If you have additional questions or comments please contact us at one of the means available at: https://www.imageway.com/contact-us
This guide was built to serve as a comprehensive resource to using .htaccess. If you are completely new to using .htaccess — you might want to start with the first chapter “.htaccess Basics” below.
If you are searching for specific code samples or tutorials look at the navigation on the right-hand side of this page to jump directly to sub-sections within this page.
What is .htaccess?
The .htaccess file is a configuration file that affects how a webserver responds to various requests. It is supported by several webservers, including the popular Apache software used by mosy commercial web hosting providers.
.htaccess files operate at the level of a directory, allowing them to override global configuration settings of .htaccess directives higher in the directory tree.
Why is it called .htaccess?
These files were first used to control user access on a per-directory basis.
Using a subset of Apache’s http.conf settings directives, it allowed a system administrator to restrict access to individual directories to users with a name and password specified in an accompanying .htpasswd file.
While .htaccess files are still used for this, they are also used for a number of other things which we’ll cover in this guide.
Where is the .htaccess file?
In theory, every folder (directory) on your server could have one. Generally, though, there is one in your web root folder — that’s the folder that holds all the content of your website, and is usually labeled something like Public_HTML or www.
If you have a single directory that contains multiple website subdirectories, there will usually be an .htaccess file in the main root (Public_HTML) directory and also one in each subdirectory (/sitename).
Why can’t I find my .htaccess file?
On most file systems, file names that begin with a dot ( . ) are hidden files. This means they are not typically visible by default.
But they aren’t hard to get to. Your FTP client or File Manager should have a setting for “show hidden files.” This will be in different places in different programs, but is usually in “Preferences”, “Settings”, or “Folder Options.” Sometime you’ll find it in the “View” menu.
What if I don’t have an .htaccess file?
First of all, make sure that you have turned on “show hidden files” (or its equivalent), so that you can be sure you actually don’t have one. Often, .htaccess files are created automatically, so you will usually have one. But this isn’t always the case.
If you really don’t have one, you can easily create one:
Start a new file in a plain text editor.
Save it in ASCII format (not UTF-8 or anything else) as .htaccess
Make sure that it isn’t htaccess.txt or something like that. The file should have only the name .htaccess with no additional file extension.
Upload it to the appropriate directory via FTP or your browser-based file manager.
Using .htaccess files to specify error documents is very simple, one of the simplest things you can do with this feature.
What is an error code?
When a request is made to a web server, it tries to respond to that request, usually by delivering a document (in the case of HTML pages), or by accessing an application and returning the output (in the case of Content Management Systems and other web apps).
If something goes wrong with this, an error is generated. Different types of errors have different error codes. You are probably familiar with the 404 error, which is returned if the document cannot be found on the server.
There are many other error codes that a server can respond with.
Client Request Errors
400 — Bad Request
401 — Authorization Required
402 — Payment Required (not used yet)
403 — Forbidden
404 — Not Found
405 — Method Not Allowed
406 — Not Acceptable (encoding)
407 — Proxy Authentication Required
408 — Request Timed Out
409 — Conflicting Request
410 — Gone
411 — Content Length Required
412 — Precondition Failed
413 — Request Entity Too Long
414 — Request URI Too Long
415 — Unsupported Media Type.
500 — Internal Server Error
501 — Not Implemented
502 — Bad Gateway
503 — Service Unavailable
504 — Gateway Timeout
505 — HTTP Version Not Supported.
What happens by default?
If you don’t specify any type of error handling, the server will simply return the message to the browser, and the browser will display a generic error message to the user. This is usually not ideal.
Specifying Error Documents
Create an HTML document for each error code you want to handle. You can name these whatever you like, but it’s helpful to name them something that will help you remember what they’re for, like not-found.html or simply 404.html.
Then, in the .htaccess file, specify which document to use with each type of error.
ErrorDocument 400 /errors/bad-request.html
ErrorDocument 401 /errors/auth-reqd.html
ErrorDocument 403 /errors/forbid.html
ErrorDocument 404 /errors/not-found.html
ErrorDocument 500 /errors/server-err.html
Notice that each directive is placed on its own line.
And that’s it. Very simple.
Alternatives to .htaccess for error handling
Most Content Management Systems (CMS) like WordPress and Drupal, and most web apps, will have their own way of handling most of these errors codes.
Password Protection With .htaccess
The original purpose of .htaccess files was to restrict access to certain directories on a per-user basis (hence the name, hyper text access). So we’ll look at that first.
Usernames and passwords for the .htaccess system are stored in a file name .htpasswd.
These are stored each on a single line, in the form:
It’s important to realize that the password stored in the file isn’t the actual password used to log in. Rather it is a cryptographic hash of the password.
This means that the password has been run through an encryption algorithm, and the result is stored. When a user logs in, the plain-text password is entered and run through the same algorithm. If the input is the same, the passwords match and the user is granted access.
Storing passwords this way makes them more secure — if someone were to gain access to your .htpasswd file, they would only see the hashed passwords, not the originals. And there is no way to reconstruct the originals from the hash — it is a one way encryption.
Several different hashing algorithms can be used:
Secure Algorithms — Use one of
bcrypt — This is the most secure, but also the slowest to compute. It is supported by Apache and Nginx.
md5 — This is the default hashing algorithm used by current versions of Apache. It is not supported by Nginx.
Insecure Algorithms — Do not use
crypt() — This used to be the default hashing function, but it is not very secure.
SHA and Salted SHA.
Creating usernames and passwords on the command line
You can create an .htpasswd file, and add username-password pairs to it, directly from the command line or SSH terminal.
The command for dealing with the .htpasswd file is simply htpasswd.
To create a new .htpasswd file, use the command with the -c option (for create), then type the path to the directory (not the URL, the actual path on the server). You can also include a user you want to add.
> htpasswd -c /usr/local/etc/.htpasswd johnsmith
This creates a new .htpasswd file in the /etc/ directory, and adds a record for a user named johnsmith. You will be prompted for a password, which will also be stored, using the md5 encryption.
If there is already an .htpasswd file at the specified location, a new one is not created — the new user is simply appended to the existing file.
If you’d prefer to use the bcrypt hashing algorithm, use the -b option.
Password hashing without the command line
If you don’t feel comfortable using the command line or SSH terminal (or if you don’t have access to it for some reason), you can simply create an .htpasswd file and populate it using a plain text editor, and upload it via FTP or file manager.
But then you’ll need to encrypt your passwords somehow, since the htpasswd command was taking care of that for you.
There are many .htpasswd encryption utilities available online. The best one is probably the htpasswd generator at Aspirine.org.
This gives you several options for hashing algorithm and password strength. You can simply copy-and-paste the output from there into your .htpasswd file.
Where to keep your .htpasswd file
You don’t need to have a separate .htpasswd file for every .htaccess file. In fact, you shouldn’t. Under most normal circumstances, you should have one for your entire web hosting account or main server directory.
The .htpasswd file should not be in a publicly accessible directory — not Public_HTML or www or any subdirectory. It should be above those, in a folder that is only accessible from the server itself.
How to use .htpasswd with .htaccess
Each directory can have its own .htaccess file, with its own set of users which are allowed to access it.
If you want any one (including non-logged-in users) to access the directory and its files, simply do nothing — that is the default.
To restrict access you need to add the following to the .htaccess file:
AuthName “Name of Secure Area”
In the above example, any valid user can access files. If you want to restrict access to a specific user or few users, you can name them.
AuthName “Name of Secure Area”
require user janedoe
The group file, which could be named (for example) .htgroups looks like this:
admin: johnsmith janedoe
staff: jackdoe cindysmith
Then you can specify it in your .htaccess file:
AuthName “Admin Area”
Using .htaccess and .htpasswd to resrict access to certain files on your server only really makes sense if you have a lot of static files. The feature was developed when web sites were usually a collection of HTML documents and related resources.
If you are using a content management system (CMS) like WordPress or Drupal, you can use the built-in user management features to restrict or grant access to content.
Enabling Server Side Includes (SSI)
What are Server Side Includes?
SSI, or Server Side Includes, is a light-weight scripting language used primarily to embed HTML documents into other HTML documents.
This makes it easy to re-use common elements, such as headers, footers, sidebars, and menus. You can think of it as a precursor to today’s templating and content management systems.
SSI also has conditional directives (if, else, etc.) and variables, making it a complete, if somewhat hard to use, scripting language. (Typically, any project more complicated than a handful of includes will cause a developer to choose a more robust language like PHP or Perl.)
Some web hosting servers will have Server Side Includes enabled by default. If not, you can enable it with your .htaccess file, like so:
AddType text/html .shtml
AddHandler server-parsed .shtml
Options Indexes FollowSymLinks Includes
This should enable SSI for all files that have the .shtml extension.
SSI on .html files
If you want to enable SSI parsing on .html files, you can add a directive to accomplish that:
AddHandler server-parsed .html
The benefit of doing this is that you can use SSI without letting the world know you are using it. Also, if you change implementations in the future, you can keep your .html file extensions.
The downside of this is that every .html file will be parsed with SSI. If you have a lot of .html files that don’t actually need any SSI parsing, this can introduce a lot of unneeded server overhead, slowing down your page load times and using up CPU resources.
SSI on your Index page
If you don’t want to parse all .html files, but you do want to use SSI on your index (home) page, you’ll need to specify that in your .htaccess file.
That’s because when the web server is looking for a directory’s index page, it looks for index.html, unless you tell it otherwise.
If you aren’t parsing .html files, you’ll need your index page to be named index.shtml for SSI to work, and your server doesn’t know to look for that by default.
To enable that, simply add:
DirectoryIndex index.shtml index.html
This alerts the web server that the index.shtml file is the main index file for the directory. The second parameter, index.html is a backup, in case index.shtml can’t be found.
IP Blacklisting and IP Whitelisting
You can use .htaccess to block users from a specific IP address (blacklisting). This is useful if you have identified individual users from specific IP addresses which have caused problems.
You can also do the reverse, blocking everyone except visitors from a specific IP address (whitelisting). This is useful if you need to restrict access to only approved users.
Blacklisting by IP
To block specific IP addresses, simply use the following directive, with the appropriate IP addresses:
deny from 22.214.171.124
deny from 789.56.4.
allow from all
The first line states that the allow directives will be evaluated first, before the deny directives. This means that allow from all will be the default state, and then only those matching the deny directives will be denied.
If this was reversed to order deny,allow, then the last thing evaluated would be the allow from all directive, which would allow everybody, overriding the deny statements.
Notice the third line, which has deny from 789.56.4. — that is not a complete IP address. This will deny all IP addresses within that block (any that begin with 789.56.4).
You can include as many IP addresses as you like, one on each line, with a deny from directive.
Whitelisting by IP
The reverse of blacklisting is whitelisting — restricting everyone except those you specify.
As you may guess, the order directive has to be reversed, so that that everyone is first denied, but then certain addresses are allowed.
deny from all
allow from 126.96.36.199
allow from 789.56.4.
Domain names instead of IP addresses
You can also block or allow users based on a domain name. This can be help block people even as they move from IP address to IP address. However, this will not work against people who can control their reverse-DNS IP address mapping.
deny from example.com
allow from all
This works for subdomains, as well — in the previous example, visitors from xyz.example.com will also be blocked.
Block Users by Referrer
A referrer is the website that contains a link to your site. When someone follows a link to a page on your site, the site they came from is the referrer.
This doesn’t just work for clickable hyperlinks to your website, though.
Pages anywhere on the internet can link directly to your images (“hotlinking”) — using your bandwidth, and possibly infringing on your copyright, without providing any benefit to you in terms of traffic. They can also hotlink to your CSS files, JS scripts, or other resources.
Most website owners are okay with this when happens just a little bit, but sometimes this sort of thing can turn into abuse.
Additionally, sometimes actual in-text clickable hyperlinks are problematic, such as when they come from hostile websites.
For any of these reasons, you might want to block requests that come from specific referrers.
To do this, you need the mod_rewrite module enabled. This is enabled by default for most web hosts, but if it isn’t (or you aren’t sure) you can usually just ask your hosting company. (If they can’t or won’t enable it, you might want to think about a new host.)
The .htaccess directives that accomplish referrer-based blocking rely on the mod_rewrite engine.
The code to block by referrer looks like this:
RewriteCond % ^http://.*example.com [NC,OR]
RewriteCond % ^http://.*anotherexample.com [NC,OR]
RewriteCond % ^http://.*onemoreexample.com [NC]
RewriteRule .* – [F]
This is a little tricky, so lets walk through it.
The first line, RewriteEngine on, alerts the parser that a series of directives related to rewrite is coming.
The next three lines each block one referring domain. The part you would need to change for your own use is the domain name (example) and extension (.com).
The backward-slash before the .com is an escape character. The pattern matching used in the domain name is a regular expression, and the dot means something in RegEx, so it has to be “escaped” using the back-slash.
The NC in the brackets specifies that the match should not be case sensitive. The OR is a literal “or”, and means that there are other rules coming. (That is — if the URL is this one or this one or this one, follow this rewrite rule.)
The last line is the actual rewrite rule. The [F] means “Forbidden.” Any requests with a referrer matching the ones in the list will fail, and deliver a 403 Forbidden error.
Blocking Bots and Web Scrapers
One of the more annoying aspects of managing a website is discovering that your bandwidth is being eaten up by non-human visitors — bots, crawlers, web scrapers.
These are programs that are designed to pull information out of your site, usually for the purpose of republishing it as part of some low-grade SEO operation.
There, of course, legitimate bots — like those from major search engines. But the rest are like pests that just eat away at your resources and deliver no value to you whatsoever.
There are several hundred bots identified. You will never be able to block all of them, but you can keep the activity down to a dull roar by blocking as many as you can.
Here is a set of rewrite rules which will block over 400 known bots, compiled by AskApache
Specifying a Default File for a Directory
When a request is made to a web server for a URL which does not specify a file name, the assumption built into most web servers is that the URL refers to a directory.
So, if you request http://example.com, Apache (and most other web servers) is going look in the root directory for the domain (usually /Public_HTML or something similar, but perhaps /example-com) for the default file.
The default file, by default, is called index.html. This goes way back to the beginning of the internet when a website was just a collection of documents, and the “home” page was usually an index of those documents.
But you might not want index.html to be the default page. For example, you might need a different file type, like index.shtml, index.xml, or index.php.
Or you might not think of your home page as an “index,” and want to call it something different, like home.html or main.html.
Setting the Default Directory Page
.htaccess allows you to set the default page for a directory easily:
DirectoryIndex [filename here]
If you want your default to be home.html it’s as easy as:
Setting Multiple Default Pages
You can also specify more than one DirectoryIndex:
DirectoryIndex index.php index.shtml index.html
The way this works is that the web server looks for the first one first. If it can’t find that, it looks for the second one, and so on.
Why would you want to do this? Surely you know which file you want to use as your default page, right?
Remember that .htaccess affects its own directory, and every subdirectory until it is overridden by a more local file. This means that an .htaccess file in your root directory can provide instructions for many subdirectories, and each one might have its own default page name.
Being able to place those rules in a single .htaccess file in the root means that you don’t have to duplicate all the other directives in the file at every directory level.
URL Redirects and URL Rewriting
One of the most common uses of .htaccess files is URL redirects.
URL redirects should be used when the URL for a document or resource has changed. This is especially helpful if you have reorganized your website or changed domain names.
301 vs. 302
From a browser standpoint, there are two types of redirects, 301 and 302. (These numbers refer to the error code generated by the web server.)
301 means “Permanently Moved,” while 302 means “Moved Temporarily.” In most cases, you want to use 301. This preserves any SEO equity the original URL had, passing it on to the new page.
It also will cause most browsers to update their bookmarks. Most browsers will also cache the old-to-new mapping, so they will simply request the new URL when a link or user attempts to access the original. If the URL has changed permanently, these are all desirable results.
There’s very little reason to use 302 redirects, since there’s usually very little reason to temporarily change a URL. Changing a URL ever is undesirable, but is sometimes necessary. Changing it temporarily, with the plan to change it back later, is a bad idea and is almost always avoidable.
All the examples in this section will use the 301 redirect.
Redirect vs. Rewrite
There are two different ways to “change” a URL with .htaccess directives — the Redirect command and the mod_rewrite engine.
The Redirect command actually sends a redirect message to the browser, telling it what other URL to look for.
Typically, the mod_rewrite tool “translates” one URL (the one provided in a request) into something that the file system or CMS will understand, and then handles the request as if the translated URL was the requested URL.
When used this way, the web browser doesn’t notice that anything happened — it just receives the content it asked for.
The mod_rewrite tool can also be used to produce 301 redirects that work the same way as the Redirect command, but with more options for rules — mod_rewrite can have complex pattern matching and rewriting instructions, which Redirect cannot take advantage of.
Basic Page Redirect
To redirect one page to another URL, the code is:
Redirect 301 /relative-url.html http://example.com/full-url.html
This single-line command has four parts, each separated with a single space:
The Redirect command
The type of redirect ( 301 – Moved Permanently )
The relative URL of the original page
The full and complete URL of the new page.
The relative URL is relative to the directory containing the .htaccess file, which is usually the web root, or the root of the domain.
So if http://example.com/blog.php had been moved to http://blog.example.com, the code would be:
Redirect 301 /blog.php http://blog.example.com
Redirecting a large section
If you have moved your directory structure around, but kept your page names the same, you might want to redirect all requests for a certain directory to the new one.
Redirect 301 /old-directory http://example.com/new-directory
Redirecting an entire site
What if you entire site has moved to a new URL? Easy.
Redirect 301 / http://newurl.com
Redirecting www to non-www
Increasingly, websites are moving away from the www subdomain.
It’s never really been necessary, but it was a holdover from the days when you most people who operated a website were using a server to store lots of their own documents, and the www or “world wide web” directory was used for content they wanted to share with others.
These days, some people use it, and some people don’t. Unfortunately, some users still automatically type www. in front of every URL out of habit. If you’re not using www, you want to make sure that these requests land in the right place.
To do this, you’ll need to use the mod_rewrite module, which is probably already installed on your web host.
RewriteCond % ^www.example.com [NC]
RewriteRule ^(.*)$ http://example.org/$1 [R=301,NC]
A lot of other .htaccess and mod_rewrite guides offer some variation of the following code to accomplish this:
RewriteCond % !^example.com [NC]
RewriteRule ^(.*)$ http://example.org/$1 [R=301,NC]
Do you see the problem with that?
It redirects all subdomains to the primary domain. So not just www.example.com, but also blog.example.com and admin.example.com and anything else. This is probably not the behavior you want.
Redirecting to www
But what if you are using the www subdomain?
You should probably set up a redirect to make sure people get to where they’re trying to go. Especially now that fewer people are likely to automatically add that www to the beginning of URLs.
You just reverse the above code.
RewriteCond % ^example.com [NC
RewriteRule ^(.*) http://www.website.com/$1 [R=301,NC]
Something you shouldn’t do
Several guides on .htaccess redirects include instructions on how to make 404 errors redirect to the home page.
This is a good example of how just because you can do something, it doesn’t mean you should do something.
Redirecting 404 errors to the site’s homepage is a terrible idea. It confuses visitors, who can’t figure out why they are seeing the front page of a site instead of a proper 404 error page.
All websites should have a decent 404 page which clearly explains to the user that the content couldn’t be found and, ideally, offers some search features to help the user find what they were looking for.
Why use .htaccess instead of other alternatives?
You can set up redirect in PHP files, or with any other type of server-side scripting. You can also set them up within your Content Management System (which is basically the same thing).
But using .htaccess is usually the fastest type of redirect. With PHP-based redirects, or other server-side scripting languages, the entire request must be completed, and the script actually interpreted before a redirect message is sent to the browser.
With .htaccess redirects, the server responds directly to the request with the redirect message. This is much faster.
You should note, though — some content management systems actually manage redirects by updating the .htaccess programatically. WordPress, for example, has redirect plugins that work this way. (And WP’s pretty URL system does this as well.)
This gives you the performance of using .htaccess directly, while also giving you the convenience of management from within your application.
Hiding Your .htaccess File
There is no reason that someone should be able to view your .htaccess file from the web. It is never a needed document.
Moreover, there are some big reasons you should definitely not want people to see your .htaccess file. The biggest issue is that if you are using an .htpasswd file, its location is spelled out in the .htaccess file. Knowing where to find it makes it easier to find.
Moreover, as a general rule, you don’t want to provide the public with details about your implementation.
Rewrite rules, directory settings, security — all of the things that you use .htaccess for — it is a good security practice to hide all of this behind-the-scenes at your web server. The more a hacker can learn about your system, the easier it is to compromise it.
It is very easy to hide your .htaccess file from public view. Just add the following code:
deny from all
Enabling MIME types
MIME types are file types. They’re called MIME types because of their original association with email (MIME stands for “Multipurpose Internet Mail Extensions”). They aren’t just called “file types” because MIME implies a specific format for specifying the file type.
If you’ve ever authored an HTML document, you’ve like specified a MIME type, even if you didn’t know it:
If you got a warning from our email system that said “Your email client used an insecure login protocol”, then you are using a email client to access your email account which is not using SSL/TLS. To fix this issue all you need to do is edit your email client settings and turn on SSL/TLS. Information on how to set-up common email clients is available on your mail system home page at: http://mail.yourdomain.com (where “yourdomain.com” is your own domain name).
SSL stands for Secure Sockets Layer and, in short, it’s the standard technology for keeping an internet connection secure and safeguarding any sensitive data that is being sent between two systems, preventing criminals from reading and modifying any information transferred, including potential personal details. TLS (Transport Layer Security) is just an updated, more secure, version of SSL.
At Imageway we offer both secure and non non-secure connections to all our supported Internet protocols. The reason we have kept the non-secure connections around is to support older clients which might not support secure based connections. If your email client supports a secure connection, which most do now in days, we strongly suggest you turn it on. This is why these warnings are sent out, so the customer is aware that something can be fixed to improve their overall security.
If you have additional questions or comments please contact us at one of the means available at: https://www.imageway.com/contact-us
The concept of “push email” has been widely marketed as a desirable feature of mobile email services, to enable users to get immediate notification of and access to new messages. This article looks at various approaches to meeting user requirements, and concludes that the Internet Standard IMAP (Internet Message Access Protocol) IDLE command is the best way to achieve this service.
“Push Email” is an unfortunate choice of terminology, as it implies a specific technical solution to a more generic user requirement. The primary user requirement described by “push email” is:
‘Immediately’ in the context of store and forward messaging would typically be interpreted as “a few seconds”, rather than hours and minutes. There are some associated secondary requirements that should be addressed
1) The user should have control over message download to the mobile device. A typical choice would be to automatically download small messages, and to download larger messages under user control.
2) The user should be able to turn off notifications when desired.
3) The user should have control over which messages lead to notifications (e.g., only messages from the boss!).
The basic approach used by many email devices is to connect to the server to access new messages. This is a good model for many uses of mobile email, where access to email is under user control – the user checks email when the user wants to.
In order achieve automatic notification of new messages, a simple approach is to use ‘polling’ where the mobile client automatically connects to the server at intervals to check for new messages. However, there are two main problems with this approach:
1) Frequent polling is an inefficient use of network and mobile device resources, increasing the cost to the user.
2) New mail notification is only as frequent at the polling, and not ‘immediate’.
Polling is a poor solution for a user needing immediate notification.
IMAP (Internet Message Access Protocol) is the best open standard for accessing mobile email. It handles immediate notification as part of general operations and by the IDLE command, which is a widely implemented standard extension to the core IMAP protocol.
IMAP works by the software on the mobile device (the client) issuing commands to the server. An IMAP server provides two things in response to a client command:
1) An answer to the request.
2) Information on any new messages.
This means that where a client is actively doing things with an IMAP server, it will be told immediately about new messages. The client can then get summary information on the message to present to the user, and can (automatically) download the message when appropriate.
This means that an active client will always be kept up to date. The IDLE command deals with the situation where the client has no more requests to make. The server responds to the idle command when there is a new message (or messages) which indicates to the client that there are new messages.
When the user is inactive, and does not wish to receive notifications, the client simply stops using IDLE, which is very efficient.
The basic network use of the IDLE command is very small, and so it makes very efficient use of bandwidth. In practice things are made more complex by the problem of timeouts occuring when there is no activity keeping the connection open. The main timeouts that will occur are:
1) IMAP server timeout: Typically occurs after 30 minutes with no activity.
2) NAT Gateway timeout: Most mobile devices access the Internet through a device operated by the mobile service provider called a NAT (Network Address Translation) gateway. These will typically time out an idle connection after 15 minutes.
The solution to this is for the IMAP client to issue a NOOP (No Operation) command at intervals, typically every 15 minutes. This will exchange a few bytes of data, and keep everything active. The impact of holding an IMAP connection open on the client, server and intermediate components should be considered:
1) IMAP Server. A good IMAP server will have minimal overhead for an Idle connection, and should be able to support 10’s or 100’s of thousands of connections.
2) IP Routers and other network components. Negligible impact.
3) Phone. For older phones there could be an issue of increased battery usage due to holding the connection open. This is unlikely to be a problem on a modern phone.
Another practical problem is that current phone networking technology will lose IP network connectivity from time to time, and this will need to be automatically re-established, and the IMAP connection re-established if this is lost due to a long network failure.
In summary, the overall IMAP IDLE architecture has good performance.
An alternative to the IMAP IDLE approach is for a mechanism whereby the server pushes something to the client when a new message arrives, without there being an open connection from the client to the server. This section looks at this approach.
There are two variants of the ‘true’ push approach:
1) Push the new message.
2) Push a short generic message alert, prompting the client to connect to the server in order to retrieve the message.
Using approach 1 leads to three problems:
1) The mechanism will need to deal with security and data confidentiality, which leads to a lot of additional complexity.
2) The data being pushed becomes larger, which reduces the options for sending the data (e.g., SMS could not be used).
3) There is no client control on the choice to download.
For these reasons, the second approach is generally better, and this is the one considered here.
A clean way to send data from the server to the mobile device would be for the server to open a TCP connection. This would give a lot of flexibility in protocol choice and deployment. Unfortunately, this is impractical because most mobile devices do not have registered IP addresses to which a server can connect. They are also generally connected through a NAT gateway that will prevent connections being made to the phone. This means that use of a TCP connection is not generally a viable option.
This means that another mechanism needs to be used to do the ‘push’. There are various options to do this. SMS is a good candidate, as it is widely supported as a data listening mechanism on most mobile devices. SMS is used as an example interconnect mechanism in this paper. The use of SMS as the mechanism to carry messaging alerts leads to two integration problems:
1) Phone. SMS is a general purpose service, not specific to email. There are two integration approaches:
1a) Use a “you’ve got mail” message to the human user, who will then connect with the email application. This crude approach would only be suitable for very basic use.
1b) Standardize how SMS is used, so that phones can detect email notifications and pass them to the email client for automatic processing.
2) Messaging server. There are two deployment scenarios:
2a) Messaging server deployed by a mobile operator. In this scenario integration with SMS is straightforward.
2b) Messaging server deployed by the end organization or independent service provider. Typically such a deployment will rely on Internet access. Integration with SMS would provide both technical problems (how to make it happen) and commercial problems (who pays for the SMS message, and how to prevent abuse).
These problems are not insurmountable, but will be a barrier to widespread adoption.
The response time and data use of this push approach are contrasted to IMAP IDLE. A messaging server offering both approaches would be able to send the push notification and IDLE response at the same time. The IDLE response is immediate, and it will initiate the client to deal with the new messages. The push notification will have two delays:
1) Time for the SMS message to reach the phone. This may be a few seconds, but could take longer.
2) Time for the client to connect to the server. This will typically be a few seconds.
True push will be somewhat slower than IMAP IDLE, but in practice this is not likely to be a big problem.
Data usage for IMAP IDLE is essentially the 15 minute NOOP to keep the connection alive, plus a small amount of data to do the notification. The true push will have the cost of the SMS notification. The data for connection establishment is more significant, typically including TCP Connection; TLS (for data confidentiality); client authentication; client (re) synchronization.
It can be seen that for frequent message arrival, that IMAP IDLE is more efficient and that for longer intervals between notifications that true push has better data efficiency. The details will depend on many parameters. A rough calculation suggests that a typical break-even point would be around two days. This suggests that for a typical user receiving and getting notifications for 10 messages per day, that IMAP IDLE has significantly better data performance.
When the user does not want to receive notifications, there is a need to change server configuration (which causes extra complexity and network activity).
IMAP + IMAP IDLE is a good approach for providing the immediate email notification and delivery service of “push email”. It has substantial implementation, deployment and performance advantages over a “true push” approach. Imageway offers a solid, fast, and fully compliant IMAP email service implementation with IMAP IDLE support for push email.
Imageway WebMail end user help.
Imageway WebMail has two slightly different forms of labels with comparitive advantages as below:
Should be used for labels you use frequently and may want to change on multiple messages. This uses IMAP user flags to store the labels.
Imageway WebMail labels
Only use if you need more than 22 labels or imap user flags cannot be enabled. Avoid using these on large messages. This stores the label as an additional header in your IMAP message. This requires Imageway WebMail to modify and re-upload your email message to the server.
Labels can be added and removed from messages as much as you like. However for both types of labels once the label has been created it cannot be deleted (for implementation reasons). You can however rename the display name or hide labels from display.
Imageway WebMail has three different ways of searching for messages
This is a ‘search as you type’ browser side ‘full text match only’ search of the displayed headers of the current page of messages. This is useful for quickly locating certain messages without waiting for the delay involved in going to the server for more advanced searches.
Note: This will not search message bodies or other pages of messages in the currently displayed folder (see hint below)
HINT: When Enter is pressed a “quick search” will be automatically switched to a “folder search” under certain conditions. In particular: if there are multiple pages of messages in a folder, if advanced search syntax characters are found (colon or minus or double quote), or control-enter is pressed.
This is a very fast server side headers search of all the messages in one or more folders. This search capability allows for the search for multiple search terms that are ‘ANDed’ together and allows for searching specific fields:
Note: This will not search message bodies, and only searches messages in folders that have already been accessed and indexed by Imageway WebMail (manually refresh by right clicking a folder and select refresh or refresh all)
note: The “Recent” option only searches folders that have been accessed in the last month. The “All” option will search all folders but does not refresh the mesage indexes from IMAP so may not find the message you are looking for. Click any folders in question to refresh the indexes.
IMAP serverside search of the full message body and headers content. This can take a long time on large folders / or large accounts – expect approx 30 seconds per 100 MB of mail that needs to be searched through.
One or more search terms can be specified which will be ANDed together.
Note: This may take a long time
|Body search syntax:|
|joe||All messages with the word ‘joe’ anywhere in the message|
|joe blogs||All messages with the word ‘joe’ AND ‘blogs’ anywhere in the message|
|“joe blogs”||All messages with the string ‘joe blogs’ anywhere in the message|
Imageway WebMail uses the surgemail user.cgi Friends and spam handling features. Manually correcting false positives and training messages as spam can be done using the following actions in Imageway WebMail or in an IMAP client:
|Primary action||actioned in INBOX or other folder||actioned in Spam folder|
In Windows XP and later, the Windows file redirector has a built-in WebDAV client which can be used to mount a Windows drive letter to our on-line Mobile Office service. When you copy files to this drive mapping, they are stored on our Mobile Office server, which can be accessed from any computer via a drive mapping or via the Mobile Office web interface. When trying to copy large files you might run into a error that says “Error 0x800700DF: The file size exceeds the limit allowed and cannot be saved”. Windows has a built in limit on the size of a file that is allowed to be copied using WebDAV. To change this limit you must edit a registry subkey which holds the value limit, and reboot your computer. To change this registry setting do the following:
1) Click Start, click Run, type regedit in the Open box, and then click “Ok”.
2) Locate “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\
Services\WebClient\Parameters” from the drop-down structure in left pane.
3) Right click on the “FileSizeLimitInBytes” subkey listed in the right pane, then click “Modify”.
4) Click the “Decimal” bubble under the “Base” section.
4) In the “Value data” box, type 4294967295, and then click “Ok”.
6) Reboot your computer.
Completing the above sets the maximum you can copy via WebDAV to 4 gig for a single file.
An email archive is a repository generally kept in a non-productive environment to provide secure preservation of email for compliance and operational purposes. A email archiving system automatically extracts message contents and attachments from incoming/outgoing emails and after indexing, it stores them in read-only format. This ensures that archived records are maintained in their original state.
The active approach adopted by email archiving solutions ensures that the company has a centralized and accessible copy of all its email. This provides additional protection against accidental or intentional deletion of emails by end-users. Email archiving also eliminates the need to search for personal archives on each and every local machine whenever litigation support is requested.
It must be noted that ‘backup’ and ‘archival’ storage serve two different purposes. Backups are intended to save current data against the event of failure or disaster whilst archives protect data so that it can be accessed when needed.
Email archiving is available on all our Email Hosting accounts. The email archiving feature is disabled by default. To turn it on do the following:
1) Login to the “Domain Management” section on the Email Message System for your domain.
2) Click the “Misc” button.
3) Make sure the “Disable Legal Archive” option is unchecked, and then click the “Save” button.
Once you do this, a copy of all incoming and outgoing email for your domain will be kept in a read only archive for 7 years. To access this archive click the “Legal Archive” button within the “Domain Management” interface.
If you require a custom email archive setup, please contact us. We can set up a email archive that will keep archives for shorter or longer periods or will only archive specific email based on “To”, “From”, or “Subject”.
Email archiving requirements are different based on country, state, and type of business. Be sure to research to find what email archiving is required for your business. One such document to aid in your research is available http://www.intradyn.com/email-retention-laws/
Imageway supports multiple technologies to allow secure encrypted sending and receiving of email. To talk to our mail system to send and retrieve email you usually have two options. Option one is using our webmail. Option two is using a 3rd party email client such as Outlook, Mac Mail, or Thunderbird. If you use our webmail, your connection to our mail system is encrypted using a secure web browser connection (HTTPS) automatically. If you use a 3rd party email client, you must tell your client to use IMAP(S), POP(S), and SMTP(S), where “S” is an SSL connection. You can find instructions on your domain’s email message center web page on setting up various email clients for a secure connection.
Now that you have your computer or mobile device talking to our system using a secure encrypted connection, you can send emails to anyone on your local domain and it will be secure. For example if “email@example.com” sends email to “firstname.lastname@example.org”, the email will reside on the same system, so it will be secure. But what happens if you want to send to another domain, such as “gmail.com”. This is where things get more complex. When you send email to someone on another domain that is not located on our email system, our system has to talk to another email system using SMTP. Our email system will try to make a secure encrypted connection to the other email system if the other system supports it. If it does not, then an unsecured connection will be used. Most of the large email providers do support using a secure SMTP connection.
To ensure outgoing email to another domain is sent securely you have two options:
1) Imageway Mail Vault – Our built in encryption system allows you to send encrypted emails by storing the outgoing email on our server, and then our email system will automatically send an email to the person receiving the email, notifying them to click a web page link to read the email. Once they click the link they are taken to a secure (HTTPS) website where they can read and reply to the email after they have been verified. You can send secure emails using any email client by putting “[Secure]” (without quotes) into your email subject. When our system notices that in the subject it will trigger our system to use the Imageway Mail Vault for end-to-end encyrption.
2) PGP (Pretty Good Privacy) – If your 3rd party email program supports it, you can use PGP. PGP requires you to create a key which you install in your email client. When you send email using PGP, the email program encrypts your email before it leaves your computer. For the receiver to un-encrypt your email and read it, they must have your public key which must be installed on their PGP supported email program. Due to these additional requirements, we do not suggest PGP if you want an easy and universally supported method of sending encrypted emails. We suggest using the Imageway Mail Vault above if you want a easier to use solution that is universally supported.
To see if incoming email was sent using a secure connection from another domain, you have two options:
1) If you are using our webmail (not the Mobile Office) and you see a “pad lock” icon next to the email sender or subject, then the email system that sent the email supported the ability to talk to our system over a secure encrypted connection and your email was sent securely. The emails themselves are sent in a plain text format over the encrypted connection, so it does not mean that the Imageway Vault or PGP was used, which offers another level of security because it encrypts the actual email content itself while sending over an encrypted connection.
2) If you are not using our webmail, then you will need to look at the full email headers for the “X-Encryption: SSL encrypted” text. You can search online to find out how to view email headers for your specific email program. If you are using Mac Mail, you can add any email header to be shown in your email view by going to the “Viewing section” of the Mail preferences, choose the “Custom setting”, and then add the “X-Encryption: SSL encrypted” text. This is a nice feature Mac Mail supports.
Using the methods above, you can have a secure end-to-end encrypted email connection which provides additional security to your business. These advanced features are included with all our email packages.
There are times for security reasons when you might want to limit access to a specific file or directory by using a login and password. One reason to do this would be to protect your WordPress installation, by limiting access to the wp-login.php script. Adding the following to your webpage root .htaccess file will require login access to the wp-login script:
<FilesMatch "wp-login.php"> AuthType Basic AuthName "Secure Area" AuthUserFile "/home/example/.htpasswds/webpage/wp-admin/.htpasswd" require valid-user </FilesMatch>
Additionally you can protect all files within a specific directory by putting the .htaccess file in the directory (for example /wp-admin/ directory in the case of WordPress) you want to password protect with the following:
AuthType Basic AuthName "Secure Area" AuthUserFile "/home/example/.htpasswds/webpage/wp-admin/.htpasswd" require valid-user
You just put the above information into a “.htaccess” file and upload to your location of choice. To create the “.htpasswd” file with users and passwords, please use the following online utility: http://www.htaccesstools.com/htpasswd-generator/
All rights reserved. Copyright © 2000-2021 Imageway, LLC.