Leopard: A Face Only a Mother Could Love - Part I

Thursday November 15, 2007 23:56 | 0 Comments

• Tags:

The first time that I used Mac OS X Tiger, I was in love. Coming from the Windows XP and Vista world, the interface seemed like such a breath of fresh air. Yes, it does have eye candy elements but it didn’t seem gaudy.

Last night, I finally sat down to install Leopard on my iMac. Honestly, I haven’t had much play time on it so I don’t know all of the ins and outs of the Operating System but after a day of using it my initial impression is, “Wow, it’s just so…ugly.”

Whereas Tiger seemed timeless and classy, Leopard looks cheap and forgettable. Here are some of the problem spots:

The Dock

Although the “glass” reflective surface doesn’t bother me as much as it does some people, I think the little “glow” lights underneath it that denote which programs are currently running is completely unusable. Look at the difference between the Leopard Dock and the Tiger Dock.

Tiger:

Leopard:

You can remove the glassy shelf from the dock by using the following commands at the terminal:

• defaults write com.apple.dock no-glass -boolean YES
• killall Dock

Also, one can get the triangles back by reading the article Leopard Dock with black triangle

The Folders

The folder icons from Tiger have changed from a 3/4 perspective view to a front perspective. Although a regular folder is easily recognizable, system folders and docked folders lose contrast when compared to their Tiger brothers.

Consider the following folders.

Tiger:

Leopard:

The difference is striking. At a glance, the Tiger icons are clearly different from each other giving meaning to the icons. The Leopard icons lose this contrast and easily become lost within each other. It’s hard to tell if there is anything special about these icons at all. This is especially true for those users that do not have the best eyesight.

In the next article I’ll cover the huge drop shadow and that dang highlight color.

Got Reverse DNS?

Saturday November 17, 2007 03:19 | 0 Comments

• Tags:

As an email administrator, I’ll sometimes get complaints that my email server is blocking legitimate messages. In about 90% of the cases, the culprit is a misconfiguration of the sender’s DNS servers.

The reason that it’s DNS instead of a mail server configuration? Reverse DNS is the answer. Reverse DNS or RDNS is widely used by email administrators to block spam messages coming from personal computers that are acting as zombies as they will always fail a reverse DNS check. Unfortunately, small and medium sized businesses that don’t have the luxury of having on-site mail administrators sometimes get caught by the RDNS trap as well. For those, fixing the DNS issues is vital to their continued business.

Here is how it all works.

Let’s say that I have cable Internet access through Cable Internet Company X and my poor Windows PC has been unwittingly turned into a zombie by a virus. From this point on it’s starting to send out spam messages to the Internet. For the sake of the example, we’ll say that my IP address is 85.105.64.87 (note: this is an actual IP address that was blocked by my Postfix server).

When a connection attempt is made to a mail server that is doing RDNS checking, the server will attempt to lookup the name that corresponds to that IP address.

If you have a * nix machine, you can do a reverse lookup by using the dig program. dig -x [ip address]. This this case, dig -x 85.105.64.87 returns the following:

87.64.105.85.in-addr.arpa. 85395 IN PTR dsl.static851056487.ttnet.net.tr.

I should note that if there is no PTR record for that address, then the RDNS check fails right here! This is actually where most legitimate servers get blocked since you can’t use GoDaddy or Register.com to create PTR records. You have to go through your ISP to have those created. However, in our example, there is a PTR record so the check continues.

Using the PTR information, the mail server will then do a forward lookup for the address dsl.static851056487.ttnet.net.tr. On a *nix machine a forward lookup is done by typing in dig [hostname].

In order for a RDNS check to be completely successful, the A record would return the IP address for the PTR record. These have to match! In the case of our example, the A record should point to 85.105.64.87. The dig program reveals something else instead:

dsl.static851056487.ttnet.net.tr. IN A

Notice that there is no IP address after the “A” part? This is a failure.

A valid set of DNS records would be similar to the following:

“A” Record:

mail.eddorre.com. IN A 192.168.1.1

“PTR” Record:

1.1.168.192.in-addr.arpa. IN PTR mail.eddorre.com.

If legitimate email is being blocked because of a Reverse DNS check failure then make sure that you have done the following:

• Make sure that your mail server has a static public IP address
• Make sure that there is an A record pointing to the static public IP address. I usually create one by adding “mail.” to the domain name. For example: mail.eddorre.com. I should note that you can create an A record using your domain registrar’s DNS utilities. You don’t need your ISP to do this for you
• Call your ISP and have them create a PTR record for your static public IP. The PTR record should point to the name you chose in step 2