Quick Talk on SPAM and the X-UID Header

Today, I worked on an X-UID problem, the problem of emails using odd (or large) X-UIDs. If you ever have a mail client that just stops reading emails, but can read the message if it is moved to another folder, you should first check permissions, and then check to see if the email message was given an odd (or, and again, large) X-UID header. The particular mail client I worked on used a 4-byte integer cast for pulling the UID, which was incapable of working with the entire UID of many of a particular client's messages. I wasn't able to think of any quick way to remake these UIDs, other than getting a MIME message cleaner or building one myself. Unfortunately, that's all that can be done. There is a drastic need for an improvement to the mail protocols and this is one issue that persists throughout current systems. Hopefully this helps someone from some headache.

A World Where Database Backups FAIL!

You ever do something that not even your backups can save you from? I have, and it is one of the most gut-wrenching moments you will ever experience in computing.

Backups are only as good as the delay between their creation. For example, if you backup a database at 7:00 am and an issue occurs at 7:00 pm, you still have 12 hours of data to restore. Not something anyone wants to hear.

Thankfully, if you use MySQL, you may be in luck. Have MySQL store binary logs of all updating commands sent to it. Basically this includes anything that isn't a selection of data, but a manipulation of data. You can set this up with mysqld (the MySQL daemon) by providing this option with it:

--log-bin

It will make processes slightly slower, but this is a slight con for an amazing pro.

Let's go back to our example. Let's say you have binary logs storing at 7:00 am right after you create your backups. You can restore your data to 7:00 am from a backup, but you are still missing 12 hours of data. You can use fancy-schmancy monitors, but I merely like looking through the next day's binary log and find the offending piece of code such as:

TRUNCATE foobar;

Then, get the binary data of all data that updates data in table foobar like so:

mysqlbinlog thebinlog | grep ' foobar' >> filteredlog.sql

NOTE: Your command may be "slightly" different from mine.

Then all you do is remove all commands starting at the offending command onto the end of this file (in our example this is "TRUNCATE foobar;"). Once you are done, save this SQL script and run it in a MySQL client.

Voila! You have perfectly restored your database up to the EXACT code that ruined it!

Neat huh?

Happy Birthday, Mason!

It's just my good friend's birthday. I encourage everyone to wish him a happy birthday!

Happy Birthday!

Welcome!

Welcome, rencalago. As my first follower, I wish to welcome you to my blog. Hopefully you find my code pondering useful and informative. I spend much of my programming life designing, documenting, coding, debugging, maintaining, talking, and all the fun little tasks and trials in between, so I figured I would just share a little of my knowledge with you and the rest of who cares here, in this blog.

So, welcome again. Look forward to having you read my ponderings.

Hiding Email Addresses

With a business or informational site, your contact information is power. It dictates the accessibility of your clients, friends, or fans, to you. However the more and more I play this game called web development, the more and more I find the uselessness of providing an email address (actually ANY email address) to the user. Any system that can handle a web site will typically have some manner of mailing functionality available. If your site doesn't offer this functionality, ignore what I say and risk keeping your email addresses on your site. But if you are one of the majority, bear with me.

The sad truth of this world is that people are out there digging out email addresses posted on web sites on these site's forums, articles, and yes, their contact sections. They will either use these email addresses to send emails TO, or worse, use these email addresses to send emails FROM your addresses.

If SPAM is sent to your address, this can be annoying, unproductive, as well as embarrassing. There are many SPAM blocking programs available nowadays, but the best defense is a preemptive one and not a reactionary one. In other words, you address the reason for the problem and not the effect of it. And mail is dumb, as is the case for the more black-hatted of the black hats or script kiddies who use your email address to send out emails. Some of you may must be wondering how this could happen. Well, again, mail is dumb. Mail servers care more about who it's going to, and not who it's coming from. You'll notice this happening when you receive a NDR (non-delivery response). What this means is that someone sent an email to a nonexistent recipient with your email address as the sender. The mail server will send you the response of this transaction. NDRs are common occurrences (I've noticed it a lot in my clients newsletters), but if you never sent an email to the nonexistent recipient defined in the NDR, you may have been victim to this problem. Soon NDRs aren't the worse of this. Mail servers will get wiser to the spamming and blacklist your email address. It DOES happen.

Ouch.

For these reasons, I move that email addresses be hidden from web sites. If people must send you emails, I suggest provide a form, process the form with a script, and mail the message on their behalf.

This has many advantages. Firstly, it hides the email address from the site. My reasons are the reasons I mentioned above. Second, it allows you more control over the email people send you in the form of validation, verification, and cleaning. You will get more organized and less frivolous emails sent to you this way which will help your respond time to these emails. Third, it will make email easier. Everyone submits a form and the recipient and any other static fields will be entered for them. This will streamline the process.

I could go on, but these pros should provide you enough to make your own decision about my suggestion.

Form Field Naming

It's fairly easy to do and yet SO useful. When working with forms, I like to use arrays for all my fields. All data retrieved in the form is put into a values array. A parameters array informs the form's action what to do with that values array.

Observe the following. It's purpose is to submit an email (although that code is not shown here):

<form action="email.php">
<input name="parameters[mode]" value="send" type="hidden">
<input name="parameters[redirect]" value="http://www.foobar.com" type="hidden">
<input name="values[subject]">
<textarea name="values[body]"></textarea>
</form>

It's a simple enough form, but makes it easier to handle in the form's action. PHP and other server side languages champion great array functions that make your life easier through organization, data manipulation, verifying, validation, and other neat little tricks. Try it out and see exactly how useful it can be.

Firebug

Get it.