Had an interesting experience today. In the quest to debug one of my apps I was talking to someone with an interesting problem. His email address was getting double encoded.

Example:
user@domain.com

Normally becomes:
user%40domain.com

When it passes thru the browser.

So what happens when, for some strange unexplained reason, the info is double encoded?

The % in %40 becomes encoded too, you get user%2540domain.com

Which is exactly nothing but an invalid email address. The system kicks it out, and it’s unusable.

Now most people will never experience this problem, and perhaps only 5% of your userbase may experience it. But what if this guy, this new subscriber, was a potential big customer? What if you’re working with multi-thousand dollar items and every single person counts?

We could simply blame it on the software, but if you’ve been on the internet for more than a week you’ll notice… there are more potential problems than anyone can ever solve, ever. No matter how great the app is, some stuff will always slip thru the cracks.

It gets worse, and perhaps more ironic. I get a spam on my forums last night. Some web developer that should know better is posting ads on a forum of mine. It’s my general policy to track these guys back when I can, and in this case it was easy. They put their URL all over the place. So I went there and sent a message via their contact form.

I got this error:
Hi. This is the qmail-send program at xxxx.yyyy.net I’m afraid I wasn’t able to deliver your message to the following addresses. This is a permanent error; I’ve given up. Sorry it didn’t work out.

<user@domain.com>
Connected to xx.yy.zz.ww but sender was rejected.
Remote host said: 554 refused mailfrom because of SPF policy

Now let me translate this from “Geek.” You see SPF policy is designed to verify that the sender of a message is really the sender. It looks at the chain of servers a message passes thru and compares it to a record specified by the domain, and if they don’t match… it’s trash’n time. In otherwords SPF helps to make sure that 3rd parties have a hard time sending email pretending to be you (spammers don’t use real “From” addresses anymore, they use another name on the list).

The problem here is simple. I’m using their contact form to send mail, and it’s sending it as me. Their mailer notices that I haven’t given permission to send mail as me to their mailing server and denies the message.

These elements are hilarious. SPF = anti spam. Good right? A strict policy, good too, right? A contact form works great too since you don’t have to post your email addresses on the site. All of these, by themselves, work flawlessly. But when combined… it’s an exercise in hilarity.

Nobody with an SPF record can ever send messages thru their contact form, it’ll bounce and they won’t receive it. I could’ve been a big paying client with thousands of dollars to spend… but a poorly thought-thru config will surely cost them a lot of money.

So why am I going thru all this? Just to point out wierd technical problems?

Because in today’s world we’re used to letting the machines do the work for us. This sounds great, to be sure. But sometimes our machines fail us. They were told to do something wacky, or a set of normal commands mixed together becomes an evil frankenconfig monster. Ever seen 2001, a Space Odyssey? It’s HAL, just a few years late.

It’s unpredictable. And it will cost your business customers and money.

Unless…

The developer above would’ve been smart to test their config. They would’ve also been smart to have a usable phone number, and perhaps an alternate way of sending messages via the internet. This is why I’m a big proponent of support forums, if they can’t reach me thru a contact form they can post to the forums where I’ll still see it.

It’s all about a little preparation and having backups in place.

What’s your backup?