|
| |
Account/Control Panel Documentation
|
This
Control Panel (CPanel) user
manual will assist in getting you familiar with the many features we have to offer. Whether you're looking for a quick start to uploading your files, or would like to familiarize yourself
with the advanced features, this manual provides easy to follow step by step instructions on just about
everything you'll need to know. New users are encouraged to print this manual and read it over at their
leisure. For the most current info on
CPanel, visit the
authors web site here.
|
| Assuming you've just signed up with AZRiver.com, you're probably wondering how to test out a few of the features and begin populating your web site with files. You're just a couple of steps from doing just that, but first things first. Your welcoming email contains the basic information you'll need to access your account and get things underway. Print it out, or open it up in a separate window, as you'll need to refer to it during these tutorials. |
|
Account Basics:
Username
and Passwords:
These are stated in the first couple paragraphs
of the welcoming email we send you once you sign up. Until you change them, they're needed
to authenticate (log in to) everything from FTP, to Email access, CPanel,
and publish with Microsoft FrontPage, etc. (if you're using it) In short, use
this Username and Password for any access you're attempting on your account.
Accessing your account via its URL or associated IP number:
If you've just signed up for hosting with AZRiver.com,
chances are you've begun the process of a domain transfer to our servers, in some cases we will be handling this transfer for you. On average it takes anywhere from 48 to 72 hours for all worldwide DNS records to reflect your domain name as pointing to our servers. While everything in our welcoming email refers to the domain you signed up, we recommended you use the accompanying "IP" number until you can verify your domain is actually answering to your new account on the AZRiver.com servers.
The IP number we've provided you with will soon
be registered to your domain name. Until such time as your domain is officially answering to our servers, you can use your new IP number to access and setup your web site. For example, if your assigned IP was 66.78.6.147, your welcoming email would provide the URL http://66.78.6.147/~username/ as an option for accessing your new account. Again, it's a great way to test all those features and make sure everything is functioning smoothly before launching your web site.
Accessing your account via FTP:
These accounts are generally accessed the same way as a dedicated IP account would be. Again, if your domain name is not officially pointing to our servers yet, use the IP
number and username, which was sent to you in your welcome email. If you have additional questions regarding the ins and outs of FTP, please see our FTP support section, which covers it in broad detail.
|
|
Accessing CPanel:
To access your CPanel account manager, you can login into it with:
http://www.yourdomain.com/cpanel/ (For name based accounts that have been up and running for more than 48 hours)
or
http://dedicated.azriver.com:2082/ if your domain is brand new and not yet
resolving...
|
|
Where to upload your files:
The Home Directory:
Your html files, which are the files you want to make accessible to the World Wide Web,
must be uploaded to your accounts web space. When you first FTP into your
account, you'll be taken to your "Home" directory. Don't confuse this with your
"web directory." The home directory is "not" accessible from the World Wide Web; it's a private directory where critical
system files reside. DO NOT delete files that have been created by the system,
otherwise your web site may disappear into cyberspace!
The public_html and www
directory - (Where web accessible files are placed)
These are the two directories where files you want accessed from the web must be placed. Open the folder "public_html".
This is your "web accessible directory." The folder named "www" is actually a shortcut to public_html, (both of them take you to your web directory). Upload the files you want accessible to your visitors and feel free to make the appropriate sub-directories
that your site may require.

|
|
Configuring FTP Clients:
Configuring Cute FTP
Based on version 4.2

Please note that there are a number of versions of Cute FTP floating around. As a result, some of the instructions provided here cannot possibly reflect all versions
that have been released in the past 5 years. The only small difference you may encounter is where some of the options can be found (depending on the client version you're using). In any event, everything is pretty much the same. Let's get started:
1. Open or Run the Cute FTP program
2. Select "File"
3. Select "Site Manager"
4. Select "New"
|
|
Options you'll see:

- Label for site: Enter a name for this account. For example, "My Root Account."
- FTP Host Address: ftp.mydomain.com
- FTP Site Username: Your main system login name
- FTP Site Password: Your main system password
- FTP Site Connection: Port: 21
- Login Type: Normal

|
Notes About Cute FTP:
There are a few advanced features you may want to be aware of. These features may need to be enabled if you're having problems accessing your site via an FTP client. The following will explain:
Trouble accessing your site via FTP:
This can sometimes occur if your accessing the Internet from behind a firewall, personal router, or using an Internet connection sharing system such as NAT (Network Address Translation). This is often
the case in a home or small office where several computers are being shared by one Internet connection. Symptoms include, difficulty logging in via FTP, and or maintaining a reliable upload or download session.
Use Passive Mode instead:
From your FTP main interface, select:
1. Edit (from the main dropdown menus)
2. Settings -
A dialog box called "Settings" now appears. Select:
3. Connections
4. Firewall -
This opens the Connection/Firewall dialog box:
5. Check the box that says "PASV mode."
6. Click OK
Do not touch any of the other settings!

Ignore all other settings you see here except for the "PASV_mode" setting!
|
Give it a try and see how it works. If you're still having problems, you should contact your ISP to see if they can make the necessary changes required for you to access your site via FTP. There are a vast number of network configurations ISP's sometimes use, and some of which that can cause problems for users wanting to access the web beyond that of a
web browser.
How to view all files in your account (For Advanced Users).
Advanced users may want ability to view all "hidden" files in their directories. While most of these are critical system files, there are a few, which can be manually edited by "Advanced Users." This is done by inserting an entry into the "File Masking" feature in the client.
Unmasking Hidden Files:
1. Open Cute FTP
2. Go to the site manager
3. Select your account
4. Select "Edit" |
|

A dialog box opens called "Site Properties":
1. Check the "Enable Filter" box
2. Click the "Filter" button
3. Check the " Enable Remote Filters
(Server Applied Filer) " box
4. In the "Remote Filter" window, type this command
-a
5. Click ok and that's it!
 |
|
The -a command will unmask "all" files
in your web account.
Final Note:
NEVER REMOVE OR ALTER FILES WHICH HAVE BEEN CREATED BY THE SERVER
or C-Panel!! Unless you're an advanced user, please leave all files that have
been created by the system alone! Doing otherwise could cause serious problems
with your account, and in some cases take it offline completely. When in doubt
"ASK", do not Delete!

|
Setting Up WSFTP

Please note that there are a number of versions
of WSFTP floating around. As a result, some of the instructions provided here
cannot possibly reflect all versions which have been released in the past 5
years. The only small difference you may encounter is where some of the options
can be found (depending on the client version you're using). In any event,
everything is pretty well much the same.
Setting up WSFTP:
1. Open your WSFTP client
2. The dialog box "WS_FTP" Sites should display. If not, click the "Connect"
button.
3. Select "New"
You should see this dialog box:

You'll be taken
through these options:
1.
New Site/Folder: Choose a name for this
account

2.
Host Name or IP address:
www.yourdomain.com

3.
User ID: Main system login
4. User Password: Main System Password
5. Select
"Save Password."

6.
Select
"Finish."
You should now be able to FTP into your site! |
Notes About WSFTP:
Main Username and Password:
The main Username and Password was sent to you in your welcoming
email, and are also the same ones used to access the C-Panel. If you've
changed your main Username and Password before setting this up, then
use you must use them instead.
Trouble accessing your site via FTP:
This can sometimes occur if your accessing the Internet from
behind a firewall, personal router, or using an Internet connection sharing
system such as NAT (Network Address Translation). This is often the case in
a home or small office where several computers are being shared by one
Internet connection. Symptoms include, difficulty logging in via FTP, and or
maintaining a reliable upload or download session. If this is the case, try
"Passive Mode." |
|
Setting Passive Mode:
1.
Open the WSFTP account manager
2. Highlight your account

3.
Select "Properties"
4. Select the
"Advanced" tab

5. Check the box called "Passive
Transfers."
6. Click "OK"

Select passive mode, click
"OK", and try it again.
How to view all files in your account
(For Advanced Users).
Advanced users may want ability to view all
"hidden" files in their directory. While most of these are critical system
files, there are a few, which can be manually edited by "Advanced Users." This
is done by inserting an entry into the "File Masking" feature in the client.
Unmasking Hidden Files:
1. Open the WSFTP account manager
2. Highlight your account
3. Select "Properties"
4. Select the "Startup" tab
5. In the "Remote File Mask" window, enter
-a

The -a command will unmask
all files in your web account.
Final Note:
NEVER REMOVE OR ALTER FILES WHICH HAVE BEEN CREATED BY THE SERVER or C-Panel!!
Unless you're an advanced user, please leave all files that have been created by
the system alone! Doing otherwise could cause serious problems with your
account, and in some cases take it offline completely. When in doubt
"ASK", do not Delete!

|
Understanding the site file system:
The index.html file and why you should use it:
This again is where a number of new webmasters
become stumped. They upload all of their files and directories, and then want to
access them with their browser, but they forget to save their welcoming page as
index.html, so here's what happens: They access their site as
http://www.mydomain.com or using the
associated IP number, for example,
http://64.191.93.84/~username/, and what
they see is their entire file directory structure! Yikes!...It looks just like
exploring the C drive on your computer! You don't want visitors seeing that, do
you?
When you access your site by calling it as http://www.yourdomain.com
or the assigned IP (for example),
http://64.191.93.84/~username/, the web server looks for the
"index.html" file. This is the default web page to be sent to visitors, this is why
http://www.yourdomain.com/ by itself will automatically display the home or
welcoming page. It's because the server automatically looks for index.html
whenever a domain or directory is called without a filename appended to it such
as this,
http://www.yourdomain.com/file.html
If it can't find index.html, it will simply list "your entire web directory" to
everyone that access's it, which is a MAJOR security risk! ALWAYS, use an
"index.html" file in any directory you create, including your "root" web
directory. In general, it's always a good idea to use "index.html" as your main
page in "all sub-directories" of your account.
Forgetting to place an index.html in your root web, or any subdirectory of
your web for that matter will effectively leave all of its contents viewable to
the world.
Understanding case sensitivity:
Another small detail, which can throw many newer
users into a tailspin is the case of characters. Unlike your local PC, the Unix
file system is very particular about "uppercase" and "lowercase" file and
directory names. Therefore, if you were to install a script, (let's say the
wwwboard discussion board for example), the name of this script would be
wwwboard.pl. If you call WWWBoard.pl it will appear as if the script does not
work or is actually not there. This is because the UNIX system is case
sensitive. If you name a picture file "me.jpg", then this is what you must call
it as. Naming it me.JPG for example, (observe the uppercase) tells a Unix
web server to treat it as a totally different file name.
Unix file servers are exceptionally fussy on this issue, so make sure you pay
close attention to the "case" when uploading files, or installing and
configuring cgi based scripts. The same rule applies for all files including
your .html pages. Again, the server treats .html and .HTML as two entirely
different files. Want to keep in simple? Try to stick with lowercase letters in
all file names and extensions.
Uploading your files in
the correct mode (ASCII or Binary)?
Uploading files in the wrong format for images (binary files) will result in a
garbled appearance of the picture on the screen. For CGI (.cgi) or PERL (.pl)
scripts, this mistake has to be the most common cause of that annoying error
known as the (Server 500 Error - Malformed Headers), or something to that
effect. While this can be the result of many various programming errors, the
most popular among new users is uploading their scripts in the wrong
format. Your cgi scripts must always be uploaded in ASCII mode.
Alternatively, if you upload an image or .exe file, it must be done in
Binary mode.
The difference between
ASCII and BINARY?
In short, html or text based files are supposed to be transferred in ASCII
mode. Uploading them in Binary mode will append ^M to the end of every line.
In most cases, this is alright with html files because your browser will ignore
them. However, with other text files such as cgi or perl scripts, uploading them
in binary will damage them, and cause a "server 500 error". This is because
binary mode has added ^M to the end of every line, which is not supposed to be
in the program. This is what causes the additional message of Malformed Headers,
which often displays at the bottom of the "Server 500" message when a CGI script
has crashed.
Once again, Binary mode is used for transferring executable
programs, compressed files and all image/picture files. If you try to upload an
image in ASCII mode, you will see nothing but random characters the page where
the image is suppose to appear. ASCII mode has corrupted the binary coding in
the jpeg or gif image. If this happens, just re-upload it in Binary format.
Setting your FTP client to automatically detect ASCII and Binary
file transfers:
Most FTP programs have an auto mode, which tells the FTP program to
automatically detect the file type you're transferring and select the
appropriate mode. By default, most FTP programs will attempt to transfer
everything in binary mode, but when
Automatic is selected, the FTP client will check a list of known ASCII
extensions, (for example, .pl, .cgi, .txt). If it detects one of these
extensions, it automatically switches to ASCII mode.
By Default, most of the well-known files to be uploaded in ASCII are already
entered, however you can manually add additional extensions that you would
like to transfer in ASCII mode by selecting the feature called "Extensions".
Here, you can additional extensions that will cause the FTP client to toggle
to ASCII mode automatically upon detecting an extension entered in this
list. Remember, you must set your transfer mode to Automatic for this
to work. |
|
File types and what
they represent:
Various file types can effect both the behavior of your files, as well as how
the server treats them. While there are numerous file extensions, which
represent a host of various file types, we'll stick to the basic ones in this
quick overview:
The .html file:
This is one is the most commonly used and the most one of you are already
familiar with. Html stands for "HyperText Markup Language". Essentially, it
tells the server, as well as the clients browser, to process and display the
.html coding in a way that is meaningful to the end users browser.
The .htm file:
Many of you have probably noticed this newer extension appearing in place of the
traditional .html one. In short, .htm is most often created, and or generated
from the Microsoft FrontPage web editor. The two are essentially the same and
provide the same basic purpose. Unless you're using FrontPage, you will probably
use the .html extension at the end of your web pages.
The .gif and .jpg file:
Most commonly used because of their good
compression for use in web pages. Generally, .gif files are the fastest loading,
as they remove a lot of unseen information, which is not required to maintain
image integrity; but to a point, the .jpg format will allow more flexibility in
compression and quality, however jpeg's can also result in larger files.
The .cgi and the .pl file:
.cgi and .pl extensions are most often used for perl scripts.
Perl scripts are small text based programs that are executed on the server side
and perform a host of interactive functions on a web site. When a .pl or .cgi
file is called it tells the server to process it using the "Perl Interpreter."
The Perl Interpreter understands the programming within the script and will
perform the sub-routines, which will yield your desired effect. This desired
effect could be anything from a simple web page counter to more complex programs
such as discussion forums, e-commerce platforms, or online auctions. In many
cases you can download these "ready to go" scripts for free, and in others you
may have to purchase them.
FrontPage and FTP:
If you're planning on using Microsoft FrontPage
to manage your web site, there are a couple of things you may want to keep in
mind:
There are two basic types of web hosting. Unix hosting and then Microsoft. While
this is not necessarily a bad thing, Microsoft plays by its own rules. As a
result, FrontPage does not always conform to the rules of Unix, so you should be
extremely careful when accessing a FrontPage web via FTP. It's easy to damage
the FrontPage web, as well as it's associated server extensions, and if it
happens, you may loose the ability to administrate it from within FrontPage. To
avoid problems like this:
-
Do not alter or delete files that are part of a FrontPage web
-
Do not delete, move, or alter directories ending in _vtf. These
are part of the FrontPage extensions
The ultimate solution:
If possible, try to create your FrontPage webs in sub-directories of your root.
For example,
http://www.yourdomain.com/home/. This way,
you can safely FTP into your root account to perform other tasks, while avoiding
the FrontPage webs, which are safely out of the way in their own separate homes.
Remember! DO NOT delete any folders, which end in _vtf! This will kill your
FrontPage web, and we'll have to reinstall the extensions for you.
For additional information on FrontPage, please see a dedicated tutorial on
it.

|
Using CGI programming:
Where to place your CGI scripts:
Although there is nothing dangerous about placing cgi scripts in random
directories on your site, it is best if you keep them in their own known as the
"cgi-bin" directory. This minimizes security risks and allows you to maintain
your cgi programs in one common directory.
The path to Perl:
One of the first things you must do when configuring a script, is set the
correct path to the Perl interpreter, which is the engine responsible for
processing the script. The path to Perl on our servers is: #!/usr/bin/perl
|
|
The path to Sendmail:
Some programs such as those that send email will need to know where the servers
"Sendmail" program is located. The script will typically have a setting like
this:
$mailprog = '/usr/sbin/sendmail'; and will want you to set it
appropriately. Sendmail on our servers can be found here: /usr/sbin/sendmail or
/usr/lib/sendmail.
Setting
directories within your cgi scripts:
When you configure a cgi script for any server, it may ask you to set variables
such as the base, relative, and CGI directory/url settings. Here's an "example"
using Matt Wright's wwwboard.pl script. Obviously, each script may vary, but
this should provide you with some basic idea:
$basedir = "/home/username/public_html/wwwboard";
$baseurl = "http://www.yoursite.com/wwwboard";
$cgi_url = "http://www.yoursite.com/cgi-bin/wwwboard.pl";
Most scripts come with documentation on how to set these directories. Please
make sure you read and understand them before configuring. New to cgi? Here is a
page with questions and answers to numerous questions evolving around the inns
and outs of using cgi within your scripts:
http://www.w3.org/Security/Faq/www-security-faq.html Another excellent
site, which provides step by step chapters is:
http://www.cgi101.com/class/
Understanding File Permissions:
There are a number of file permissions which can be used for a variety of
different purposes, however, we'll limit this tutorial to the ones most commonly
used. To begin with, it's important you understand the three categories of
permissions, which are:
Owner Permissions:
The owner is you. In most cases, this is not so much of a concern, as you can
only obtain owner permissions in one of two ways.
1. FTP into your account using your Username and Password.
2. Login via Telnet with the same information.
Group Permissions:
This represents a group of users who have access to a particular directory. For
example, a password protected directory, whereas only members can access it upon
providing the correct Username and Password. In this case, any permissions you
assign to "Group" would be applicable to users with access to that particular
directory.
Public Permissions:
This is the most important one of all. Public permissions determine what your
site visitors can and cannot do with your files. ALWAYS make sure you understand
what a particular permission does before assigning it to a file. If not, you may
wakeup to find your website demolished by some clown who was snooping about and
gained access to your files.
Setting File
Permissions:

To set file permissions:
1. Login with your FTP client
2. Open the directory where the file you wish to set
permissions on resides
3. Right click on the file and select CHMOD
A box similar to the one above will appear
Observe how you can "select" the
individual permissions you want, or simply enter the 3 digit number if you know
what it is. Most instructions included with downloaded scripts will tell
indicate this to you.
By default, all files uploaded to the server automatically have
permissions set to 644. The setting 644 is relatively safe, as it provides
"Read" and "Write" access to the owner, while limiting the rest of the public to
"Read Only" access.
When setting permissions for cgi scripts, the most common permissions setting is
755. 755 allows the owner "Read and Write" access, while allowing the Group and
Public "Read and Execute" permissions. So what are we actually saying? In short,
when users access your cgi script, the server has been instructed to grant them
permissions to "Read and Execute" it. Sound scary? It's not actually…
Remember that a script is a program that must be processed by the server. As
long as the script is written properly, you can safely allow users to execute
it, and thus providing the desired results. For example, if they wanted to post
a message to your wwwboard discussion forum, then they would need these
permissions to execute wwwboard.pl, which would write their new message to an
html file, which is displayed on the main forum. The new message would reside in
a directory on your site so other users could view it.
Most cgi, perl and other scripts you'll be installing come complete with
instructions telling you which permissions you'll need to set them to.
WARNING!
Setting permissions on files is a relatively simple task, however, make sure you
fully understand what it is you're allowing the public to do with your files.
For example, some less experienced users often make the fatal mistake of simply
setting ALL of their files to 777. While 777 will automatically allow executing
privileges, it also allows full "READ, WRITE, and EXECUTION ability to the
entire world!!!!
This is how web sites get hacked! While most visitors have good intentions, all
it takes is one person whom snoops about your files seeking an "Open Back Door."
This could result is them gaining full access to your directories, which means
they can do anything from deleting your entire site, to defacing it with
obscenities.
Using Server Side Includes - SSI
SSI works in conjunction with a web page usually with the .shtml
extension. The .shtml extension tells the server to do something different
with the web page. When you append the .html or .htm extension, this tells
the server to "read" the page only. The .shtml extension tells the server to
"Execute" the page, in addition to just reading it.
So, why would you want to execute the page? There are various commands you
can program into a web page, which the server will look for and parse when
the file is called as .shtml. In many cases, this mode is used in
conjunction with Server Side Include (SSI) tags, to call a CGI script. For
example, you have a visitor counter script, and we'll call it count.cgi.
Every time someone visits your website, you want the script to be called, so
that it logs the visitor into a file.
To do this, you would place an SSI tag into your web page. The tag in this
case, would look something like:
<!--#exec cgi="/cgi-bin/count.cgi" -->
This small tag, which is hidden in the html coding of your page is telling
the server to:
1. Go to the cgi-bin
2. Execute count.cgi
That's it! The information has been captured and processed by the count.cgi
script. Of course, that's the short version of what happens. The long
version would no doubt, would take us far beyond the scope of this document.
PLEASE do not use the .shtml extension on "all" of your web pages unless
it's absolutely necessary. With a busy web site, this means that every page
must be executed, as opposed to just read. This, as you can appreciate, can
add considerable memory and CPU load to the system. As always, read the
instructions that came with your script carefully. They should provide
specific instructions on how to configure the script, as well as the SSI
tag.

|
|
The
ins and outs of DNS and how it effects your domain:
Understanding DNS and Name Servers:
This is an area which causes a great deal of confusion amongst both
webmasters and end user clients. Before we go any further, let's look at this
quick analogy: DNS can be considered something similar to that of a phone book.
When you move from one location to another, your last name stays the same, but
your phone number may change. In order to point your name to the new phone
number, you must contact the telephone service provider, which will assign you
the new phone number. In addition, they update all directory information data
basis to reflect you as pointing to this new phone number.
What is DNS?
DNS stands for "Domain Name Server." The domain name server acts like a
large telephone directory in that it's the master database which associates a
domain name such as (http://www.mydomain.com) with the appropriate IP number.
Consider the IP number something similar to a phone number: When someone calls
http://www.AZRiver.com, your ISP looks at the
DNS server, and asks "how do I contact AZRiver.com?" The DNS server responds, it
can be found at: 64.191.93.84. As the Internet understands it, this can be
considered the phone number for the server which houses the
http://www.AZRiver.com web site.
Where are all of the DNS records kept?
This is slightly more complicated, but for the purpose of this overview,
we'll try to keep it as general as possible. There are 2 basic places DNS
records reside:
International Root name servers (13 exist throughout the world) and your domain
registrar, where your current DNS settings reside.
When you register/purchase your domain name on a particular registrars "name
server", your DNS settings are kept on their server, and in most cases point
your domain to the name server of your hosting provider. This name server is
where the IP number (currently associated with your domain name) resides.
The entire hierarchy is somewhat involved, but in short, the world Root Name
Servers can be considered the master listing of all DNS records, and there are
currently 13 of them in the world. These name servers are where all the master
DNS records are kept. The DNS server of your ISP will typically query the Root
Name Servers once every 24-hours. This is how they update all of their DNS
tables, which in turn, resolve www requests to the IP number of the server they
reside on.
Changing your Name Server settings, so your
domain points to your AZRiver.com account:
Your "Name Server Settings" must be updated to point to your account on
AZRiver.com's servers. You originally purchased your domain name from a
registrar like Network Solutions, and this register is where your current DNS
settings reside. That is, unless you transferred your domain name to an
alternate registrar, in which case, you would control your DNS settings from
there.
The "Register" your domain resides in, communicates your 'current' DNS settings
with the International Root name servers, which is turn share this information
with ISP's, routers, and cache engines around the world. In essence, it's like a
worldwide directory that other computers can refer to when they want to match a
domain name with its associate IP number. This IP number is how the particular
server your website resides on is located.
Accessing your domain manager:
Simply go to your domain registrars web site and look around for links
which point to something like domain manager, manage domain, or something of
that administrative nature. In your welcoming email, you were sent DNS settings,
which look similar to this example of our own server:
NS1.AZRIVER.COM 64.191.93.84
NS2.AZRIVER.COM 64.191.93.85
Most of the newer registrars such as the "OpenSRS" based entities have turned
this into a 5-minute process. You simply login to your domain account, select
"manage domain" and you'll be presented with an option to update your new DNS
numbers. Contrary to popular belief, Network Solutions now also provides an
online interface to change these settings, so this process with them is no
longer as complicated as it use to be, however, it's still not as simple as the
OpenSRS based system. If your particular registrar does not provide a domain
manager of some type, then you'll need to send them a message requesting a
change of DNS. This is an unlikely scenario as most every registrar now allows
you to manage your own domain settings from a web based interface.
Once you've accessed the "management interface" of your domain name, look for a
setting which says "change or manage DNS settings." In most cases, you can
simply cut and paste the DNS settings we've sent you directly into the spaces,
which correspond to your DNS management settings. Remember, the DNS settings
we're displaying here are an "example."
The 3 to 4 day propagation period -
Understanding what happens during this time frame:
In short, patience is a virtue. Remember what we talked about earlier in
this chapter regarding the shear size and scope of the worlds DNS system? In
short, when you change your DNS settings, these new settings must propagate
throughout the worlds DNS servers. It also means that every ISP (Internet
Service Provider), must update their DNS records to reflect these new changes,
which in most cases, is done automatically every 24 hours, but not always
however...
Where do the Root Name Servers receive
their information from?
The Root Name Servers will query "domain registrars" several times a day.
Domain Registrars, being entities such as Network Solutions, Register.com and
the newer OpenSRS based systems. The Root Name Servers will gather this
information from the many registrars now in existence, and update their master
records accordingly. Now your ISP must access the Root Name Servers, and update
their DNS records, which reside on their 'local' DNS server. This process is
fully automated and most ISP's will check the Root Name Servers for updates
every 24-hours. Beware however, that some lame ISP's will delay this process for
as much as 2 to 4 days in some cases. If that happens, it will no doubt cause
additional confusion, as everyone else will be reaching your new account on our
servers except you. This is because your ISP has not updated their DNS records,
and or have not cleared their DNS cache, which means they'll still be pointing
your domain name to your old server. If it's a new domain name you've
registered, then you'll receive a blank "Site Not Found" page.
DNS Cache and your ISP:
There is also the issue of DNS cache, which is something we won't go into
great detail about here, but here's the short version. Every time you access a
site from your ISP, they cache the URL, as well as its associated IP number. If
their network is properly setup, these DNS cache records should "Expire" at
least every 24-hours. If they did not (which is often the case), you'll
experience this: You enter your
http://www.yourdomain.com
URL, and it keeps taking you back to your old server account.
In a large number of cases, it's the result of an ISP who "Did Not" configure
their servers to "Expire" the DNS cache records at the appropriate intervals.
Unfortunately, this adds additional confusion to their clients, and especially
the ones whom are trying to point their domain name to a new server. Yes, it
will make you want to scream sometimes, however, if you understand whom is
actually at fault, then you'll know who to scream at. :-)
The DNS propagation process is not limited to
ISP's!
Just when you thought you had it all figured out! Unfortunately, there's
more...The Internet itself must update/clear its DNS cache as well. When we say
the Internet, we mean the numerous intermediate "points of access" you're routed
through before reaching your final destination. For the most part, these
intermediate points of access consist of "Internet Routers" and "Internet
Caching Engines." These too maintain their own DNS cache, which assists them in
routing traffic/resolving URL's to the correct destination IP's. Don't worry
though, as Internet routers are usually faster at clearing their DNS cache than
ISP's are.
What to expect during this 2 to 4 day
propagation period:
In most cases, the propagation process will take at least 24-48 hours to
complete, sometimes longer depending on each visitors ISP. The first thing that happens is the "World Root Name Servers" will
check all of the various Domain Registrars for updates. Ok, so now the Root Name
Servers have done their job. The rest of it is up to the many ISP providers who
should be updating their DNS records (at least every 24 hours) but, as we
said, a number of them will not.
Side effects that can be expected during the
propagation time frame:
It's perfectly normal for strange things to happen within the 48-hour
propagation period, but sometimes longer. While we could provide a full list of
all the anomalies that can occur during the DNS propagation period, we'll stick
to some of the most common scenarios that most people experience:
HELP! My friends can reach my new site, but I'm still
being directed to the OLD ONE!
This is a classic case of your friends ISP (who did update their DNS
records), but your ISP unfortunately did not. As a result, your ISP is still
pointing your domain name to the old DNS record, which is your old hosting
account. Wait a couple of more days, and if it appears that everyone but you can
access your new account, then contact your ISP and tell them to expire their old
DNS cache records.
WOW! http://www.mydomain.com was taking me to my new
AZRiver.com account just a minute ago, but when I try it now, I'm being taken
back to my old hosting account - what's up with this?
In all likelihood, your ISP may be in the process of clearing their DNS
cache, and or updating their local DNS server records. During this small
interval, it's normal to fluctuate between the new and old web site, as the old
DNS records may not have completely expired from their cache yet. Give it
another several hours and it should be fine.
HEY! My new site comes up for me, but my friends
are being directed to my old one!
Break out the coffee and donuts, and consider yourself lucky. Your ISP is
on the ball and updates DNS records and/or clears the DNS cache in short regular
intervals. Your friends may be using an ISP which is not as fast, and/or as
efficient at doing so. The only remedy for this is time. Eventually, the other
ISP's DNS cache will expire and be replaced with the updated DNS records.
What's going on with my email? When I try to access
it, I receive a "host does not exist" or a "cannot authenticate" error message.
This can happen for a number of reasons, but in most cases, it's because
your new DNS records have not fully completed the propagation process yet.
Consequently, you may be trying to access your old email account on your "old
server", which you may have already cancelled, or it's in a state of DNS flux,
which means it points to the new server one moment, and the next, points back to
the old server.
Give it some more time and it will eventually settle down. In the meantime,
consider accessing email from your account using the WebMail based reader. If
your domain has not propagated as of yet, you can access your email account via
WebMail with your IP address number. Example:
http://64.191.93.84/webmail/
This will allow you to access your default mailbox on your account.
Replace the IP number with the one we sent you.
Microsoft FrontPage will not accept a Username and
Password, or displays the error message (FrontPage Extensions Are Not
Installed).
While you should be able to access FrontPage with your associated IP
number (until your domain is resolving to our servers), this is not always the
case. FrontPage can behave in a number of different ways depending on which
direction the wind is blowing. In some cases, it will allow you to initiate an
upload session, but upon asking for your Username and Password, will not
recognize them. If this happens, the best thing to do is wait until your domain
name is answering to our servers. One thing we know for sure, is FrontPage will
work without much of a problem if you're using the full www.mydomain.com URL to
manage your site with. Feel free to try it with your IP, but we cannot guarantee
it will work.
It's been over a week. Everybody else can access my
new site except me!
Was your domain originally hosted by your ISP? If so, they may not have
deleted this entry in their DNS files. This results in you, and/or anyone else
accessing the net from this "particular ISP" being directed to your old web site
on their servers. A number of ISP's forget this small detail, which can result
in weeks of utter confusion and frustration. If this is happening to you,
contact your ISP and make sure they've made the necessary changes to their DNS
records.
|
Checking your DNS update status (outside of your
ISP):
In the event you're becoming impatient, and or are wondering if the rest of
the world outside of your ISP can access your new site, you can proxy
yourself to another network and test it there. In many cases, you'll be
surprised to see your site responding perfectly, yet when you attempt it
directly from your ISP's servers, it does not exist.
There are several services, which allow anonymous surfing across the net.
While this is not the intent here, they can be used for trouble shooting
domain resolution problems. How? Because they proxy you through their
network, which means your URL requests are controlled by "their" DNS cache
records. These services update/expire their DNS cache far more often than
ISP's, which makes them well suited for testing your domain name through a
network, which operates with the latest DNS updates across the web.
To run this check you can try accessing your site through a service like
this:
http://www.anonymizer.com/
Both of them allow you to enter a URL and proxy your request through their
servers. If your site is accessible from these servers, then chances are,
your ISP has yet to expire their old DNS cache records.
Working on your account during the DNS
propagation period:
You can still work on your new account until your domain name finds it
way to our servers using your "IP Number", which was included in your
welcoming email. Your IP number is how your new domain will be identified on our
servers. Using it at this point will provide a means for you to access your
account, as well as test your new site by using something like
http://64.191.93.84/~username/
(64.191.93.84 IS the actual server IP address)
One easy way to check and see if your domain is answering to our servers
yet, is to create a file called "test.html" and place it in
your web directory. Keep checking the URL
http://www.yourdomain.com/test.html
and see if it works. When it does, you'll know your domain name is
answering to your account on "our servers", and has been officially transferred.
The personal DNS (for advanced webmasters).
Personalized Name Servers are generally used by webmasters who will be
reselling web hosting accounts, and want to add a professional look to their
DNS. Why? If you're reselling accounts under your own entity, you could use our
name servers, which would be sent to your customers in the form of:
NS1.AZRIVER.COM 64.191.93.84
NS2.AZRIVER.COM 64.191.93.85
Not bad, but what if you want your DNS settings to appear as a part of your
company? Let's say your company was www.acmewebhost.com. If you desire, you
could setup your own custom branded DNS, which could display as:
DNS1.ACMEWEBHOST.COM 66.78.4.6
DNS2.ACMEWEBHOST.COM 66.78.6.14
This provides a somewhat more professional look to your customers when sending
out your DNS settings in a welcoming email. In addition, if someone does a WHOIS
lookup on your domain name, it appears as your personal DNS, as opposed to the
company you're reselling for. Not really a big deal, but some webmasters do not
want to advertise the host they're reselling for, as they feel it does not
portray a professional and independent look.
Personal name servers are offered to clients who manage multiple domains and to
anyone who purchases a VS200 or higher hosting package. If you're not in this
category, please use the standard DNS settings we provided you. There is no
superior advantage to having your own name server unless you're a reseller or
manage multiple domains.

|
|
Setting Up Sub-Domains
What is a Sub-Domain?
A subdomain is one which resides under your top-level domain
name, but in many ways behaves as a "totally independent domain". You'll observe
that many of the larger corporations use these, as they're somewhat more
professional looking, and do a better job of creating an independent precedence
for service or product lines, which appear as separate web entities.
Example: You're a GM dealer with a site such as GM.com. You sell everything from
Pontiac's to Cadillac's. To better organize your online presence, you could
create sub-domains for your various automotive lines. These would appear as
http://pontiac.gm.com
or http://cadillac.gm.com.
Also note that in most cases the domain need not be called with the
"http://" or "www" protocol. pontiac.gm.com
can be called exactly how it appears here.
Setting up a sub domain:

Thanks to C-Panel, this task has been made easier than ever and
can be achieved as follows:
1. Login to CPanel
2. Select "Manage Subdomains" from the Subdomain menu
3. Enter the name of your new sub domain
4. Hit "Add"
That's it! Your new sub-domain is now ready for use. To find it, login to your
"main web directory" through C-Panel by selecting "files" or simply use your
favorite FTP client. You'll see it residing as another directory. Upload your
files to this directory just as you would with any other. For example, if you
created "pontiac", then a directory called "pontiac" is what you'll be looking
for.
Independent cgi-bin
All new sub-domains are created with their own independent cgi-bin. This
means your new sub-domain operates independently of everything else, and is
almost like having a whole new domain. Feel free to configure all cgi scripts
which are pertinent to the functioning of this sub domain. A nice feature as it
saves your main cgi-bin from becoming cluttered and somewhat disorganized;
especially if you utilize a lot of cgi programming.
Independent email for the new sub domain
- (In final development)
Yes, you'll observe duplicates of all "configured pop email
accounts" appearing beside the sub-domain, and or all sub-domains you've
created. Now I know you'll be tempted to use (what appears to be) a
perfectly good email address's, BUT please "Don't!" This is a feature that
is in final development. While it may look somewhat confusing at first glance,
it's really not. In the near future, you'll be able to configure these
email accounts for use with your sub-domains. For example, if you
configured
support.yourdomain.com, then you'll
be able to use the address
tom@support.yourdomain.com
For the time being, please configure email address's that correspond to your
standard "top-level" domain, and just ignore the sub-domain duplicates.
ALSO: Any duplicate sub-domain email address's you see appearing in your
pop mail setup configuration "DO NOT" count towards your allocated number of pop
mail boxes we've provided.

|
Configuring Domain Email Systems:
Adding a Pop Email account:

The difference between private pop mail
accounts, and simply using the "Catch-All" method:
There are two kinds of email address's you can use, starting with the "catch
all" method:
With the catch all method, you don't have to worry about setting up individual
pop3 email accounts. Simply set your email client to your "default" email
address (displayed in CPanel), and "all" email sent to
anything@yourdomain.com
will land in this box, or whatever you've set your default address to.
This is an easy way to catch all email sent to your domain. The drawback of this
"catch-all" method of collecting your web site email is that you will also end
up with an enormous amount of spam. This email method is not recommended!
The pop3 email account method (Preferred Method):
In this case, you configure a "private" pop3 email account for one or many
users who will be receiving and sending email from your domain. Once an email
address is configured as a pop mail account, it operates privately and
independently from the default mail system. Any mail sent to a
private pop email account "can only be received" by logging into that account
with the separate username and password you have assigned it.
Your default "catch all" account will not intercept any mail being sent to a
pop3 email account, which is what makes it 'private'. Pop3 accounts are useful
if there are a number of people (for example employees) who would each need a
private email account.
This way everyone at your company can utilize private email. The default email
address plays a slightly different role in this case: If a sender uses the
'wrong' Email name or syntax, then that message would bounce to your "default
catch all" account, and at which time, you could probably figure out who the
sender was trying to contact. They do, however, have to at least send it to your
correct domain name, (i'e', oops@yourdomain.com). This would end up in your
"default" mailbox.
|
|
How to configure a pop3 email account:

1. Login to CPanel
2. Select "Manage Accounts" in the email menu
3. Select "Add Account"
4. Enter an email name and password
5. Select "Create"
That's it, done! Your private pop3 email account is now ready for use. If
you're a little lost on how to manually configure an email account with Outlook
Express (still the most popular email program), please see the detailed
tutorials on how to configure Outlook or Netscape mail readers.
SPECIAL NOTE!
If you've enabled SubDomains you'll observe a duplicate email account which
corresponds to each subdomain you've added. Please ignore these duplicate
addresses for the time being. This is a new feature under development and will
soon enable the ability to configure email accounts for subdomains. For the
time being please configure email address's that correspond to your
"regular" domain, and just ignore the subdomain entries. ALSO:
Duplicate subdomain email addresses you see appearing in your pop3 email setup
"DO NOT" count towards your allocated number of pop3 email boxes we've provided.
In short, just ignore them for now :-)

|
Setting Your Default Email Address:

It appears pretty simple, but read through this documentation as this
controls much more that you'd expect. As mentioned in the previous chapter, your
"default" email address is the one which can be used as a "catch all", or
in other words, to "catch all mail"; which would be addressed to anything@yourdomain.com.
Using a catch all can be a blessing but most of the time it's a curse.
The "catch all" is excellent if you have a high number of people who mistype
your email address, as these addresses (even though mistyped), will simply be
bounced to your "catch all" or "default" email account. That is providing they
at least managed to spell your domain name properly :-)
If you're not planning on using multiple "private email boxes", then you can
keep life very simple - just configure the default email address in your mail
reader and leave it at that. This way, you'll receive everything sent to your
domain. There are indeed pro's and con's to this method, which will be discussed
in the following tutorial.
Setting your default/catch all email account:

Note: By default, or until you change it, the
default email address will be the same as your "log-in name."
1. Login to C-Panel
click on the "Mail Manager" icon
or select #2 below.
2. Select "Default Address"
3. Select "Set Default Address"
4. Enter a desired default email address
Just enter a name, "@yourdomain.com" part is added automatically
Select "Change" and you'll see a confirmation box, which
displays your new default email address. That's it, you're done!
Remember:
In order to receive mail which finds its way into your "Default Mailbox",
you must configure the default address in your email program (i.e. Outlook
Express). If you don't, then all mail which bounces to this address will sit on
the server unread. This is easy to do in Outlook Express, as it allows you to
configure and monitor multiple email accounts. Email readers such as older
versions of Netscape, on the other hand, are limited to "one" email
account. Actually, you could re-configure your email reader to check your
default email box every few days, but who wants to be bothered with that
trouble? We suggest using an email reader which allows you to configure multiple
pop3 email accounts.
The Webmail Alternative:
You can also check your default email account, or another other mail
account by logging into it through the "WebMail" interface. Log into your
control panel, click on the "Mail Manager" icon, select "WebMail" and log in to
it using your "Main Account" Username and Password. This will
allow to to check your default email box, as well as other mailboxes without
having to configure them in your email reader. In fact, using any pop3 accounts
"Username and Password" will log you into that particular account through the
"WebMail" interface.
NOTE: When logging into any email account, whether automatically using
an email program like Outlook Express, or through the WebMail interface, you
must use the whole email address as the username, e.g. "dave@daveshome.com".
The downside of enabling the "Catch All":
Problems can sometimes arise when Spammers or junk mailers use this
feature as a means to pump their trash into your mailbox. As long as the "catch
all" is enabled, then all they must do is send email to any name @yourdomain.com
and it will reach you.
On the other hand if you're using "specific pop3 email accounts", you could
opt to disable the "catch all", which would mean that only visitors or
associates who you've given a specific address to can send mail to a particular
email account on your domain.
In this case everything else, (that you have not configured as a pop3 email
account) is bounced back to the sender. In our opinion, we suggest leaving your
"catch all" enabled for the time being. If Spammers begin sending random junk
messages using anything@yourdomain.com, then you can disable your "catch all"
feature.
Disabling your "Catch All Feature"
Instead of entering a syntax correct name, like "alex231" or "jon12u" use one of these command
alternatives shown in bold:
:fail: no such address here
This "FAIL" command returns (bounces) all un-routed email
with "no such address here" as an attached error message. This is the
preferred setting for your default email account. It sends an error message to
the sender and it keeps the CPU usage to a minimum because the server doesn't
have to download and filter the message first, it's simply rejected with a
bounce message of "no such address here".
:blackhole:
The BLACKHOLE command deletes all incoming email but does not return or bounce
anything. Additionally, this setting can cause the CPU to overload during peak
periods because the server will still have to process the mail even though it is
not addressed to a legitimate user. We reserve the right to force email bouncing
in the event our server is adversely effected by a users default account
receiving too much unrouted email.
 |
Configuring Email Auto Responder's

What is an Email Auto Responder?
Email auto responders will automatically send a customized auto response (that
you compose) to any visitor whom emails the address configured with one. More
specifically, automated responses are sometimes used to send additional
information about your service or product by having a visitor email something
like moreinfo@yourdomain.com. In most other cases, they are used to send a
'courtesy reply' to anyone who sends a query to your companies main email
address. When visitors email this address, they receive a response such as:
Thanks for contacting our company! Someone will be replying to your email soon.
If you require immediate assistance, please call 555-222-1212. Thanks!, and
so forth.
There are two types of Auto Responders:
The silent Auto Responder:
In this case, you configure the responder to send the desired information
when it's emailed, however you 'do not' receive copies of the
inquiries that people originally sent. This method is typically used if you have
a product and want people to email an address for additional information on
it. You simply tell them to email moreinfo@yourdomain.com, and they receive
additional information on it. Again, you 'will not' receive receipts of the
visitors emailing the auto responder. If you want to do this, please read the
next paragraph.
The Auto Responder that sends you the original inquiry:
In this case, the auto responder is setup to work with a
currently configured pop email account.
Now the sender receives your automated response, and you receive their original
inquiry.
How to setup an Auto Responder:

1. Login to CPanel
2. Click on the "Auto Responders" link from the email menu
3. Select "Add Auto Responder"
4. Enter the "Email Address" to send the auto response
5. Enter a "From" name, (for example, my company)
6. Enter a "Subject", (for example, thank you)
7. Enter your message in the "Body" area
Select "Create"
and that's it! Your auto responder is now online. To test it, email its
address and see if you receive the auto response. If you've configured it to an
existing pop3 email account, you should receive 2 responses. The first, which is
your inquiry, (that you just sent to yourself), and the second, which will be
the automated response.
Remember! If you want to receive the "Incoming Inquiries" in
addition to sending the automated response, then add an email address, which is
already configured as a pop email account. If you do not wish to receive
the original incoming inquiry, then simply enter a name, which
is not configured as one of your existing pop3 email accounts.
If at anytime you want to update, edit, or delete an auto response, simply go
back into "Auto responders" and you'll see the current responders configured, as
well as options beside each of them to change or delete.

|
|
Blocking Unwanted Email Messages:

From time to time you may experience either a junk mailer or some other
menacing individual who keeps sending you annoying email messages. C-Panel has a
built in feature that allows you to block these email messages in a multitude of
ways. You can block them by:
- Sender
- Subject
- Message Header
- Message Body
Of course, if all you want to do is block one specific email address,
then you don't have to worry about getting fancy with it; just enter the email
address to be blocked, and that's it, your done!
How to use the block email function:

1. Login to CPanel and select "Email Filtering" from the email menu
2. Select "Add Filter"
If all you want to do is block a single email address, then simply leave the
current setting as it is, and enter in the email address to be blocked, for
example,
annoying-nolife@nothingbettertodo.com,
click "Activate" and that's it...
When you click "Back", or login to this feature the next time, you'll see
the list of email addresses, and or expressions you've blocked. Beside each one
of them will be a "Delete" option, so that you can remove the block from your
account at a future time. NOTE: When you block an email
address, or some other keyword, this filtering will be enabled on "All Email
Accounts" within your domain.
Advanced Blocking:
For those of you who experience frequent problems with junk email
messages, you'll be please to see this option provides a broad range of
blocking. Instead of having us try to explain every last one of them here, this
is a feature you'll really want to experiment with yourself.
Doing so will allow you to become familiar with the ways that email can be
blocked and will also help you with customizing a recipe that works best for
your domain. Play around with the settings, and try to block words, or phrases
based on the From name, Subject, or Message Body. Now, send an email to your
account and see if the terms and criteria you selected are providing the
filtering you want.
It may take a little time to master but it's fun, and a great way to broaden
your abilities on web site administration.
FINAL NOTE: If you're totally new to email blocking and
wish to explore its full potential, we highly suggest you test it before
launching your site. This way you don't have to worry about accidentally
disrupting email for your entire domain.
Hint: Unless you're 100% sure of what a setting will do,
always delete it when you're finished, or until you have time to run a series of
tests on it. You want to ensure it is blocking what it's supposed to, and
not legitimate email messages!
A big junk mail problem:
If you're experiencing a high volume of junk mail, then there's a good
chance Spammers are taking advantage of your "catch all" option. To disable
this, please see our tutorial on "Default Email Address."

|
Email Forwarding:

Email forwarding is a feature which forwards an email - that originated from
your domain - to another email address. The forwarding address can be another
email address within 'your domain', or an 'external email' address, (for example
to your home ISP email account). There are two types of email forwarding:
Forward silently to another address:
In this case the email address from your domain (setup for forwarding)
will divert all messages to the forwarding address you've selected without
sending you a copy of the original message. For example, you@yourdomain.com will
automatically forward all messages to you@mindspring.com. Pretty straight
forward.
Forward to another address, but also send you the "original inquiry":
This is the method most commonly used. For example, you have two other
partners who wish to receive all incoming inquiries to the company. Perhaps
you're the one who responds to them, but your counterparts would like copies of
the incoming activity as well. The method for accomplishing this is pretty well
the same as above, except in this case you would configure one of your existing
pop3 email accounts, as this is how you'd receive a copy of the original
incoming message.
Example: When General@company.com (your companies main address) is mailed, you
would typically be the only one to receive the response, however if you've
configured forwards for your two counterparts (Bob and Mary), then bob@doodles.com
and mary@yourdomain.com would also receive a copy of the incoming email
messages.
How to setup a mail forward:

1. Login to CPanel and select "Forwarders" from the email menu
2. Select "Add Forwarder"
3. Enter a configured pop email account name if you want to receive original
inquiries. (Enter a non-configured email address if you do not)
4. Enter the email address you want it to relay a copy of the message to
5. Select "Add Forwarder"

All messages will now be forwarded to the
forwarding address with a copy sent to you.
Need to Forward to more than one
person?
Simply repeat the above process using the same address you've setup as the
forward and enter the additional recipients you would like to send a copy of the
message to. All email forwards will be listed in your "Email Forwarder"
administrator. You can delete forwards when you no longer require them.
Testing your forward.
If you want to test your new email forward, it is recommended that the
email account you're testing from
is not one of the accounts you're using in conjunction with the forwarder
you've just setup. For example, if you've configured harry@yourdomain.com to
forward copies to bob@doodles.com and mary@yourdomain.com, then send a test
message from an email address other than one of the addresses you've just setup,
otherwise it can somewhat confusing in figuring out which message was coming
from the actual forward and which was the original sent from you.

|
Accessing your mail through the web based interface
The CPanel extends the versatility
of the email system by allowing you to access any one of your email accounts
through its own WebMail interface. You have the choice of accessing all mail
through the web, or any of your private pop3 email accounts. Gone are the days
of having to create several email accounts on various free html based mail
systems as now you have your own, which operates from "your account."
Accessing your mail through the CPannel "webmail" interface:
Login to CPanel and click on the "Manage Accounts" link in the email
menu. Or you can also use the following URL's:
http://dedicated.azriver.com/webmail/ or http://yourdomain.com/webmail/
To the right of the email account you wish to access select the
"Read WebMail"
button. A username and password prompt will appear, and are the same
as the username and password you created with that particular account.
NOTE: Remember to use the full
email address as the account
login name for the account you're accessing.
|
The first screen you'll see:
If it's the first time you're accessing this email account through WebMail,
a setup screen may appear. Actually, all this really does is display how you'll
be identifying yourself in email messages. Everything is pretty much the
same as what you setup as the original pop3 email account, however, check it
closely and make sure everything is appears as you want it.
Does everything look correct?
If so, then click "Save" and a dialog box pops up, which confirms your
settings as being saved successfully. Click
"Continue"
and you'll be taken to your WebMail inbox. You will have two webmail
options, Neomail and Horde. They are both an interface program to send and
receive email using your web browser. Try them both and see how which you
prefer. |
| |
|
Using an SSL
(Secure Socket Layer) Server
NOTE: Our new SSL certificates are
currently pending and should be installed by January 31, 2006. A Wildcard
secure server will be available for use after this date.
You can secure (using 40, 128, and 256-bit encryption) any web page on your
site by serving the web pages from a secure server. A secure server is also
commonly referred to as an "SSL" server. Data packets (web pages, credit card
numbers, etc) served from an SSL server - or sent from your computer from an
online form - are sent over the internet encrypted so that the data cannot be
viewed by anyone who may be snooping. SSL is particularly useful in ecommerce
for things like shopping carts and/or online banking because the end user can be
assured that their personal information is secure while in transit, this
includes usernames, passwords, credit card numbers and the like. The information
is decrypted at both ends (on your computer and on the server) but in between it
cannot be read by anyone. It would take the most sophisticated government two weeks to decrypt
anything that is secured at 128-bit encryption, the current standard for
internet use, and the same level of protection we use on our SSL servers.
There are two ways you can use SSL on your web site. You can
use the free "wilcard" SSL server that is included with all hosting accounts, or
you can purchase your own "personal" SSL certificate and we can install it for
you.
|
Free "wildcard" SSL
server usage:
Your free "wilcard" SSL server is located here, all SSL
servers start with "https" instead of just "http":
https://dedicated.azriver.com/~username/
Just substitute "username" with your own account username and
your web site will show up as encrypted, you will know it's encrypted by the
padlock icon which shows up near the
bottom right section of your browsers status bar.
You should only use SLL to secure one or two pages, like for
the checkout form of an online store. The secure URL for such a page would look
something like this:
https://dedicated.azriver.com/~username/anypage.htm
The drawback to any SSL server is that it is a little slower
than a normal server. This is because the server and your browser must take more
time to encrypt/decrypt the data before it can be transmitted and/or presented
on your computer screen. Another drawback are the occasional warning messages
about the server name not matching the certificate; or one that might look
something like this:

Clicking "yes" will serve the page unencrypted,
so you must tell your customers in advanced to click the "no" button to keep the
page encrypted, however, some images or scripts may not work properly or show up
on the page. The above warning occurs when pictures or scripts embedded in the
web page are called from outside the secure server. The way to halt this warning
message is to call images from the secure server as well, this will require
editing the html of your web page so the image or script links are called using
the "https" protocol and not simply "http". Here's an example for an image:
<img src="https://secured-domain.com/images/picture.gif>
Using the https protocol within the secure
page to call a picture(s) will stop the annoying warning message shown above.
Purchasing
your own "personal" SSL certificate:
Warning messages about a name mismatch can only
be solved by purchasing and installing a "personal" or custom certificate for
your web site from an SSL certification authority like
Thawte and these certificates can
cost between $100 and $600 or more a year depending on the type of certificate and who
you get it from. The benefit of having your own SSL certificate is that your
secure URL can be more like this:
https://yourdomain.com/anypage.htm

|
|