By default WordPress uses web URLs which have question marks and lots of numbers in them, however WordPress offers you the ability to create a custom URL structure for your permalinks and archives. This can improve the aesthetics, usability, and forward-compatibility of your links.To use the two pre-defined permalinks format you need to:

 1.  Enable these two settings in your PHP 4 php.ini file:

cgi.fix_pathinfo = 1
cgi.force_redirect = 0

This will allow these two permalink options to work:

Date and name based:
» http://YOURDOMAIN.COM/index.php/2007/11/21/sample-post/

Numeric:
» http://YOURDOMAIN.COM/index.php/archives/123

2. Make sure your PHP version is set to 4 in your control panel and set to use the FastCGI and not the ISAPI version.

Notice that you still need to have the index.php file in the permalink structure.  This permalink option uses wordpress to rewrite the URL format using native PHP 4.

ADVANCED - USE A ISAPI URL REWRITER
If you wish to use a Custom Permalink Format and do more advanced URL Rewriting then you will need to ask support to install the IIS ReWrite DLL for your site.  You can then use regular expressions to do URL rewriting much like that of the linux mod_rewrite module.

Here is an example of entries needed in your IsapiRewrite4.ini.  This file will be located in your httpdocs directory.  This example is written for a wordpress blog that is:

1.  Installed in the root of the website.
2.  Uses a Custom Permalink of:  /%post_id%/%category%/%postname%.html

#RewriteLog  C:\Temp
#RewriteLogLevel 3

# MaxMatchCount
#
# Specifies the maximum number of sub-expression matches to
# capture for a single pattern. This specifies the size of the
# array in the C module.  If you have a pattern with more than
# the default number of matches, set this number.
#
# The default is 10.

MaxMatchCount 10

The most typical method for having your website accessible via HTTP/SSL, would be to upgrade your hosting plan to use a dedicated IP address, and purchasing and installing an SSL Certificate issued to your domain name, www.yourdomainname.com for example.  At that point, people could access your site one of two ways:

• http://www.yourdomainname.com
• https://www.ourlittleuniverse.com
  

BOTH of these would serve files from your httpdocs folder, your website root.... the only difference would be those accessing it with the HTTPS would have that transfer of files/information encrypted as it traversed back and forth.  This is the ideal solution for an ecommerce based website. 

As a lower cost alternative, we have a feature that is called SharedSSL... it provides a method for having content on your site accessible through an HTTPS connection without the expense of a dedicated IP address, and an SSL certificate issued to your domain name.  When you enable SharedSSL, your httpsdocs (note the "s" in the name) folder becomes available and accessible through what we call the "shared SSL url".  The exact SSL URL will vary some depending on which server you are on (details are below), but for example, let's say the SSL URL is https://ssl18.3essentials.com/something where "something" is a virtual directory name that you specify when you enable SharedSSL in your control panel. 

So in this case... you end up with:

• http://www.yourdomain.com serves content from your httpdocs folder
• https://ssl18.3essentials.com/something serves content from your httpsdocs folder
  • And on our most recent version of plesk (plesk 8.x) .. you can actually make the shared SSL url point to your httpdocs folder, rendering the httpSdocs folder moot/obsolete.
    

• WEB2 and WEB4
  • The Shared SSL functionality is not available on these servers.  Please submit a support request indicating you are interested in this functionality, and the support team will coordinate with you to move you to a hosting plan and server which supports this function.
• WEB6 and WEB8
  • The shared SSL function is available to any and all customers, no changes are necessary by the customer or by us, no settings have to be made. 
  • The shared SSL url is: https://webX.3essentials.com/customerdomain.com
    • where webX = your web hosting server, either Web6 or WEB8.
    • and "customerdomain.com" = your domain name.
  • This Shared SSL URL points to your httpdocs directory... so, for example, a file called myfile.html can be accessed in two different ways:
    • http://www.yourdomain.com/myfile.html
    • https://webX.3essentials.com/yourdomain.com/myfile.html
• WEB10, WEB12, WEB14
  • Log into your control panel, click on your domain, click on the SHARED SSL icon
  • Click the ENABLE SHARED SSL checkbox, and add a Virtual Directory name, click ok.
    • the virtual directory name can contain dashes "-" or underscores "_" but cannot contain a period ".". If you attempt to create virt dir with a "." in the name, you'll get an error that it contains an improper value.
    • If your domain name is mysite.com, you may want to use a virtual directory name like: "secure-mysite" or "mysite_secure".
  • The https URL you will use will be https://webX.3essentials.com/virt_dir_name where:
    • webX = your webserver (web10, web12, etc.)
    • virt_dir_name = the virtual directory name you specified in the "shared ssl" section of the control panel
  • Important Notes: 
    • This "shared ssl virtual directory" does not point to the HTTPDOCS folder on your site... instead, it points to the HTTPSDOCS directory (notice the difference: httpdocs vs httpsdocs).   As such:
      • All of your regular site content will go into your httpdocs folder, and be assessible via http://www.yourdomain.com
      • All of your secure site content will go into your httpsdocs folder, and be accessible via https://webX.3essentials.com/your_virt_dir
    • Currently, you cannot use ASP.NET content in the SharedSSL/HTTPSDOCS folder on these servers. This is due to an incompatibility between the Plesk implementation of this feature, and ASP.NET security requirements.  Our engineering team has resolved this on newer built servers - see ASP.net and SharedSSL incompatibility
• WEB16 
  • Log into your control panel, click on your domain, click on the SHARED SSL icon
  • Click the ENABLE SHARED SSL checkbox, and add a Virtual Directory name, click ok.
    • the virtual directory name can contain dashes "-" or underscores "_" but cannot contain a period ".". If you attempt to create virt dir with a "." in the name, you'll get an error that it contains an improper value.
    • If your domain name is mysite.com, you may want to use a virtual directory name like: "secure-mysite" or "mysite_secure".
  • The https URL you will use will be https://ssl16.3essentials.com/virt_dir_name where:
    • virt_dir_name = the virtual directory name you specified in the "shared ssl" section of the control panel
  • Important Notes: 
    • This "shared ssl virtual directory" does not point to the HTTPDOCS folder on your site... instead, it points to the HTTPSDOCS directory (notice the difference: httpdocs vs httpsdocs).   As such:
      • All of your regular site content will go into your httpdocs folder, and be assessible via http://www.yourdomain.com
      • All of your secure site content will go into your httpsdocs folder, and be accessible via https://ssl16.3essentials.com/your_virt_dir
• WEB18 
  • Log into your control panel, click on your domain, click on the SHARED SSL icon
  • Click the ENABLE SHARED SSL checkbox, and add a Virtual Directory name, click ok.
    • the virtual directory name can contain dashes "-" or underscores "_" but cannot contain a period ".". If you attempt to create virt dir with a "." in the name, you'll get an error that it contains an improper value.
      • If your domain name is mysite.com, you may want to use a virtual directory name like: "secure-mysite" or "mysite_secure".
    • Unlike earlier versions of this feature (which pointed this virtual directory to the httpSdocs folder), on web18's Plesk 8 version, you get the choice of whether your sharedSSL virtual directory points to your httpdocs or httpSdocs.  Choose which you prefer when you set this up.  If you're unsure, we'd recommend setting it to "httpdocs".  You'll see below in the "important notes" how your content will be accessed, and we believe it just makes it easier to keep it all in one place.
  • The https URL you will use will be https://ssl18.3essentials.com/virt_dir_name where:
    • virt_dir_name = the virtual directory name you specified in the "shared ssl" section of the control panel
  • Important Notes: 
    • If you set the "shared ssl virtual directory" to point to your httpSdocs folder:
      • All of your regular site content will go into your httpdocs folder, and be assessible via http://www.yourdomain.com
      • All of your secure site content will go into your httpsdocs folder, and be accessible via https://ssl18.3essentials.com/your_virt_dir
    • If you set the "shared ssl virtual directory" to point to your httpdocs folder:
      • All of your content (files) should go into your httpdocs folder, and be assessible via http://www.yourdomain.com  OR by https://ssl18.3essentials.com/your_virt_dir
      • You should put NO content (files) into your httpSdocs folder, as it will be unused.

         WEB20

• Log into your control panel, click on your domain, click on the SHARED SSL icon
• Click the ENABLE SHARED SSL checkbox, and add a Virtual Directory name, click ok.
  • the virtual directory name can contain dashes "-" or underscores "_" but cannot contain a period ".". If you attempt to create virt dir with a "." in the name, you'll get an error that it contains an improper value.
    • If your domain name is mysite.com, you may want to use a virtual directory name like: "secure-mysite" or "mysite_secure".
  • Unlike earlier versions of this feature (which pointed this virtual directory to the httpSdocs folder), on web18's Plesk 8 version, you get the choice of whether your sharedSSL virtual directory points to your httpdocs or httpSdocs.  Choose which you prefer when you set this up.  If you're unsure, we'd recommend setting it to "httpdocs".  You'll see below in the "important notes" how your content will be accessed, and we believe it just makes it easier to keep it all in one place.
• The https URL you will use will be https://ssl20.3essentials.com/virt_dir_name where:
  • virt_dir_name = the virtual directory name you specified in the "shared ssl" section of the control panel
• Important Notes: 
  • If you set the "shared ssl virtual directory" to point to your httpSdocs folder:
    • All of your regular site content will go into your httpdocs folder, and be assessible via http://www.yourdomain.com
    • All of your secure site content will go into your httpsdocs folder, and be accessible via https://ssl20.3essentials.com/your_virt_dir
  • If you set the "shared ssl virtual directory" to point to your httpdocs folder:
    • All of your content (files) should go into your httpdocs folder, and be assessible via http://www.yourdomain.com  OR by https://ssl20.3essentials.com/your_virt_dir
    • You should put NO content (files) into your httpSdocs folder, as it will be unused.

If you require HTTPS/SSL access to your site to use your own domain name exclusively (i.e., https://www.mydomain.com instead of the https://webX/yourdomain-virt-dir), then you need to upgrade your hosting plan to provide for your own SSL certificate.  This requires:

• adding a static/unique IP address to your site
• purchase of an SSL certificate.

Please submit a support ticket indicating you wish to do this, and we'll advise you of pricing and options, and assist you through the process.

It's important to note that a CGI executable is NOT a standard executable.  A CGI executable is not a standard exe file.  You can't just take a standard DOS or Windows executable program and run it as a CGI application on a webserver that supports CGI (even a Windows/IIS webserver).   A CGI application must be written to the CGI 1.1 Specification, including implementation of certain standards for input and output. 

Reference: http://blogs.msdn.com/david.wang/archive/2005/08/14/HOWTO-Setup-a-CGI-EXE-on-IIS.aspx

Running CGI executables:

In order to run a CGI a CGI executable on your website hosted on either our Windows Shared Hosting plans or Windows Dedicated Managed server plans:

1. the application/executable must written to the CGI 1.1 specification
2. the CGI executable must be placed in the "/cgi-bin" directory off your FTP root (this is not below httpdocs, it's at the same level as httpdocs).
3. submit a support request asking us to enable CGI execution of that executable... if you have more than one cgi executable file, we must enable execution for each executable (you can specify multiple executables in a single request).

CGI executable sample:

The associated download is a sample CGI executable which you can use on your site to test CGI executable execution... be sure to follow steps 2 and 3 above to ensure you're placing into cgi-bin directory (unzipped), and requesting cgi execution be enabled before you attempt to use the sample.

If you've properly followed those steps, when you visit www.yourdomain.com/cgi-bin/cgi-test.exe you will see

This is a test
Time: current date and time

Thank you to customer Daniel Jette for sharing this sample.

What is SMTP-AUTH?  And why is it required on 3Essentials hosting services to send mail?

Answer:

In order to protect 3Essentials servers and network from being used by spammers, 3Essentials requires SMTP-auth to be enabled on any method it's customers use to send mail.  There are basically two methods for sending mail:

• from a mail client, like Outlook, Outlook Express, a webmail tool, etc.
• from your website code, i.e., a webform in PHP, ASP, ASP.net, etc. that collects information from a visitor, and sends an email to you with it.

Before spammers, providers and mail server administrators did not require you to authenticate to a mail server before you sent an email via one of these methods... you could simply connect to the server via SMTP, and send the mail.  But with the pervasive and intrusive nature of spammers, they've exploited this... and now any mail server that allows you to connect "unauthenticated" (i.e., not identifying who your are, and being authorized to send mail), is considered an "open-relay" for mail, and open-relays are a dirty word in the hosting business.

The best first line of defense is to require all people who send mail from your server to have a predefined username and password, and to use that when making the connection to the mail server.  This is SMTP-auth... an SMTP connection which requires "authentication" of your user id / pw before sending mail.  Each method for sending mail implements this slightly differently:

• For desktop mail clients (Outlook, Outtlook Express, etc), the mail client configuration screens will have options for "smtp authentication" being required for the SMTP server.  The following KB articles lead you through configuring popular mail clients to support smtp-auth:
  • Configure Outlook or Outlook Express to send/receive mail
• For website code / scripts, the solution will vary slightly:
  • For ASP, you'll need to use a mail component that supports SMTP authentication.  3Essentials provides Microsoft CDO (aka CDOSYS) and JMail components for this purpose.  Information on those components, and sample code, can be found at the following KB articles:
    • Sending mail from a web page using ASP and JMail 
    • Using CDONTS for sending mail
  • For ASP.net, use System.Net.Mail:
    • http://www.systemnetmail.com/faq/4.2.aspx
  • For PHP:
    • If you need to send mail from your own designed PHP page, you'll need to use the PEAR MAIL function.  Info on this function and sample code can be found in the following article:
      • Sending mail with PHP using SMTP-auth
    • If you're using an open source PHP application, the solution may vary slightly.  First, check the email settings configuration option for the product, and if it has options for sending mail via SMTP, SMTP-auth, SMTP username and SMTP password, then it probably supports it out of the box, and you just need to configure those options.  A few common open source products do not support this with their base/default installation, and an add-on is required.  The following KB articles provide info on enabling SMTP-auth for some common, open source, PHP based solutions:
      • Adding SMTP-auth support to OSCommerce
      • Enabling SMTP-AUTH support in phpBB
      • Adding SMTP-auth support to Wordpress
        
      • SMTP-AUTH support in Sitebuilder 4.x feedback form

What is a subdomain?

Answer:

Within webhosting, a subdomain allows you to create an entirely separate website within your main domain's namespace.  For instance, if your main site is mydomain.com (also accessible by www.mydomain.com), you can create/add a subdomain called shop.mydomain.com... or forum.mydomain.com.   This will be a completely separate website from your main site.  It does, however, share the same limits (disk space, transfer, mem usage, etc) as the main or parent domain.

When you create a subdomain, you have the option for the subdomain to use the same FTP user or a unique one:

• If you chose to use the SAME ftp user as the main/parent domain:
  • Make an ftp connection to the server just like you would to your main site.  You'll see the following directory structure (we've populated this example with sample subdomains "forum" and "shop"... change directory to the subdomains subfolder for the subdomain you created:
    • httpdocs <= website root for mydomain.com (a.k.a. www.mydomain.com)
    • htpsdocs
    • statistics
    • webusers
    • subdomains
      • forum
        • httpdocs <= website root for forum.mydomain.com
      • shop
        • httpdocs <= website root for shop.mydomain.com
• If you chose to use a UNIQUE ftp user:
  • Make an ftp connection to the server using the unique ftp user/password you created for the domain.
  • Once connected, your will be in the ftp root for the SUBDOMAIN (the ftp server distinguishes what directory to place you in based on the user).  So at this point, you'll only need to change directories to the /httpdocs, and publish your files there.   Using the example above, if you set the forum subdomain up to use a unique ftp user, then when you make an FTP connection with that user, you'd be put into the directory "forum".

Most of our plans include subdomains, and may include unlimited number of subdomains.  To determine how many are included with your hosting plan, please log into your control panel and check the LIMITS icon to determine if and how many subdomains your plan includes.

Follow up question:

Is this the same as a Subweb in FrontPage?

Answer:

No.  Actually this is completely different.  A subweb in FrontPage is a "frontpage only" concept... With FrontPage, you can treat a subfolder on your site (like mydomain.com/shop) as a a regular subfolder, or as a "subweb".  If you set as a subweb, then that subweb has it's own FrontPage configuration options, separate from the primary domain.

A subdomain is not a FrontPage subweb... just looking at the URLS can illustrate that:

• shop.mydomain.com - a subdomain, a completely separate website on the webserver.
• mydomain.com/shop - a FrontPage subweb, still part of the main site, but a space where FrontPage allows for different FrontPage configuration options than the main domain. 

Follow up question:

So, can I use FrontPage to create a website for a subdomain, and publish to it.

Answer:

Yes.  Within FrontPage, a subdomain will be a completely different website than your main domain.  So create a NEW WEB in FrontPage, and create the files for your subdomain there.  Then, when you're ready to publish, publish to http://mysub.mydomain.com (where you'd replace "mysub" with whatever your subdomain name actually is).  When prompted for the FrontPage user and password, you provide FTP user and password you specified when you created the subdomain (this is discussed above in the first question, where you had the option of the subdomain using the SAME ftp user as the main domain, or creating a UNIQUE ftp user (the ftp user is the frontpage user).

http://www.dnncreative.com/Tutorials/DNNTutorialsforAdministrators/MultiplePortals/tabid/300/Default.aspx

Answer: Both terms relate to the amount of data you can transfer between your server and the people who visitor your site on our server.  Both are sometimes used interchangably, but they are actually 2 different ways of buying that same resource. 

Transfer refers to the total number of BYTES of data transferred in a given period of time.  3Essentials hosting plans include X amount of bytes of transfer for a month... for instance 100GB (roughly 1 billion bytes).

Bandwidth refers to the amount of bytes transferrable in a period of time, for instance 1Mbps, means 1 million bytes per second.  Now, this term "bandwidth" can be used to refer to describe CAPACITY or AVERAGE UTILIZATION:

• THROUGHPUT CAPACITY:  For example, on our dedicated server plans, we typically connect your server to a 100Mbps connection, which is then connected to a gigabit ethernet backbone.  So the "pipe" through  which data flows to your server, is maximum throughput capacity of that 100Mbps connection to your server. 
• AVERAGE UTILIZATION: to reflect average usage...  for instance, let's say that same dedicated server hosts a small website, which doesn't get much traffic... it may only actually utilize .5Mbps on average through the month.   At the end of the month, we average your utilization, if it's 1Mbps or below, you're fine.  If it's over 1Mbps, say 1.5Mbps, then there is a charge for the additional usage. 

Think of your residential water service as a perfect example of a similar concept...

• The city might be able to deliver you 100 gallons per minute, that's your THROUGHPUT CAPACITY of your BANDWIDTH.  We'll say 100GPM for shorthand.  That's the fastest RATE at which you could get water coming into your house if you opened every faucet in your home wide open.
• At the end of the month, you used 1000 gallons.  That was your TRANSFER... the total number of gallons TRANSFERRED to your house during that month.
• So you used 1000 gallons in a month... the average usage in "gallons per minute" would be 1000 gallons divided the number of minutes in a month.  This actually comes out to be= .023 GPM.  So this is your AVERAGE UTILIZATION of your BANDWIDTH. 
• You can see there that even though BANDWIDTH can be used to mean both CAPACITY (100 GPM) and AVERAGE UTILIZATION (.023 GPM), there can be quite a difference between the two.  
• Now the question... how do you want to pay for your water?  total gallons usage?  or average utilization, Gallons Per Minute?  Well... it depends on how you use your water, doesn't it? 

When you're purchasing a hosting plan, you'll find you may have some options as to whether you purchase TRANSFER or BANDWIDTH with your hosting.  For 3Essentials, you'll find the following:

• On our SHARED HOSTING plans, we only offer the TRANSFER option... the total number of bytes transferred per month.  Then you say "how much do I need?"... well the simple rule is, if you have to ask that question, then you only need the smallest amount available in our plans.  Seriously... if your site has heavy transfer needs, you'd know it by now, and you'd know exactly how much you need!  If you are coming from another hosting provider, you should actually be able to get exact statistics from your previous hosting provider that would tell you exactly how much monthly data transfer you've used historically.  Our shared hosting plans are LOADED with transfer... and you can upgrade plans to get more transfer at any time without a charge for upgrading plans.  So look at your OTHER needs for plans (like # of databases, etc), and don't worry much about transfer.   Our control panel will provide you with a daily report of your transfer usage.
• On our DEDICATED SERVER hosting, you have the option of purchasing this resource by either TRANSFER (total number of bytes transferred in a month) or by BANDWIDTH (Mbps)/ average utilization.  Which you chose will depend on you, your site and your preferences.  It's a little like  the myriad of cell phone plans... it all depends on your calling patterns.  The Bandwidth options are available at 1Mbps and go up to whatever you need.  This doesn't mean your maximum throughput capacity is 1Mbps, it means you're paying to use up to an average of 1Mbps with no additional charges.  We do this averaging based on the 95th percentile method.  We sample your usage and discard the highest 5% (this helps you with any spikes you had). 
• Again, if you're just starting out, and you don't know your network needs, don't worry too much about it, pick one or the other, and pick a minimal option.  We can always adjust your bandwidth pricing as your demands grow.

Windows Web Hosting has been around for several years now and has evolved from simple HTML pages hosting small simple sites with a few images into full blown web based hosted applications where end users can visit a site, interact with the web site owner and even purchase goods and services all over the internet.

Web hosting platforms vary from different types of operating systems. Microsoft Windows Server and Redhat Linux are just two examples and probably the most well known web hosting platforms. So, what is Windows web hosting and what are the advantages and disadvantages to hosting your web site on a Windows Server. Well, that's just the answer isn't it ? Windows Web hosting utilizes the Microsoft Windows Server operating system to host websites containing simple HTML pages and even applications written in ASP or ASP.NET. Windows uses a built-in application or "service" called Internet Information Services (abbreviated as IIS). IIS is the "Service" or "application" that runs on a windows server that is responsible for serving or rendering your HTML pages to a browser. Whenever you visit a site, say www.3essentials.com and you view the content, your web browser is "downloading" or "Viewing" the pages that are stored on our Windows Server, via IIS.

Why use Windows and not Linux, or Unix ? This usually comes down to a couple of "proprietary" requirements you may have when searching for a web hosting provider. If you need to use ASP or ASP.NET, then these scripting languages are only available on Windows. If you have never designed a web page before then most likely either Windows or Linux will work fine for your needs. ASP, ASP.NET (with the newer version of ASP.NET 2.0), and Ajax are all designed to run on Windows with IIS. Windows can run PHP very easily as well.

With Windows Web Hosting from 3Essentials, you have many different options in getting your HTML pages that you design uploaded to your web hosting account. You can use File Transfer Protocal (FTP), there are many Free FTP programs available and some that you can buy at very reasonable prices. If you use FrontPage or Macromedia DreamWeaver you can upload your pages directly from the application.

Sending and receiving email is done easily on a Windows hosting account. Once your mailbox has been created you can use a WebMail interface to send and receive email from a web browser or you can use Outlook and Outloox Express email clients.

Self Management of your website with 3Essentials hosting is made very easy with our Implementation of the Award Winning Control Panel software by Sw-Soft called Plesk. Plesk is a web based interface to your Windows web hosting account that allows you to create e-mail addresses and mailboxes, view your web site traffic statistics, set permissions on your HTML, ASP, and ASP.NET pages... and more.

This article is the sole property of 3Essentials, Inc.

When you purchase a domain name, say 3essentials.com, you purchase it from a registrar (Network Solutions for example). The registrar registers the domain name for all of the DNS Servers on the planet to query. There are several DNS Servers that contain records about the domain (3essentials.com) and what DNS Servers have the master record for that domain, these are called root DNS Servers. When another DNS Server (say your ISP's) needs to know where to go to find the master record they query(go ask) the root DNS Servers.

So let's say a visitor wishes to view your website and say they type www.3essentials.com (or better yet, your domain name!) into their web browser and click go. The visitors computer that is connected to the internet contacts it's ISP's DNS Server looking for www.3essentials.com. If the ISP's DNS Server already has a record of the IP (66.179.153.10) for the www.3essentials.com web server it gives the visitors computer that IP Address, and then the computer connects to the IP and the browser passes www.3essentials.com to the web server for the page to be displayed.

If the ISP's DNS Server doesn't have the IP for www.3essentials.com, then it contacts the root DNS servers on the internet asking them what is the IP Address of the DNS Server that has the IP for www.3essentials.com. That's where our DNS Servers come into play. 3Essentials DNS Servers contain the master record for www.3essentials.com. Any DNS Server on the planet that doesn't have the IP will ask the root dns servers who does, the root dns servers will say go ask NS1.3ESSENTIALS.COM or NS2.3ESSENTIALS.COM for the IP. So the ISP's DNS Server will go ask one of our DNS Servers for the IP and then pass that back to the requesting vistors computer.

When you purchase your new domain, you need to delegate ( or assign ) it to our DNS Servers so that every DNS Server on the planet knows where to go to get the IP for your domain.

When you transfer your domain to us, it can be a lengthy process (up to 72 hours) for the DNS records to replicate. First you need to create a transfer request. You do this by creating a regsitrar account with us, then you sign into that account and select the transfer option. A request is sent to the email address that is listed for the domain when it was created. You must click the link or follow the instructions that is sent to that email address. For security reasons we cannot confirm the transfer for you, because we do not have access to that email address. The transfer moves the registration for the domain from your current registrar (Say Network Solutions) to another regisrar, say 3Essentials.com.

This article is the sole property of 3Essentials, Inc.

What you're experiencing is called email spoofing. And unfortunately, it's all too common. Virus writers and other Internet bad guys will "spoof" the sender/return to address of an email in order to hide the real point of origination, or worse, mislead the recipient into thinking it's from someone it's not... phishing scams use this tactic, for instance sending emails from something like acctmgmt@citibank.com.  Unfortunately, this is completely possible due to innate flaws within the design of Internet based email itself.  It's because each potential "mail handler" on the Internet doesn't validate the sender address before it forwards the mail along.

Think of it this way... the same flaw exists in U.S. mail... I could go to any U.S. Postal Service blue mailbox, and drop a letter in it that is addressed to your neighbor, for instance, but I could put your name and home address as the sender... The Postal Service will deliver it, and your neighbor will think it's from you (although there will be some telltale signs like the postmark... but nothing that will point directly to me). The US postal service does not include a mechanism for validating the sender is who they say they are. And right now, Internet email does not either. There are various efforts under way to address this, but for now, it's not there yet.

So, where is the mail coming form?  Basically, there's a couple possibilities:

1) The mail is actually coming from your PC (or from a PC from one of your other mail users on your domain).
This is possible if your PC is infected with a virus/spyware which is sending mail from your system.  For anyone that has an email address on your domain, their system should be thoroughly scanned for spyware and viruses, in an effort to eliminate these. 

2) Your website.  It's possible someone has hacked your website and is using it's access to your host's mail server(s) by using mail credentials you have embedded in your website code (especially if you have mail functions on your site).  You should perform a complete security review on your website... remove any code that sends mail if not absolutely mission critical... and if it is critical and you need to keep it, then investigate making changes to it:
- first, change the password for any email account it uses to send mail.
- look to see if you can lock down the mail function any better.
- add code to log the mail sent via these functions, so you can review it to see if it's been exploited.

3) A spammer's own SMTP mail server, directly connected to the internet (or his ISP's SMTP system isn't locked down properly... this is common in other parts of the world, Asia, Russia, etc... they are spammer's paradises).  In this scenario, they can send mail specifying any "sender" they want to... and as previously noted, SMTP allows this, because there's no built-in way to validate the sender is who they say they are. 

Indeed, it's not a pretty situation...  and it's all due to this innate flaw in internet email.  There are some standards to address this (like SPF, sender policy framework) which help by providing a mechanism to say only servers A, B, and C are allowed to send mail for mail domain). But these only work if both the sender and reciever's ISPs use it, currently they are not widely adopted.

Your best bet is to track down the source...

As noted, if it's a virus/spyware on your system (or the system of any of your mail users) or an exploit on your website, you need to find it and remove it.  If it's someone spamming from their own systems using your domain name, you need to track down a copy of one of those mails, and review the header to find the IP(s) used in transmitting the message (although headers can be forged... ugh!) and then contact the ISP's that own those IPs, and lodge an abuse complaint (and then hope they action it).   Tracking these types of issues down is beyond the scope of services for most hosting providers, including us.  Other than providing this information about the nature of the problem, the scope of our services does not include finding, identifying, or otherwise addressing the source of spoofing issues.

You can HELP protect against this by enabling an SPF record for your domain.  SPF puts a special DNS record in your DNS info that says "mail for my domain should only come from these servers: (list of servers)... this can HELP, but unfortunately, not every ISP checks for SPF records on inbound mail, it's just not widely adopted yet, even though it would virtually stop spoofing overnight.  If you want to create an SPF record for your domain, you can do so through the DNS icon for your domain in your control panel... if you're not familiar with how to do this, no problem, just submit a support request asking for assistance in setting up an SPF record for your domain, and we'll help you define the correct record, and get it implemented in your DNS settings in your control panel.

Of course, if you're not 100% committed to your domain name (I'm sure Coca-Cola's pretty commited to coke.com, but you might not have such an attachment to your domain name)... then it might be way easier for you (though slightly more drastic) to simply change to another domain name... domain registration is very affordable, and you may not wish to expend the same resources to protect your domain name that Coca-Cola expends protecting theirs. 

In the beginning of "the web", when you needed a website, you set up a server with webserver software, and built your site on it.  But as more folks started adding small websites with small amounts of traffic, it quickly became clear that you didn't need a whole server just for one website, that in fact, 1 physical server could be able to host a large number of small websites... those websites could "share that server's resources".

Today, the two main web server solutions, Apache for Linux, and IIS for Windows, both provide the ability to host multiple websites on a single server, all sharing a single IP address and other server resources (CPU, memory, etc).  Each provides an implementation that isolates each site's code and user priveledges to ensure approriate security, although each takes a slightly different approach. 

So, in short, shared hosting means you have many websites on a single server.  

One separate note on SSL certificates... you can host your own unique SSL certificate on your website on a "shared hosting" solution.  However, you need to not use the "shared IP address" that all sites on a shared server use by default.  Instead, you'd need your site configured to use it's own unique IP (this is due to the nature of how the server handles HTTPS/SSL communication).  Check our website hosting plan pages for prices for adding a unique/static IP to your hosting plan as well as SSL certificates, and then submit a ticket if you'd like to make this change.

3Essentials also offers dedicated server plans.  A dedicated server is a server dedicated to a single customer... that customer may chose to host 1 big site on the server (that needs lots of CPU and memory), or may host many websites on it, depending on their needs.  

In general, the Windows IIS Web Server handles all basic, static HTML processing... i.e., if a visitor goes to your site and gets index.html, the core IIS webserver process will handle retrieving this html file, and sending the contents to the visitor's browser.  But for "dynamic code", script based files like ASP and ASP.net, the webserver will hand this request over to an application pool.  An application pool is a seperate process which can host this type of dynamic content.  To keep each customer's code separated, shared hosting providers will use a separate application pool for each website.  Each application pool will run under a user ID unique to that website/customer. 

The image above depicts this scenario... requests coming in for domain1.com are handed off to an application pool dedicated to just domain1.com.  This offers great advantages for stability and security, explained here by example:

• if domain1.com has written bad ASP code, and it keeps hanging up the process, it won't affect domain2.com... because domain2.com's code is executing in it's own process space.
• each website only has permissions granted only for their own unique user... so processes running under domain1.com's application pool cannot access domain2.com's files.
• if domain3.com is doing something malicious, it's doing it under domain3.com's unique user id, allowing us to quickly identify who is responsible and shut it down.

3Essentials utilizes Plesk Control Panel to manage our Windows hosting servers, and it will use one or two of these unique IDs depending on the version... here's clarification:

• Plesk versions 7.0.3 and below (web4, web6, web8) will use a single unique user id for all execution within your site, and the user id will be IUSR_something
• Plesk versions 7.5.6 and above (web10, web12, web14, web16) will use two unique user id's for execution within your site:
  • IUSR_something will be used for static content (html files) and PHP, PHP-CGI 
  • IWPD_something (assigned to the application pool) will be used for ASP and ASP.net

Related articles.

• What identity is my ASP.NET application code running under?

When you need to go to www.somedomain.com, your computer needs to actually "resolve" that name to an IP address... i.e., what is the IP address of the server that is hosting www.somedomain.com.    To resolve that IP address, your system will FIRST look in your HOSTS file, which is simply a text file with a list of hostnames mapped to IP addresses.  Typically, it's empty, as it's just there for specific purposes.  When www.somedomain.com isn't found there, then your computer will check with your ISP's DNS servers (ISP = Internet Service Provider).

As you can see, because your computer checks in this order, hosts file first, then DNS servers, if you put an entry in your hosts file, you can effectively override what is in DNS.  A neat trick that's helpful sometimes in troubleshooting, or publishing a site with FrontPage before DNS is actually pointing to the right IP address.

To edit your hosts file, follow these steps:

1. Open Windows Explorer on your system
2. Navigate to c:\windows\system32\drivers\etc
3. Find the file named "hosts" (it has no file extension), and double click it.
4. Windows will ask you if you want to open it and what to open it with, choose to open it with Notepad (notepad.exe).
5. Once the file is open, you can add the necessary lines.  If our support team is asking you to modify your hosts file, they will provide you the exact line to enter.  The line will be in the format of:
   • 1.1.1.1 somedomain.com
   • 1.1.1.1 somedomain.com ftp.somedomain.com www.somedomain.com
   • where "1.1.1.1" equals the ip address you need to point to and "somedomain.com" is the hostname you need to map/resolve the IP to.
6. Important notes when editing a hosts file:
   • make a backup copy first, so you can quickly restore if you need to.
   • the IP address and the first hostname should be seperated by at least one space... it can be more than one, but should be at least one.
   • you can list multiple hostnames on the same line for a single IP address.
   • make sure there's at least one blank line at the end of the hosts file.
   • remember to either remove the entry or restore your orignal hosts file once you're done with whatever your testing.

   • your browser will cache DNS information and needs to be cleared by closing your browser, so the process would really go like this:

     • close all instances of your browser
     • edit your hosts file to point the domain to the new/test server
     • open your browser, go to your domain (you should be accesssing the site at the IP in your hosts file entry)
     • finish testing, close all isntances of your browser 
     • edit your hosts file to remove the entry (or comment it out). 
     • open your browser, go to your domain (you should be accessing the site at the original IP active in DNS)
     • You can switch back and forth like this as much as you need.

A website visitor types in www.mydomain.com/somefile.html, the webserver is handed the request, and it uses the www.mydomain.com portion to determine which specific "site" it should access (remember, a given webserver will have many many websites, this portion of the URL not only locates the correct physical server, but then also which website on that server).  Once it locates the www.mydomain.com website, it looks for a file called "somefile.html" and sends that back to the website vistor to display in their browser.

Now, if a website vistor types in just www.mydomain.com , then which file is the webserver supposed to send to the visitor?  That's where the concept of a default document for a directory comes in.  If "default document" is enabled for a directory (which it is for all sites and directories by default on our servers), then the webserver will look for a "default" document... a page to serve up to the visitor when no specific page was requested.  To do this, it maintains a list of possible default document names, and searches the directory for these in order, and serves the first one it finds to the visitor.  And example is the best way to understand this:

• Let's say on my website, mydomain.com, I have default documents enabled, and I have the following default documents listed as possible documents in the following search order:
  • index.html
  • index.htm
  • default.html
  • default.htm
• Now, let's say my website contains BOTH a index.html file AND a default.html file...
• When a visitor visits my site using www.mydomain.com, the webserver will serve the index.html file... because it looks for any of those files (in the order they are listed) and it serves the first one it finds.
• Now if I simply deleted the index.html from my site - i.e., I deleted the actual file, and made no changes to my default document search order:
  • index.html
  • index.htm
  • default.html
  • default.htm
• And I then refresh my browser which was pointed at www.mydomain.com, suddently, the default.html would be loaded... because that's the first file the webserver finds when searching in order for default documents.
• Another important example.... Let's say my website has the following list of default documents:
  • index.html
  • index.htm
  • default.html
  • default.htm
  • default.asp
• And let's say I have these actual files on my website:
  • index.asp
  • contact.asp
  • services.asp
  • products.asp
• When someone visits www.mydomain.com, which file will they be served? 
  • ANSWER: nothing, they will get a 404: File Not Found error. 
  • WHY? Because the webserver looked in the directory for each of the default documents, and none of those were present... I designed my site to use "index.asp" as the default/home page, but I didn't update the default document list to search for index.asp.  So, unless someone visits www.mydomain.com/index.asp, they won't ever get my index.asp page (until I change the document list).

To find these settings in the control panel:

• log into the control panel
• click on your domain name
• then click on WebDirectories, "webdirectories" is basically Plesk's access to IIS's "virtual directories" settings
• when you click on the webdirectories icon, you are in the "root", note at the top, it says "Web Directory /".  The "/"symbol signifies the "root" of the website.
• click the "preferences" icon (the preferences of the "root" directory)
• there you will find options for changing the default documents, and the order in which it looks for them

1. let's say my domain name is mydomain.com, and I want to create make a place called mydomain.com/secured that is only accessible via login, thus protected from the general public.  In general, the steps we will follow will be:
   • first create the folder called "secured"
   • apply the "URL protection" to it (the layer that asks for the login)
   • create a login username/password combo to access it
   • Detailed instructions follow.  
2. Log into the control panel
3. click on your domain, in our example, we'd click on mydomain.com
4. click on the File Manager icon
   • In File Manager, click on httpdocs (remember, httpdocs is the "root" of your website... i.e., http://www.mydomain.com points to this httpdocs folder).
   • Once in the httpdocs folder, click on Add New Directory, add the name of the directory you want, in our example, I'd enter "secured", and click OK.
   • Once that folder is created, navigate back out of the File Manager tool, back to the top level.  For most versions of Plesk, you can click on the domain name at the topof the control panel as a shortcut to do this.
5. Now you're done with creating the folder in File Manager, let's apply the protection.... remember, you should be back at the top level for the domain in the control panel, back where the FileManager Icon was.  Find and click on the Protected URLs icon.
   • In Protected URLs, click on Add New Protection
   • In the URL field, leave the "/"and enter the name of the folder you just created... in our example, this would be how the field would look: /secured
   • For the Realm Access Text field, whatever value you enter here will be displayed to the user in the login prompt, preceeded by "Welcome to ".  So if you enter "my secured area", the login prompt will read "Welcome to my secured area".  If you enter "welcome to my secured area", the login prompt will read "Welcome to welcome to my secured area", so just remember it appends the "Welcome to"
   • Click OK
   • You should now be back at the Protected URLs menu, and the Protected URL you just added will be listed.  Click on the Protected URL you just added; this will takeyou to the Protected URL Users page for this Protected URL.  Use the Add New User icon to create a username and password combination to access this Protected URL. Some notes about Protected URL Users:
     • Note, you can create multiple Protected URLs, each will have it's own unique list of users. 
     • You can create 1 user for a protected URL, and give that to however many people you wish.  Or you can create a unique user for each person you want to access a given Protected URL.
6. Setup of the Protected URL is complete, to test:
   • first we'd actually need to put a file in the secured folder, so follow your normal process for FTPing a file into the httpdocs/secured folder.
   • To test the URL... for our example, we'd point our browser to http://www.mydomain.com/secured and should be prompted with "Welcome to my secured area"
   • Please note, there is a known issue with some versions of the Plesk Control Panel that cause the directory to NOT prompt for user/pw immediately after being set up.  This can be fixed by our support team after you've set it up.  Please see KB Article #9.

For most businesses, having the registrnt information publicly available is perfectly acceptable, like the pepsi example here... it simply provides corporate contact information.  But for small, one owner businesses, where the business address is also the owner's personal residence, or for personal websites, it may not be wise to allow this information to be publicly available, given the current concerns with identity theft.  Remember that by default, it is publicly available to anyone with access to the Internet.  Remember that all of this DNS stuff came about before less-than-scrupulous folks started using the Internet to retrieve personal information for the purposes of identity theft and fraud. 

Recognizing this as a concern, domain registration companies have started offering an optional service which will protect your private information.  3Essentials in conjunction with our domain registration partner also offer this as an option, which is called "private registration". 

Private registration will list the registrant as "Domains By Proxy", and your personal information will be unavailable publicly.  You will still have full control over the domain registration and it's options.  Private registration is available as an add-on to domain registration, and can be added when you first register a domain, or even after, as noted here:

• You haven't registered your domain name yet?
  • when you register your domain, look for the "add-on" option of "private registration" and add it to each domain you're registering that you want to protect in this manner.
• You have already registered your domain name with 3Essentials
  • Log into our domain registration management interface at http://3essentials.com/domains/manage.asp
  • click on MANAGE DOMAINS
  • you'll see a list of your domains, click the UPGRADE DOMAIN link to the right.
  • you'll find "private registration" is an available option there.
• You have already registered your domain name with a different registrar
  • check with your current registrar to see if they have something similar to "private registration" available.  If not, you can TRANSFER the domain name to us, and then use our private registration service.

Answer:
Many people think that there are 1000 bytes in a kilobyte. After all, "kilo" means 1000. In most cases, this approximation is fine for determining how much space a file takes up or how much disk space you have.

But there are really 1024 bytes in a kilobyte. The reason for this is because computers are based on the binary system. That means hard drives and memory are measured in powers of 2. For example:
2⁰ = 1
2¹ = 2
2² = 4
2³ = 8
2⁴ = 16
2⁵ = 32
2⁶ = 64
2⁷ = 128
2⁸ = 256
2⁹ = 512
2¹⁰ = 1024
Notice how 2¹⁰ is 1024. Therefore, 2¹⁰, or 1024 bytes compose one kilobyte. Furthermore, 1024 kilobytes compose one megabyte, and 1024 megabytes compose one gigabyte. For most practical purposes, you can estimate 1024 to 1000.