This is a free beta release, so anyone can sign up and use the service totally free of charge. Hit the site to get started:

http://fwdvault.com

If the description “Secure data backups through email” isn’t obvious enough, you’ll find more information on the About page.

However, in the course of testing today, I realized that when a message is forwarded, sometimes the forward header will encode the email address, which gets stripped when I process the message. Allow me to demonstrate. Here’s the body an example message that someone might send to Fwd:Vault for safe keeping…

---------- Forwarded message ----------
From: "Office Flirt" <flirt@example.com>
Date: Wed, Jan 14, 2009 at 10:14 AM
Subject: Delete those images
To: you@example.com

My boss is sniffing around. I want you to delete those pictures I sent you right away.

Signed,
Office Flirt

Obviously you’re tucking this one away in Fwd:Vault to provide a little CYA-insurance when the boss calls you into his office. Good call. Now, before today, this message would come out of the scrubbing process looking like this:

---------- Forwarded message ----------
From: Office Flirt
Date: Wed, Jan 14, 2009 at 10:14 AM
Subject:
To: you@example.com
...

Look at the bolded red line. The email address is gone. You don’t have any other copies of it, so your boss doesn’t believe your story, and you get the blame. You’re forced to attend one of those god-awful sexual harassment classes. Fail.

So, what happened? Remember, you are looking at the body of a message in plain text. That “Forwarded message” block at the beginning is just part of the body text. So when the text was scrubbed by strip_tags(), the function picked it up as just another tag, which it dutifully removed.

To handle this situation, I came up with a piece of code that will look for email addresses in “tagged format” — i.e. surrounded by < and > — and remove the surrounding symbols, leaving us with harmless text.

$test = 'some surrounding text';
$test = preg_replace( "/(\<)(.+@[^\(\);:,<>]+\.[a-zA-Z]{2,4})(\>)/",
                      ' $2 ',
                      $test);
$test = preg_replace('/[\s]+/', '', $test);
echo $test;

Let’s break this down. First, we have a regular expression that identifies email addresses: .+@[^\(\);:,<>]+\.[a-zA-Z]{2,4}. This is the same expression set in the example on the Quanetic Software Regular Expression Tester (an excellent tool). We surround that in parentheses to isolate it as a subpattern. Then on either end of the expression, we tack on more regex voodoo to look for tag syntax: (\<) and (\>). These also get parentheses to identify them as subpatterns. Once its finished, we have an expression that will only match addresses wrapped in tagging structure.

The second argument in preg_replace() is the replacement, or what we should replace any matches with. In this case, we’ve isolated the address from the tags using subpatterns. So all we need to do is make a single call to the proper reference, which is $2, because its the second set of parentheses in the expression. Confused? You can learn about subpatterns on the PHP manual page for preg_replace().

Note the spaces around the $2 in the second argument. Sometimes the address will not have any spaces between the person’s name and the actual address. This could lead to the address being combined with the name which, in the case of Fwd:Vault, would screw up our search indexing. So we add spaces during the replace, then make a second call to preg_replace() to eliminate extra spaces: $test = preg_replace('/[\s]+/', '', $test);.

Legal Disclaimer: In case you do end up using Fwd:Vault when it launches, I’m fairly certain the service wouldn’t be liable in this silly hypothetical. Just make sure you read the terms before you sign up if you play the field at your office. Sorry to everyone going “duh” right now; it’s a sue-happy world.

Update: When I went to implement this change today, I discovered that the code was catching newlines (\n or \r) in the crossfire. It was actually due to the second call to preg_replace(), the “\s” character class includes not only spaces but line terminators as well. Oops. The revised version looks like this:

$body_text = preg_replace('/[ ]{2,}/', ' ', $body_text);

I recently had need for a small side project to read e-mails. Every e-mail is split up into parts; each “part” represents every separate piece of the e-mail. The plain text format, rich text or HTML formats, and attachments are all sent as parts. Problem is that there is no obvious way to quickly decipher just how many parts you have in a message. The documentation for the imap functions in PHP is also woefully inadequate. Maybe I’ll help flesh it out once this project is done.

Anyway, you can ascertain the total number of parts using the results from the function imap_fetchstructure(). The parts array in the returned object contains ALL the parts of the message, including the top level used to construct the rest of the object’s data. So, this simple call is all you need…

$structure = imap_fetchstructure($mbox, $message_num);
$total_parts = sizeof($structure->parts);

Which is probably why I had a problem, and it had me initially cursing the name of WordPress.

My e-mail server sits on a different box, which means that I need to configure the e-mail functionality of my site to access this server via SMTP. I’ve set up countless PHP-based CMS’s—I contribute to one, and I’m in charge of custom-building another—so I know the first thing you always do is consult the manual, both the official one and Google. Of course, as you can see in these search results, I come up with absolutely nada. There is seemingly nothing in WP documentation about natively configuring the e-mail functions to use a mail server outside of the local box.

Further searching does reveal a hack up solution, which would suffice since I am pretty well-versed in PHPMailer. I also came across two decent plugins; ultimately I decided to go with WP Mail SMTP, as it’s functionality seemed to fit my needs. The plug-n-play style of the plugins system also made this a far better solution than hacking at the core code.

Which brings me to the reason I’m explaining all of this: simple SMTP e-mail configuration should be required in every CMS or CMS-style framework that sends e-mail, and that’s pretty much all of them. Why should users have to traipse across the net looking for a solution to a very common situation? Most hosting packages physically split their hosting and mail services for a menagerie of security and performance reasons.

I’m betting that a lot of WP users have found themselves in the same boat I did, and handled the issue with a plugin or two. But how many users even realized that what they lacked was SMTP configuration options, and instead simply knew that “I can’t send e-mail?” At the very least, WP documentation ought to explicitly lay out the e-mail setup, and point users to the available plugin solutions.

In the end, the plugin functionality came through, and honestly did impress me overall. Plus, during the turmoil, I learned about another great WordPress feature, the kvetch…