Email email go away

My web host smartly disables php's fsockopen function, but this makes the Swiftmailer library I just downloaded not work. I might have to connect to my email provider with curl instead. Such joy, trying to navigate through other people's design decisions.

Email Buggy Joy!

In case you haven’t heard, sending email from web apps is a real pain. PHP’s mail() function is terrible for large numbers of emails because it opens a new SMTP connection for each message. My web host limits outgoing SMTP messages to 100 per hour. If one organization using my system has 50 members, two of their emails would already be exceeding the limit. Sendmail seemed like a good solution, but I found out that my web host even limits these to 200 per hour. I calculated that if I throttled the emails, I could send one email every 16 seconds (4800 per day) and still stay under the limit. But then people’s emails would be delayed, possibly by hours at peak activity times. Gmail also sets limits on outgoing SMTP messages, so I can’t use my account hosted at Google Apps, either.

Beyond the outgoing message limits, deliverability is a problem. You have to set up DKIM and SPF keys in your DNS record, and even then, some email providers will still block you.

I’ve spent the last two days research third party solutions. I’ve looked at basically everything out there: Postmark, Sendgrid, CrtiSend, Socket Labs, and others. I’m close to reaching a decision as to who I’ll go with. I spent a full day setting up my app to be used with Postmark only to figure out that their service will not meet all of my requirements. I’m really looking forward to getting past this bottleneck.

This afternoon I’m taking care of some business related items while I wait for my accounts to be set up with two of those email providers. I filed business name papers with the Secretary of State, and I’m going through about nine months of accounting backlog. Tomorrow, hopefully, I’ll be able to write some code again!

Should you check the user agent?

Checking the user agent on incoming requests to prevent session hijacking is sort of like putting scotch tape on your door to keep intruders out of your house.

But, it is one little extra barrier that an attacker will have to bypass, so I put it in my code. Then I was playing around on my site in IE8 one day, and just for fun I hit the Compatibility View button. And it broke everything.

Clicking this button toggles the user agent between IE7 and IE8 and thus breaks the whole thing. To make sure the site still works, I've taken the user agent checking completely out of the application.

This still won't allow anyone to hijack a session, because all traffic, including cookies, is sent only over SSL. There are a number of other security features built in, so the scotch tape can come off.

Beta Is Imminent

I have enough features coded to start beta testing. The software is still not complete; there are a few holes in the functionality, and there are a few known bugs, but I’d like to get a system up and running on the live web server at Dreamhost so I can iron out any deployment issues far in advance of the launch date.
Here are a few particular things I’ll be watching for:

Problems with SSL. I’m currently hosting jQuery and jQueryUI on Google, and those requests are non-encrypted, so I’m curious to see if that will work, or if I’d be better hosting jQuery locally.

PHP Configurations. I’m setting PHP configurations directly in my scripts; I’ll look into the possibility of installing PHP from binaries and configuring those settings directly in php.ini.

Performance. There are three concerns here. First, the wire transfer speed (what a technical term). I know that there are more HTTP requests on my pages than there needs to be. Combining CSS and JS, as well as using image sprites, will reduce the number of concurrent requests, but I haven’t done these things yet. Some pages are very JavaScript intensive and I’m interested in the client performance on older machines. Lastly, I have some rather complex SQL queries, and I’d like to see how the database performs when n gets big.

Usability. How easily will people be able to figure out how to use the software to perform specific tasks?

Unknown Bugs. I’m mainly looking for logic errors here. For example, today I just discovered that members cannot change their own passwords because they don’t have setSecurityRole permission.

File permissions. I want to make sure that users only have access to the files they need access to. On my development machine, all folders are writable, but that won’t be the case in production.

I just set up the SSL certificate on my server today. I anticipate launching beta by Wednesday!

I'd like to introduce my brother, the eminent psychologist, Niles Crane.

Frasier was eminent when my eminence was merely imminent.

FogBugz World Tour

Last Thursday, I had a chance to see Joel Spolsky at his Minneapolis stop on the FogBugz World Tour. I’ve been following Joel’s blog and businesses for the last ten years, and it was cool to see him speak in person. He was in town to pitch the latest version of his FogBugz and Kiln software.

I’ve been using FogBugz as a bug tracking and project management tool for the last six months, and I really like it. Luckily, I can get a free license as a one-person startup. Past that, it gets quite expensive. That shouldn’t be a problem, however, as I don’t ever anticipate adding employees.

I’ve been considering using distributed version control for a while. For development teams, there are no questions about its superiority to traditional version control systems. But I haven’t found a real need for any type of VCS yet. I keep daily backups of all of my projects, so I can go back in history to whenever I want.

The one thing that does get a bit more complicated is when I’ll have different versions of the codebase – one for dev and one for production. The branching capabilities of Mercurial would definitely help me out there, but I’m not sure it’s worth the half day investment it would take to configure and learn it. I’m pretty focused on my ship date at the moment, and this is one of those things that I feel can wait.