Email Forms: Slient and Deadly
I really hate email forms, from a developer perspective. Meaning, I hate forms that just email something somewhere and then forget about it. The fact is that email is a horrifically dodgy medium to do anything with. Two-and-a-half years ago, I complained about Barnes and Noble doing this. A customer…
The author expresses frustration with email forms that are sent without any follow-up, citing issues with email as a problematic medium. They compare email to a forward pass, suggesting that once it leaves the sender’s hands, it can be lost or lost due to issues with mail servers or spam filters. The author suggests persisting form data on the server by serializing the data with a timezone and storing it in a non- URL-addressable directory.
Generated by Azure AI on June 24, 2024I really hate email forms, from a developer perspective. Meaning, I hate forms that just email something somewhere and then forget about it.
The fact is that email is a horrifically dodgy medium to do anything with. Two-and-a-half years ago, I complained about Barnes and Noble doing this. A customer service form on that site apparently just sent an email, which didn’t get delivered, and I got “Message Delayed” messages back for two days.
And this is how email is – sometimes it just doesn’t work. It’s like a forward pass in a football game. The quarterback may intend to get the ball into the hands of the receiver, but the reality is that once the ball has left his hands, it belongs to anyone. It’s up for grabs until it is safely delivered into the arms of the receiver. Sure, it’s probably headed in the right direction (unless your quarterback is Kerry Collins), but it’s a crapshoot until it actually gets there.
The problem with accepting user input then just emailing it is that stuff will break, and then your data is gone, man. Mail servers can stop running, mail can get sent and just get lost, or it can get sucked up by spam filters.
And the big problem with losing email like this, is that it generally happens silently. You usually don’t find out anything is wrong until a few days later when someone calls and say, “Uh, we haven’t gotten anything from the Web site in a while…” And, by that point, how many are you missing? How much user input is gone? And can you even figure out who entered something so you can contact them and get the data again? Not usually.
What I’ve learned is that you still have to persist the form data on the server, even if you’re emailing it. This can be as simple as just serializing the data somewhere safe with a timestamp, so that if email starts vanishing, you can go back through the data and figure out at what point you stopped receiving stuff, and recreate what’s missing.
Usually, you can serialize the entire POST, but if you’re doing server side validation and the POST can get submitted more than once, you need to remember to delete what didn’t make the final cut. A more efficient route is to just write the body of the email you send to a text file with a timestamp in a directory that isn’t URL-addressable.
In a perfect world, you’ll never have to touch it and it will just sit there and accumulate. But this ain’t a perfect world, and having it is really handy when something goes bad.