SMTP authorization does not work on Plesk 11

I was having this issue today and wasted quite a lot of time trying to figure out what was going wrong. The client’s server was running Plesk 11 and had SMTP running with port 25 open. IMAP was working flawlessly but Outlook kept returning the login box with “Login Failed” error pointing towards wrong credentials. But I knew the password was correct so I started haunting.

I logged in as root user and checked the mail log file at:

And there I found a lot of warnings but one stood out:

postfix/smtpd[31280]: warning: SASL authentication failure: realm changed: authentication aborted
postfix/smtpd[31280]: warning: SASL DIGEST-MD5 authentication failed: authentication failure
postfix/smtpd[31280]: warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory
postfix/smtpd[31280]: warning: SASL LOGIN authentication failed: generic failure

“No such file or directory”? Interesting.

I did a quick edit of the smtpd.conf by running:
nano /usr/lib64/sasl2/smtpd.conf

And there I saw the problem. The saslauthd_path and sql_database were wrong paths:

pwcheck_method: auxprop saslauthd
auxprop_plugin: sql_sqlite3
saslauthd_path: /postfix/private/plesk_saslauthd
auto_transition: yes
sql_engine: sqlite3
sql_hostnames: localhost
sql_database: /postfix/plesk/passwd.db
sql_select: SELECT `%p` FROM domains d, users u WHERE'%u' and'%r' and d.status=0 and u.status=0 and
sql_verbose: yes
log_level: 9

I just added the “/var/spool/postfix” before the paths and the correct file looks like:

pwcheck_method: auxprop saslauthd
auxprop_plugin: sql_sqlite3
saslauthd_path: /var/spool/postfix/private/plesk_saslauthd
auto_transition: yes
sql_engine: sqlite3
sql_hostnames: localhost
sql_database: /var/spool/postfix/plesk/passwd.db
sql_select: SELECT `%p` FROM domains d, users u WHERE'%u' and'%r' and d.status=0 and u.status=0 and
sql_verbose: yes
log_level: 9

Saved and got out, restarted the postfix:
/etc/init.d/postix restart

And hit the Send/Receive button and guess what… it worked! Please share this post and leave a comment if this worked for you.

Flattr this!

jQuery Image Resize Plugin v2.1.3

I’ve finally got around to updating the jQuery Image Resize plugin and pleased to get it working with jQuery 1.9+.

The plugin is also hosted on the new jQuery Plugins website:

I’ve also started using UglifyJS at it reduces the minified version to less than 0.5KB!

As usual, if you find any bugs, specially regarding IE, please do report them on github.

Download the latest version:
Report any bugs:

If for any reason you do not use github (seriously?!), then drop me a line on twitter, ideally with a jsfiddle example: @adeelejaz

Flattr this!

jQuery $.browser detection as a Separate File

As jQuery has removed $.browser from the versions > 1.9.0, I found myself extracting it to be used in my own projects that depended on the feature.

jQuery does provide jQuery Migrate plugin which includes the following code, but it also includes a lot of other things you might not need. I saw a couple of requests on the official blog and thought I’d put this live in case it helps anyone else.

Note: I highly recommend using tools like Modernizr for feature detection. Only use $.browser if you really need to detect the browser vendor!


Flattr this!

Revisiting User Agent Strings

I will start by pointing out that I will not spend time any time discussing the historic value of User Agent strings (also referred to as Browser IDs). A few sites have done it rather well (MSDN, MDN).

In this day and age, we optimize everything from our JS and CSS files to HTTP and image requests. We use tools that compress images better (or strip bytes off it). I propose an optimization that has been over-looked for years, for one reason or another!

For every single request made in this world via a browser, the browser adds a User-Agent header in the request, yes, every single time!


My first jab is at “Mozilla/5.0”. Is it still 1995? No. Then why are we carrying this “legacy” with us. Personally, I believe it is there so whenever a new developer asks why its there, it gives the senior developer an opportunity to re-live and re-tell the story of Browser Wars!

So, without any delay, lets look at what exactly is being sent by the famous browsers:

(For sanity, I’m not including IE6, IE7 or IE8 but trust me, they are VERY long!)

Internet Explorer 9 32-bit (70 bytes):
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)

Internet Explorer 9 64-bit (75 bytes):
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)

First stop, Internet Explorer. I just do not understand why I’m seeing the “compatible” string even though I’m not running in compatibility mode. But according to Microsoft, “it indicates that Internet Explorer is compatible with a set of common features”. Umm, what common features? We’ll never know. I also find it fascinating that Internet Explorer tells which 64-bit CPU you are using (that x64), Intel or AMD. What I just love is that really useful “feature” disappears for Internet Explorer running on “Windows Phone 7”! Oh come on… I would love for my Windows Phone to shout to the world what’s my CPU!

Firefox 13 (74 bytes):
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20100101 Firefox/14.0.1

Second stop, Firefox. See something repeating? Yep, that is the version of Firefox, in this case, 14.0 that is repeated twice. Why? Because Gecko version is kept the same as Firefox since Firefox 5. Then you might think what is “20100101” there for? I won’t bother trying to explain as things get really confusing really fast, specially considering that for mobile browsers this is same as the Firefox version (Whaaat??) Just head over to Mozilla for a dose of confusion as I’m starting to think they might even not know why it’s there to begin with, or how it helps someone by putting this info in a UA String.

Opera 12.01 (100 bytes):
Opera/9.80 (Windows NT 6.1; WOW64; U; Edition United States Local; en) Presto/2.10.289 Version/12.01

Opera does something that no one else does. They have actually dropped “Mozilla/5.0”. Which is my proof that the internet does not come to a halt when you remove it! Dead proud of it but my happiness doesn’t last long! For some reason Opera tells everyone, “Hey, its Opera 9.80” but then at the end, confesses its 12.01. I would love to argue about why it could’ve been better handled but there’s something else I want to point out. That “U”!!! Its an encryption identifier that has become obsolete since 1996! If that’s not enough, for some reason Opera is telling everyone that its “Edition United States Local”, which I assume means “it’s” a United States edition. How does it help anyone is beyond my limited thinking! I’m in the UK, and I doubt it’ll change if I was in France. That “en” is a two letter language code for English. I hope Opera is not telling everyone that I’m running a US English Edition of Opera, because I do not see how it can help the server serve me the right “content”, or someone needs to tell Opera that there is an “Accept-Language” header that they should use.

Safari 5.1 (106 bytes):
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.57.2 (KHTML, like Gecko) Version/5.1.7 Safari/534.57.2

Chrome 21 (106 bytes):
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.60 Safari/537.1

Lastly, Chrome and Safari, I’ll rant them together, well because Chrome just copies what Safari does. First, Safari and Chrome tell everyone, “Hey, its KHTML” but then they say, “Tell you what, we’re like Gecko”. I also think since the project is called “WebKit”, it should not be “AppleWebKit” but I don’t want to start a fan boy war. What I find fascinating with Safari’s version is that they use WebKit’s version right after Safari. And then create a separate declaration for “Version” which is actually for Safari. Go figure!

Operation Clean Up

My proposal is to simplify the damn thing. And here it is:

[Browser Engine]/[Version] ([OS]; [Architecture/Others]) [Browser]/[Version]

And the new User Agent strings will look like:

Internet Explorer 9 32-bit (44 bytes):
Trident/5.0 (Windows NT 6.1; WOW64) MSIE/9.0

Internet Explorer 9 64-bit (38 bytes):
Trident/5.0 (Windows NT 6.1) MSIE/9.0

Firefox 6 (53 bytes):
Gecko/20100101 (Windows NT 6.1; WOW64) Firefox/6.0.2

PS: Someone needs to tell Gecko team on how to do versions.

Opera 12.01 (50 bytes):
Presto/2.9.168 (Windows NT 6.1; WOW64) Opera/12.01

Safari 5.1 (51 bytes):
WebKit/534.57.2 (Windows NT 6.1; WOW64) Safari/5.1.7

Chrome 21 (56 bytes):
WebKit/537.1 (Windows NT 6.1; WOW64) Chrome/21.0.1180.60


Let’s take example of Yahoo!. Its a pretty optimized website but it makes 80 HTTP requests. Lets see how it pans out in terms of savings:

Browser Current Proposal Savings
Size per Request Size for 80 requests Size per Request Size for 80 requests
IE 32-bit 70 5600 44 3520 -37.14%
IE 64-bit 75 6000 38 3040 -49.33%
Firefox 13 74 5920 53 4240 -28.38%
Opera 12.01 100 8000 50 4000 -50.00%
Safar 5.1 106 8480 52 4160 -50.94%
Chrome 21 106 8480 56 4480 -47.17%

* All numbers are in bytes.

Just to re-iterate. This information is not cached, not zipped, and sent every single time! For every single page request. Imagine the amount of bandwidth we can save on mobile devices! Just imagine…

Flattr this!