Yeah, so I upgraded courier-imap the other day, and nothing worked anymore. It ended up being due to changes in authdaemon/courier-authlib, and there not being a valid authdaemon.mysql to use, and it not properly failing over to authdaemon.plain and on and on. Enough of that; I’d been putting off switching to vhosted mail domains with courier/mysql/postfix for far too long, so I’ve now managed to pull that off. It’s a bit clumsy to set up, but once it’s up and working, it works pretty sweet, especially if you want to create virtual mailboxes for domains without having to create corresponding user accounts. It would be nice to figure out a way to allow procmail to interface with the vhosted accounts as well, but that’s a project for another day.
All sorts of stuff broke in a batch run the other night because the user named something with a space in it in the booking system, and half of the applications that use this data can’t handle spaces in filenames/arguments. One of the classic reasons is that the command-line programs that process a lot of the data interpret the spaces as new arguments, since they don’t escape the arguments with quotes. Brilliant. I classify this as an application error, because the developers should be restricting input to only those things that will work. I’m willing to bet I could put a non-writable character such a a quote, slash, question mark, etc. into the system and it would just blow up completely. Data validation is an easily solved problem, at least for these sorts of things — you just say that all input must come from a certain character class — in this case, letters, numbers, and underscores. That’s it. Problem solved. It’s a lousy developer (in my opinion) that doesn’t even try to handle these simple cases. I understand that it actually takes some brainpower to consider some more obtuse issues, and I’m not even asking them (yet) to think about cross-site scripting and sql injection and those sorts of things … but this sort of stuff is child’s play!