Michael Brandonisio

Hello,

I’m sure the internet has changed quite a bit since you first unveiled your web site to the world. The technologies used to build web sites and internet presentations have also changed too. You may be thinking that the time is right to redesign your web site. A new look/ feel and fresh content will go far to better reflect your business services today. Make sure you have someone who understands search engine optimization involved with your project. This is very important for a web site redesign.

In the past it was possible to simply write code to display your pages properly in the few browsers available. Today if your web site enjoys any traffic that comes from the search engines, you want to keep it. This means that your REDESIGNED web site cannot have broken links that come from the search engines or dump all of your old site links to the home page. Doing so will impact your search engine ranking. This will cause your rank to drop. For some business this could have a serious financial impact.

You need to redirect all of your old pages to the new pages that have similar content. Often a web site is transitioned from a static HTML web site to a dynamically scripted web site like those coded with ASP, PHP, .net, Cold Fusion, Java to name a few server side scripting languages. Your old web site may have had links that looked like this:

http://www.example.com/folder/products.htm

or something similar. Your new site may simply have restructured how the pages are stored by changing the folder names or your web site is now dynamic. Either way you want your old web page links to be redirected to the new web page links. If you are running apache server you can use an htaccess file in the root of your public folder to preform the redirect of OLD to NEW. This is just one way to make use of htaccess files. Feel free to use your favorite search engine to find other htaccess tutorials for password protected folders or event URL rewriting.

How to use htaccess files with apache server for URL redirect

Create a plain text file named: .htaccess

in the root of your public folder. In this file you will use the following structure to create a redirect that tells the search engines that a permanent change to the old link has been made, meaning the old link is being redirected permanently. The format is action, error code, OLD URL, NEW URL. Each redirect is on its own line like this:

Redirect 301 /your_file_name.html http://www.example.com/index.php?a=12&b=39
Redirect 301 /file_name.htm http://www.example.com/index.php?a=657&b=354&c=234

If your OLD URL happened to have a space, %20, in the file name or folder name put the entire URL in double quotes like this:

Redirect 301 “/folder name/file name.htm” http://www.example.com/content/view/215/27/

This will allow the directive to be performed properly. With out double quote around the URL with a space it can cause an internal error 500 on the server. Often this error is associated with htaccess files the have invalid syntax.

Note:

1. 301 is the error code for a permanent redirect
2. The OLD URL starts with a forward slash
3. The NEW URL is a fully qualified URL
4. The new URL can also be on a different domain too.

That is all there is to it. Save your htaccess file and test it by access an old URL. It should redirect your browser without incident. Using the 301 error tells the search engines to update their index with the new URL.

Sincerely,
Mike

Hello,

I recently upgraded my servers to the cpanel 11 when I received a notice from cpanel that stated, “Unable to automaticlly update the mailer config…”. So I manually performed the upgrade only to discover that email was being handled very differently after the upgrade. No email that was marked as SPAM was was being delivered. Instead it was being dropped. This meant that there would be no way to check for a false positive email marked as SPAM. Normally spammy email has it’s subject rewritten to prefixed with, “[spam]”. This allowed the user to then use a filter in their email client to filter email with “[spam]” in the subject to a folder for later review. This would keep the inbox clean.

I did some research and found that this was a common issue with the new cPanel 11. After many hours of thinking that I may have to downgrade the server to cPanel 10, I found my answer in WHM. When you log into WHM as root there is a section called, “Service Configuration”. In this section you will find, “Exim Configuration Editor”.

In the “Exim Configuration Editor” page in the, “Mail” section just above the the buttons marked, “Visualized ACLs and Save” is an option to use the old old transport, “Use the old transport based spamassassin system instead of the new acl style one. (not recommended, slow)”. When I first saw this and it said it was not recommended I looked for an alternative. I could not find one. I need my email spammy or not to be delivered to each users inbox for their review.

Check this option, “Use the old transport based spamassassin system instead of the new acl style one. (not recommended, slow)” and click the save button. If you were previously using subject rewrites SPAM Assassin will again rewrite your subjects. You can also make use tof the X-Spam-Flag header for filtering this is a YES or NO value.

At least by doing this you can continue to make use of the NEW cPanel 11 features while monitoring the cPanel forums to see of the Exim ACL’s have been fixed to allow subject rewrites and delivery of email marked as SPAM.

Sincerely,
Mike

Hello,

This is a re-write with a few additions of a solution that I found on 2 BLOG’s and in the cPanel Forum. My sources are: johnhesch.com, yamzy.net and forums.cpanel.net.

I was having some issues with a few clients and their email. A client would call me and say, “A vendor says that they cannot send email to me. What’s going on?”

I’d chime back, “Did they give you any more information? If you can ask them to fax you the bounce message or email it to my comcast account I will look into it.”

Eventually I’d receive the error the message. It would read something like:

Error 451: Deferred sender callout cannot be verified.
or
Error 550: Verify sender callout failed.

If you look in your exim Logs /var/log/exim_mainlog you might find something like:

could not complete sender verify callout

Exim by default, will check the senders email address and send a callback to the sending server to check and see if the users email address actually exists. In this case the senders email server was not verifying the email address actually exists and so the email was being rejected. In some cases the sending server does not wait long enough for the check to complete. Most of the time this is an issue with the sending servers configuration. It is not RFC compliant. It is not always possible to contact the senders server admin to alert them of their server issue. You may want to just make a concession on your end.

In cPanel or more specifically “WHM -> Service Configuration -> Exim Configuration Editor” there are 2 setting that help keep SPAM down “Verify the existence of email senders.” and “Use callouts to verify the existence of email senders.” These Exim directives tell Exim to perform the checks. I tried to turn them off for about 4 months. My server mail queue was loaded with over 3000 emails. The queue ages 7 days then deletes but still something was wrong. Then I got on an RBL list and that was the straw that started the search for a solution. I enabled both “Verify the existence of email senders.” and “Use callouts to verify the existence of email senders.” while I looked for a solution. In 7 days my queue dropped to just 40 emails. Now I still had a clients that needed to communicate with their vendors.

After Googling I found my solution on johnhesch.com. I nearly lost it. When I finally confirmed that what was posted there was worth trying the link was broken. I contacted John via email to ask about it and he sent me back the info I needed. I later found what looks like a copy of John’s posting here yamzy.net.

So it turns out what I needed was a white list. Now Starts the “How To” Create a file that will be the actual white list. In this example it is /etc/exim_whitelist_senders – the addresses need to be listed one entry per line, either the email address or use the wildcard to do an entire domain. The Following supports cPanel 10.

1. SSH into your server and as root or using SUDO or SU run this command:
   touch /etc/exim_whitelist_senders
2. In WHM, got to “WHM -> Service Configuration -> Exim Configuration Editor.”
   In the top most edit box add (if there is anything else in the text box add this bellow it):
   addresslist whitelist_senders = wildlsearch;/etc/exim_whitelist_senders
3. Still in WHM. scroll down to where there are three text boxes together. This is the begin ACL section. In the middle box scroll down until you find:
   #sender verifications are required for all messages that are not sent to lists
   require verify = sender/callout
   accept domains = +local_domains
   endpassIn

   cPanel 11 look for:
   [% ACL_RBL_BLOCK %]
   require verify = sender/callout=60s

4. and change it to:
   #sender verifications are required for all messages that are not sent to lists
   deny
   !verify = sender/callout=30s,defer_ok,maxwait=60s
   !senders = +whitelist_senders
   accept domains = +local_domains
   endpass
5. Save and exit. Now try to send and receive email to make sure everything is still working. If all is ok add the address in question to the white list and see if it works.
6. Put the sender addresses in the file /etc/exim_whitelist_senders, one per line, e.g. someone@domain1.tld
   *@domain2.tld

If you do not want an RFC compliant email server make this change too. When I made this change it broke my setup. Verifying the header can cause valid email to fail this check since some valid email does not come from users but is created by the automated systems, like a server. I WOULD NOT MAKE THIS CHANGE. It took me 5 day to figure out this was the part that broke the above setup.

1. Still in the middle box scroll down to the end and change:
   #!!# ACL that is used after the DATA command
   check_message:
   # Enabling this will make the server non-rfc compliant
   #require verify = header_sender
   accept
2. and change it to:
   #!!# ACL that is used after the DATA command
   check_message:
   deny
   !verify = header_sender
   !senders = +whitelist_senders
   accept

It did not really break it but for some reason beyond me it was not working with this section active. Disabling it made my white list work like a charm.

Sincerely,
Mike