Microsoft actually explains something well

Microsoft normally explains things in terms of "you're an idiot so we can't really explain this in a way that will make sense" but this one struck me differently. I came upon it by accident. Here goes.

What is a homograph attack?
A homograph is a word with the same spelling as another word but with a different meaning. In computers, a homograph attack is a Web address that looks like a familiar Web address but is actually altered. This occurs when the domain name was created by using alphabet characters from different languages, not just English. For example, the following Web address looks legitimate, but what you can't see is that the "i" is a Cyrillic character from the Russian alphabet.

www.microsoft.com

Phishers spoof the domain names of banks and other companies in order to deceive consumers into thinking that they are visiting a familiar Web site. Special software is needed to detect these kinds of spoofed domain names in Web addresses. See the next section to learn more about how The 2007 Office release helps protect you from links that attempt to lead you to suspicious Web sites.

.htaccess fix for trailing slash(es) on server-parsed HTML files

I now have a complete fix for not only trailing slash(es), but also characters following the slash, and a redirect to the proper/permissible path.

RewriteEngine on
RewriteCond %{REQUEST_URI} ^(.*\.shtml?)/.*
$RewriteRule ^.*$ http://%{HTTP_HOST}%1 [R=301,L]

You also deny these altogether by changing [R=301,L] to [F,L]. This will generate a 403 FORBIDDEN response.

.htaccess fix for trailing slash(es) on server-parsed HTML files

I just came across something slimilar. Here's a link:
http://www.webmasterworld.com/apache/3412891.htm

Spam this!

I finally had a great idea in my war against spam. Even if you have a personal and a not-so-personal disposable account, it is an imperfect arrangement. The idea is that at some point your not-so-personal account will reach an intolerable limit of spam and you can abandon it and move on to some other then-in-vogue address. But between inception and abandonment, what about the annoyance of the steadily building spam? And for that matter, wouldn't it be nice to know WHO didn't protect your email address and WHO you can blame for this dastardly misfeasance? And wouldn't it be nice to not have to keep track of multiple accounts?

Having your own domain name (i.e. JaneDoe.com) is the first step. Next, find a web host or an email service (Google and Yahoo, for example) that will let you use your personal domain with their email service. Create whatever email address you like (say, jane@janedoe.com) and only provide it to your most trustworthy correspondents.

Now for the genius part! Establish a sub-domain that will be easy to remember (i.e. Jane.JaneDoe.com), but don't configure any email addresses for it. Instead, set your options so that all messages sent to this sub-domain go to your private email address. So any email sent to blahblah@jane.janedoe.com will be delivered to jane@janedoe.com. Don't dismiss me just yet. This is the good part! Whenever you buy or sign up for something online, create a new email address according to the merchant. So if you buy something from amazon.com, enter your email address as amazon@jane.janedoe.com. It does not matter that this is not your email address as all messages sent to the sub-domain are delivered to your private email address. Now if you ever start getting spam sent to amazon@jane.janedoe.com, then you know that Amazon is responsible for not protecting your information. As for stopping it, now you can create a block/filter that deletes any future message sent to amazon@jane.janedoe.com and you will NEVER get another spam from anyone who obtains that address. But this caveat: I use Amazon as a convenient example. I have shopped with Amazon for years and have never had a single problem. It is a great company in every respect, so in their case, you could trust them with your private address.

As a final note....if any of your trusted correspondents do not use anti-virus software, a nasty virus could harvest the email addresses from every email sent to or from that person. So this might not work until the next American centennial, but it should last you a decade.

.htaccess fix for trailing slash(es) on server-parsed HTML files

Ok, this is a strange post, but since Blogger is immediately indexed in Google search, I thought I'd put this out there for any other geek-zoids out there like myself. I spent a great part of yesterday googling a solution to this problem. It is an obscure condition to say the least, but perhaps there is one other person among the world's six billion people who needs this same solution.

The problem: Trailing slashes on a server-parsed html file breaks every relatively linked resource. Images, style sheets, etc. won't display. Apache 2.0 has an httpd mechanism to ignore the trailing slash, but if it is not configured for this, or if you're using Apache 1.3, the trailing slash(es) will present a problem. So I came up with this snippit to put in your .htaccess file. If you don't know what a .htaccess file is, google it. Put this code in the root directory as follows:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} (.*)/$
RewriteRule ^(.*)$ http://%{http_host/} [R=301,L]

Requested URLs with trailing slashes will instead serve up the default page. Of course, this only removes the trailing slash (or multiple slashes), which is the most common issue encountered thanks to the myriad search engines and spammers who abuse your cgi/pl forms. This fix does not prevent a trailing slash with extra characters following (ex: www.yourhost.tld/index.html/a). If you need this, add the appropriate RegEx to to fix your particular situation. Your snippit would then look like this:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} (.*)/$ [OR]
RewriteCond %{REQUEST_URI} (.*)/PutYourRegExHere$
RewriteRule ^(.*)$ http://%{http_host/} [R=301,L]

Another--although undependable--way to handle this is to add a conditional SSI (server-side include) meta refresh statement. This is problematic because it will be ignored by robots, crawlers, and the like, not to mention browsers that either ignore or allow the user to disable meta refresh. I tried to include it anyway, but then Blogger wouldn't allow it because it tried to interpret it as html code. But it is made to be irrelevant by the solution above. And if you can use SSI in the first place, you can almost certainly use .htaccess.

If you need some guidance, try these links
Comprehensive guide to .htaccess
Lissa Explains it All -- .htaccess Tutorial
Apache Core Features
Regular Expression Tutorial - Learn How to Use and Get The Most out of Regular Expressions