Best Practice

Recommended Best Practice.

This is primarily a guide to assist clients in the smooth running of their website(s). As such, it does NOT form part of the Terms of Service and AUP but will hopefully provide an insight and recommendations to enable clients to make the best of the MadeRite Hosting Service. The information herein has been gained through experience and research and will hopefully assist you to reduce the number of problems faced when trying to run a successful website or program. This guide is mainly aimed at Paid To Read Program (PTR) or Paid To Click (PTC) owners, but all clients may find some benefit from this information. If anyone has any information or advice that they would like to share in this document, then please feel free to contact me. I will accredit any additional information to the relevant person.

Email

One of the most important areas of most online businesses today, it can also be the most troublesome. Here are a few points to be aware of:

• Yahoo are constantly deferring emails. This is a global problem and is being experienced by all Hosting Service Providers. Each time a Yahoo based email attempts to send, it tries to connect to one of several different MX servers in turn. If it fails on the first, it moves to the next until it either connects or gets refused or deferred. Each attempt times-out after about 5 minutes if nothing happens, so multiply that by each MX server - it can take 20-25 minutes or more for one email and after all that, it still may not have been delivered. It just keeps on retrying until it is deleted from the queue or times-out overall, which is 4-8 DAYS. These mails do not bounce, if they did it would be better. Yahoo just defers them, therefore shifting their load and bad email management onto the sending mail server. There are a limited number of connections that any server can make at any one time, so whilst the Yahoo mails are merrily hogging all the resources, NO OTHER MAIL IS BEING SENT. Yahoo will not assist, all replies are automated and explain what should be done to ensure that email is delivered. Even when all of their criteria has been met, emails still remain undelivered, only very few actually get through. The idea behind this is to reduce Spam, but it appears that Spam always succeeds where legitimate mail does not. Other email providers also use the Yahoo engine, to name but a few: BTInternet, BTOpenworld, Ymail, Rocketmail, Rogers etc. Clients should set users to onsite inbox and encourage the user to change to a non-Yahoo based address. Also prevent users from signing up with Yahoo email address, block these in your Admin panel. At the end of the day 9 out of every 10 don't get their signup confirmation email anyway. Please see the following links for Yahoo's view on the problems Message Temporarily Deferred and Sender Etiquette. All clients that send mass emails should particularly note the content of the Sender Etiquette page, but the information on both pages should be read by all to better understand. This does not only apply to Yahoo, but most other Email Providers also.
• You should always have an account setup in your cPanel for the address that emails are sent from. Some scripts send through e.g. rewards@domain.com or noreply@domain.com even if the account does not physically exist. This account should be monitored and any bounces actioned.
• Bounced emails should be taken very seriously. If a Member of your site has an email address that is constantly bouncing emails from the server, it could be caused by several things:

1. The email address is incorrect or has been mis-spelt by the Member.
2. It is a false address.
3. The Members' mailbox is full.
4. The email provider is rejecting emails from maderitehosting.com and/or our IPs.

• There are many other reasons, but these are the most common. Action is required to reduce the number of bounces as the consequences could lead to our IPs and server being blacklisted and that means NO EMAIL would be accepted from our server, by anyone.
• Ensure that all Members of your site have a proper email address in the User Info and not just blank. Blank fields still generate emails and the script attempts to send them. They are easy to spot, they usually take the form e.g. test@1200381931.com or jimbo883@1203731087.com where numeric section between the @ and .com is randomly generated by the script. The Emails will also be treated as bounces and they cause unnecessary server load and resources being used whilst attempting to send to an address that clearly does not exist. Check your return address mailboxes regularly and take action to prevent this from occurring. We will occasionally forward bounces to clients that are sent to the root of the server because clients to not have or monitor their return address.
• For CashCrusader scripts (may also apply to other scripts), in Admin, under 'Site Email Settings' you should set 'Throttle back the send speed of mass mails to help prevent being blacklisted and reduce load on your server' to YES and 'Force Return-Path eMail header (do not use unless you're not receiving bounced email notices)' to YES. Whilst you are there, it would be useful to reduce 'Number of days to keep email IDs in internal inboxes:' to only a few days - this will reduce the overall size of your database.
• Avoid sending 'Bulk Emails (i.e. 7 or 30 Day Ads). This type of email is processed differently to Click-thru' emails. Bulk emails are sent to all Members in one email whereas Click-thru are sent individually to each Member. Many email providers are now restricting the use of Bulk Emails (e.g. Hotmail, which includes MSN, live.com and WebTV). They will only accept 2-3 addresses per connection, so if you have an email to many Members it can take several hours for the mail to be completely delivered.
• For Aurora (PTC) Scripted sites, in Settings>Site Settings>Email Settings set your 'From Name' to the site name and 'From Address' to the real account set up in your cPanel. Use SMTP and set the correct details in the SMTP settings below. Use the full sending email address and login password. Usually the pre-filled 'localhost' is all you will need, then set the mail.domain.com to your actual domain mail server as shown in your cPanel. This will ensure that your emails are sent from your own domain and are more likely to be accepted.
• DO NOT use non-domain/non-server email addresses to send your emails. Some Program Owners feel the need to add the sending address of their paid/bulk emails as a Gmail or similar address. The script will show this address in the 'from' field, but the actual email headers seen by ISPs and other mailservers will show the sending server as servername.maderitehosting.com or similar with our server IPs - as our servers (or any other for that matter) are not registered, authorized senders for Gmail, the DomainKeys and SPF Records will not match and the emails will be seen as spoof, fraulent and/or spam. This practice is against most protocols and also against our own AUP.
• Keep your onsite (cPanel) mailboxes clear. If you use an external email client (Outlook, Thunderbird etc.) set them to remove emails from server once downloaded. If you use the onsite mailboxes, send mail you don't want to keep to the 'trash' folder and then empty it.
• Do NOT change your 'Default Address' from :Fail No Such User Here. This helps to prevent mails being sent to email addresses on your domain that don't exist, they are rejected when attempting to connect to the server. If you require cron outputs, please ensure that you set a legitimate email address in the box at the top of the 'Cron Jobs' page in cPanel.
• Configure the SpamAssassin in your cPanel to your requirements. Block known Spam senders and Whitelist addresses that you wish to receive.
• On the 'Email Authentication' page in cPanel, ensure 'DomainKeys' and 'SPF' status remains 'Enabled'. This helps with delivery of emails and authenticates that to other servers that the email actually comes from your domain and is not cloned or faked.
• REMEMBER THAT YOU ARE NOT THE ONLY CLIENT HOSTED WITH MADERITE HOSTING - Constantly bouncing emails and bad email management affects the WHOLE SERVER and all of its IPs. If the mailer is overloaded with YOUR deferred or frozen emails, it prevents the sending of ALL emails in the queue.

 

Backups and Quota (Disk Space)

Daily, Weekly and Monthly backups are made by the server automatically. This does not mean that you don't have to make and keep them yourself. It is in your and your members' interest to keep regular backups of your site and/or databases, should anything untoward happen. Server backups contain the entire Database and 'Home' folders on the server, as well as system files. Each account has its own sub-folder in the main 'Home' directory - this is where all of your pages and other files are stored. Whilst there is no limit to what you can store on your Quota of disk space (within the confines of your package), it is wise not to store any unnecessary files, i.e. don't use it as a store room for the files you don't want to save on your own PC or removable storage. The more that you have stored on the server, the longer it takes for the backup to run on each account. Whilst the backups are running (every day) server load is increased. Good housekeeping in your account helps the server run as smoothly as possible and keep resources free for other important tasks. Again, your domain is not the only one hosted with MadeRite, server resources are used by all and if any account is using more than its fair share, it affects EVERYONE on the server.

 

Bandwidth

Remember that Bandwidth is an essential ingredient of your Hosting Package, excess use along with Quota (Disk Space) can lead to suspension of your account. Whilst we all want to see plenty of 'hits' to our websites, we also want the viewer to be able to access pages quickly, especially if they are on a slow connection or even dial-up. One of the biggest causes of slow access AND high bandwidth usage is images. That includes images in web-pages AND linked in emails sent. For Paid-To-Read emails, there is very little point in sending them with images. They are viewed by the Member for only a few seconds whilst they find the clickable link and then it gets trashed. All images in every email, to every person you send it to, add to your bandwidth usage. Images should also always be optimised. Don't just add an image to your website and then assume it's ok. Photos in particular can be very large files and can take a long time to load into your visitors' browser. Always keep the dimensions low, but also optimise the image to ensure that the actual filesize is as small as possible. Reducing the quality and/or resolution helps greatly. It is not essential to have high resolution or definition images on the usual web-pages. If you need someone to view in a higher resolution, use a thumbnail and link to the main image. Good graphics are essential for a good website, but they need not use up valuable resources. Properly optimised graphics don't have to look bad. Avoid .png or .bmp images, convert to .gif or .jpg as they are smaller by default - a 2500kb bmp for example might only be 19kb gif or jpg. Keep animated images to a minimum, but even they can be optimised to an extent. Remember, whilst the server itself is on un-metered bandwidth, there is a limit to how much data can be transmitted at any one time. If you have a busy site with high bandwidth usage, your site IS affecting other sites hosted on the same server.

 

Databases

Ensure that your databases are kept optimised at all times. Clean out expired emails and clicks daily, also purge cancelled Members (except those cancelled for cheating etc.). Ensure that emails that have not expired are resent promptly, so that they can reach the allocated clicks and be deleted. If you use Ad Manager, the daily emails are actually recreated each time they are run, so a 100 click email, that is sent every day for 30 days, will generate the same email 30 times, unless it expires before that. CC owners can use the free CCScrubber plug-in to help clear the excess emails and the table overheads. You can set the search to anything over, say 3 days, then delete everything older. It is amazing how much can be safely removed. Set the 'Number of days to keep email IDs in internal inboxes:' to a number as small as possible, 3 days would be the maximum I would recommend, but it is a personal preference. Overly large databases are more prone to crashes or failure and of course generate larger backups with more disk usage.

 

Server Problems

Server problems do occur and are dealt with as quickly as possible. Please do not panic if you can see your site one minute but not the next. There are many causes of this and most are temporary.

• Connection issues with your ISP
• General connection issues with the Internet
• The Server may have too many connections
• The Server may be rebooting
• The Server is offline

These are just a few examples. The first 3 are beyond any hosting company's control and are just an unfortunate factor.
Occasionally the Server needs to be rebooted. This may be a requirement when any updates or changes are made and normally means that the server is only offline for a few minutes. It would take longer to warn everyone of a reboot than to actually do it, so there is little point. In any case a reboot normally only takes about a minute. On occasion, the datacentre may take the server offline (and all others in the same part of its section) for routine or urgent maintenance. Other reasons may be a system fault or error. If the server does go offline, then 99% of the time we are already aware of it, so there is no need to panic and send Instant Messages or urgent contacts. We are working on the server or related sites most of the time and would normally be the first to know if there is a problem. Contacting us just further delays investigation or fixes. If there is a major problem, we will send information to all affected clients. If there are any planned outages for maintenance, we will inform all clients in advance. We are not saying that you should not contact us if you have a problem, we are only too glad to help, but if you notice that all sites are offline or have been affected, then you know that we are probably already fixing it. Your patience and understanding would be greatly appreciated.

©Tony Bishop
TGB Enterprise

 

Reproduced with permission from the author.