A maintenance window has been set tonight September 20th between 11:30 PM - 3 AM EDT (-0400 GMT). The window should be non-disruptive to all services. During this window the following changes will be pushed to the servers:

• Removed artifically low hard limit on Dovecot processes (32). Dovecot likes to be a little too liberal in its connection estimates and overcompensates with spare workers. During times of high volume, several idle workers spin-up waiting to resume resulting in starvation.
• Standardized Apache configuration files across servers
• Bumped mod_frontpage after mod_cgi was loaded in Apache to avoid segfaults (possibly a result of my “patch”)
• Relaxed threshold to trigger mod_evasive 403 redirects in Apache. Doubled threshold and increased interval from 1 to 2 seconds to ensure large pages with multiple cached items won’t result in false-positives
• Flush Dovecot’s auth cache once a user is deleted. Fixes rare circumstances where user would be deleted and recreated in the control panel (guys, that’s not a not great fix for a user going over disk quota). Dovecot held onto old uid mapping resulting in permission mismatch after successful authentication.
• Added extra set of customizable Apache parameters which apply only to SSL sites.  Used primarily for chained SSL certificates at this time.

12:32 AM Update: maintenance window is now closed.

I will be breaking the football-themed tips this week — I know, I know… bust out the handkerchief and sob a bit. It’s time to move on to bigger and better things. This week we will be looking at sorting e-mail as it arrives on the server. Sorting upon delivery has two advantages over sorting in your e-mail client (Outlook, Thunderbird, Mail.app, etc.): (1) access from multiple e-mail clients will have the same e-mail layout and (2) mail is filtered as soon as it’s delivered; there is no need to perform a batch sort first thing in the morning.

Filtering on the server is handled by maildrop, which acts as the local delivery agent. maildrop is also responsible for handing the message off to SpamAssassin for spam checking. Filter rules are stored in the file named .mailfilter in each user’s home directory. There are two very important caveats that you need to know before hacking your filter to bits.

1. maildrop expects Unix-style end-of-line markers (”\n”). If you edit the script on a Windows/Mac PC either in the browser via File Manager in the control panel or a separate text editor, then watch out! EOL markers are generally converted over to their respective OS’ style. On Windows, this means “\r\n” would silently be used to mark the end of a line and on Mac it would be “\r”. Both of these EOL markers will result in unexpected behavior in the filter.EOL markers may be converted either in your editor or in the File Manager. Conversion in text editors vary from editor to editor; for example in Komodo right-click file tab -> Properties and Settings -> Line Endings -> UNIX \n, untick Preserve existing line endings; Vim is simpler with “set ff=unix”; and if you are using ed… then, well, you may be a lost cause.
2. maildrop also requires very restrictive permissions. Only the owner may have read/write access to the file. Permissions may be changed by either bringing up the file options in the File Manager by clicking on the icon to the left of the file name, through your FTP client (SITE CHMOD command), or inside the shell with chmod. maildrop will refuse delivery if the .mailfilter is anything but 0600 (-rw-------).

Keep those two requirements in mind. These are the two most popular problems that I see with users who embark on maildrop modifications.

Syntax is very simple with maildrop.

if (/Subject: Fantasy Dungeons and Dragons/D)
{
   to "Mail/.Mailbox/"
}
if (/(To|Cc):.+msaladna@apisnetworks.com/ && /From:.+sports-fantasy-[^@]+@yahoo-inc.com/)
{
   if (/Subject: Fantasy Football/D)
   {
      cc "!insider-analysis@apisnetworks.com"
      to "Mail/.Mailing Lists.Fantasy Football/"
   }
   if (/Subject: Fantasy Baseball/D)
   {
      to "/dev/null"
   }
   cc "Mail/.Important Copies/"
}

Let’s step through each line.

Line 1: examine the “Subject” line of an e-mail. If the subject, what appears in the Subject line of an e-mail message, explicitly matches, case-sensitive (D flag at the end) “Fantasy Dungeons and Dragons” [aside: I’m stoked for the 4th edition rules] then process the following rules between lines 2 and 4 [aside: line 3 for those mathematically challenged folk such as myself] enclosed by braces ({…}).

Line 2,4: maildrop isn’t a fan of K&R braces, so you will need to place the opening/closing braces, which are required, on their own lines.

Line 3: deliver it to a Maildir-style mailbox named “Mailbox”. This would appear in the e-mail client under Inbox -> Mailbox. Recall that e-mail is stored in $HOME/Mail/. maildrop begins in your home directory, so using a relative path (e.g. Mail/…) would work fine. An absolute path (/Mail/…) would fail; however, an absolute path prefixed with the home directory, stored in the HOME variable, would be OK ($HOME/Mail/…). If there is one thing to learn, learn that to begin mailbox delivery locations with “Mail/”. to instructs maildrop to deliver the message to this directory/e-mail address and finish processing the message.

Line 5: slightly more complex example of header matching. This time the e-mail must have not matched any previous blocks which ended in a to (terminates message processing); think of it falling through to the next case. Programmatically this could be represented as if (…) { … } else { … } except maildrop doesn’t understand else statements. If my address, msalandna@apisnetworks.com, is provided in either the To or Cc field, i.e. I wasn’t addressed in a Bcc, and (&&) the message is from sports-fantasy-<anything>@yahoo-inc.com, then process the next chunk of code. Note the [^@]+, which may very well look alien to you. This is a regular expression, which is a more flexible process of wildcard matching. You’ve used “ca*” to match “cat” and “car” before, right? Same principle, but this offers more flexibility and, incidentally, complexity. .+ is a close analog, which matches one or more of any character and this is used to ensure the target e-mail address, subject — or more generally, string — appears in the line. If you want the true analog to “*“, then use the regular expression .*, which means to match zero or more. [aside: I had to add that otherwise my inbox would be flooded with angry nerds upset over labeling AD&D as “fantasy” and misrepresenting regex patterns in the morning.] Note the absence of D in either pattern. This means both matches disregard case.

Line 7: if the subject begins with “Fantasy Football”, and again case doesn’t matter with the D, then process the next section enclosed by braces.

Line 9: make a copy of the message (cc) and forward it to insider-analysis@apisnetworks.com. Note the placement of the exclamation mark, !. ! informs maildrop that the text immediately to the right is an e-mail address. If it read ‘cc “insider-analysis@apisnetworks.com”‘, guess where the message would be copied? If you guessed to a file called $HOME/insider-analysis@apisnetworks.com, then you would be absolutely correct. Don’t forget the ! if you intend of forwarding a message. Replacing cc with to would forward a copy of the message to insider-analysis@apisnetworks.com and terminate execution. Because execution is not terminated with the cc directive, we continue onto the next line.

Line 10: terminate execution and deliver the message to “Mail/.Lists.Fantasy Football”. Note the double-quotes surrounding the destination for each directive. It’s good form to do this for various reasons, which you’ll find out the hard way if you specify an IMAP folder with a space in it or try forwarding to an external e-mail account (it won’t work correctly). This IMAP folder would be represented in the e-mail client as Inbox -> Lists -> Fantasy Football.

Line 12: this line is left as an exercise to the reader to ensure you have a pulse. See Line 7’s explanation if you get stuck.

Line 14: just like before, we’re delivering the message to a file, but /dev/null is a special file on the server designed to swallow whatever it is fed. Think of it like a black hole. Because my fantasy baseball team is in shambles this year the message is deleted, never to reach my inbox and prolong my misery.

Line 16: finally, if the message makes it this far it has to be important. Store a copy of the message in “Mail/.Important Copies”, which would appear in the e-mail client as Inbox -> Important Copies.

Line 17: if the message hasn’t triggered a to directive yet, then fall through out of the special processing and deliver to the default mailbox. If a message matched line 16, then it would also fall through to the end, because cc was used and not to. Implicitly to “Mail/” appears at the end of the .mailfilter file; that is another way of looking at this. If nothing else terminates message delivery, then execute to “Mail/” and terminate delivery.

That was fairly easy, right? I hope so, because you’re going to be quizzed now. But before we do that, make sure the IMAP directories exist on the server. You can accomplish this with the maildirmake program or by creating four directories with the permission set 0700.

mkdir $HOME/Mail/.MyDir/
mkdir $HOME/Mail/.MyDir/{cur,new,tmp}
chmod -R 0700 $HOME/Mail/.MyDir/

Let’s wrap up this week’s tip with a quick exercise to make sure you know what you’re doing. Refer to the headers below as a guide to answer the following questions. If you get them correct, then you are ready to write filters on your own.

Return-Path: <bounce-live-964777629-46771286@ezinedirector.net>
X-Spam-Checker-Version: SpamAssassin 3.2.0 (2007-05-01) on
assmule.apisnetworks.com
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_60,
DK_POLICY_SIGNSOME,HTML_MESSAGE autolearn=no version=3.2.0
X-Original-To: football@apisnetworks.com
Delivered-To: msaladna@apisnetworks.com
Received: from mx11.ezinedirector.net (mx11.ezinedirector.net [65.207.215.17])
by assmule.apisnetworks.com (Postfix) with ESMTP id 6FB60274719
for <msaladna@apisnetworks.com>; Fri, 31 Aug 2007 07:57:07 -0400 (EDT)
Message-ID: <31063140@964777629.ezinedirector.net>
X-Subscriber: 46771286
Subject: FF Today News: Week 1 Right Around The Corner
From: <list@fftoday.com>
To: football@apisnetworks.com
X-Campaign: 964777629
Reply-To: <bounce-live-964777629-46771286@ezinedirector.net>
Errors-To: <>
Date: Fri, 31 Aug 2007 06:32:16 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary=”_NextPart_000_1188541936_CFX_iMSMail_1017171156″
Content-Transfer-Encoding: 8bit

1. If the e-mail was delivered in August of this year, then store it in Inbox -> Football -> August
2. If the message starts with “FF Today:”, then save it under Inbox -> FF Today
3. If the message is from “list@fftoday.com” and contains the subject “FF Today:”, then store it under Inbox -> Lists -> FF Today -> Announce, otherwise if the subject doesn’t match, then save it under Inbox -> Lists -> FF Today -> Misc
4. Finally, for the smart-asses out there, if the message isn’t labeled as spam, addressed to football@apisnetworks.com, a multipart MIME message, and less than 30 KB in size, save in Inbox -> FF Today -> Small otherwise if the size if greater than 40 KB forward it to football-big@apisnetworks.com, which just so happens to be an alias to football@apisnetworks.com. Hint: use reformail and avoid forwarding loops.

Answers will be posted on Wednesday. Anyone wishing to venture forth bravely to answer question 4 feel free to post it here and I’ll let you know whether you’re warm or cold ;). Also, it looks like we had a football-themed tip in the end. That’s a three week streak.

Wednesday Update
As promised, here are the answers.  Problem 4, despite having a real answer, was a joke problem.  If you have seriously attempted it and can’t make sense of the solution, then let me know and I can walk you through it.

Problem 1:

if (/^Date:.+Aug 2007/)
{
	to "Mail/.Football.August/"
}

Problem 2:

if (/^Subject: FF Today/)
{
	to "Mail/.FF Today/"
}

Problem 3:

if (/^From:.+list@fftoday.com/)
{
	if (/^Subject: FF Today:/)
	{
		to "Mail/.Lists.FF Today.Announce/"
	}
	to "Mail/.Lists.FF Today.Misc/"
}

Problem 4:

if (/^X-Spam-Status: No/ && /^(?:To|Cc|X-Loop):.+football@apisnetworks.com/ && /^MIME-Version: /)
{
   if ($SIZE < 30720)
   {
      to "Mail/.FF Today.Small/"
   }
   if ($SIZE > 40960 && !/X-Loop: football@apisnetworks.com/)
   {
      xfilter "reformail -A 'X-Loop: football@apisnetworks.com'"
      to "!football-big@apisnetworks.com"
   }
   # Messages fall through to the default mailbox between 30 KB - 40 KB
}

As always, I’ve taken it upon myself to pack in too many updates for the next esprit release. Aside from the Joomla one-click driver update and basic symlink support, here’s a listing of other notable changes sitting on the development server pending completion:

• Symlink target autocompletion
• Portable/non-portable symlink warnings; non-portable are unable to be read by Apache (e.g. ln /var/www/html/ foo)
• Multiple file upload
• Further conversion of File Manager’s jumbled JavaScript to lightweight (comparatively speaking of course) jQuery methods
• WordPress 2.2.3 update
• File rename support

As you probably know from experience, I am terrible when it comes to providing ETAs of releases. I will arbitrarily say the next release is due out “soon”. New symlink support lays the foundation of moving the subdomain management from Ensim to esprit. Likely you’ll see that afterwards, but in the meanwhile don’t forget that you can assign subdomains from the shell.

Welcome to week number 2 of the fantasy football-themed weekly tip. I had difficulties tying football into this week, but lo and behold as if it were a sign from the big cheese, Peyton Manning, himself — who I drafted, but lucked out on Harrison/Wayne to complete the trifecta — we’ve got yet fantasy football-themed tip. At this point you may begin taking bets on how long I can keep it up. Two weeks and counting…

This week we’ll be looking at a lovely marriage between the e-mail client Mozilla Thunderbird and sa-learn. Although I will refer to Thunderbird explicitly, this system works with any e-mail client that can use IMAP and labels. Don’t feel left out if you are using Outlook, Mail.App, Eudora (which is on its ninth life), or any e-mail client. A label is an arbitrary assignment to a particular e-mail. For example, hitting “1″ on the keyboard may assign “Important” to the message in your inbox while “2″ may mean “Work” and so on. In Thunderbird, “j” is a shortcut to label a message as “Junk”. We’ll use this special label to automate SpamAssassin teaching.

Let’s face it. Thunderbird’s junk controls are terrible. Let’s also face the fact that even though this is evidently a spam with link to malware it doesn’t stop me from forwarding to my current opponent this week, “Nasty Audibles”. See, we have accidental death/dismemberment/incapacitation clauses every year in our league and I’m down heading into Monday Night Football. I will take every opportunity to guarantee a victory during week 1… forwarding malicious e-mails included.

Toggling “Junk” status in Thunderbird labels a message as junk, but what happens internally? IMAP is designed for synchronization among e-mail clients. Each e-mail client on each computer has access to the same status information such as whether it has been read, replied to, forwarded, deleted, and any arbitrary labels (Important, Work, Junk, etc). These status changes are stored either in the message or in the file name itself. Since the major software changes in February [note: a change from mbox to Maildir++ introduced the one file-per-message style of storage], these status changes are stored in the file name and thus easily accessible by a simple shell script.

Digging deeper, let’s examine a message in our main mailbox in ~/Mail/cur/:

1189385193.M835488P16631V0000000000000905I00BB08BB_0.assmule.apisnetworks.com,S=1290:2,RSk

The last group of characters (RSk) in the comma-delimited set holds the message info. Other metadata in the file name is inconsequential for the purpose of this tip, but you may always read more about it on Dovecot’s wiki. We have three flags in the info field:

• R: replied to message
• S: message has been viewed by the e-mail client
• k: special arbitrary label set by Thunderbird (”non-junk” label)

Watch what happens when the message is labeled as “Junk” in Thunderbird:

1189385193.M835488P16631V0000000000000905I00BB08BB_0.assmule.apisnetworks.com,S=1290:2,RSj

One thing changed in the info field: k to j. I know that light bulb has gone off in your head now, but don’t bust out your mat just yet. As I mentioned earlier that labels are arbitrary. How do you find out what label means what? Check ~/Mail/dovecot-keywords. Here are the labels for my IMAP account:

0 unknown-0
1 unknown-1
2 unknown-2
3 unknown-3
4 unknown-4
5 unknown-5
6 unknown-6
7 unknown-7
8 unknown-8
9 Junk
10 NonJunk
11 $Label1
12 $MDNSent
13 $Label2
14 $Forwarded
15 $Label3
16 $Label4
17 $Label5

There are 26 possible labels, 0-25, which correlate to 0 = a… 25 = z. The 9th index is labeled Junk and the 10th character in the alphabet is j… the 11th is k. Now, do the labels in the file name make sense? These vary between user accounts. Even though the 9th index may be Junk for my e-mail account, it may be the 21st for you. Always double-check dovecot-keywords before asserting the character association. Treating forwarded e-mails as spam because $Forwarded is in the 9th index spot, which is a “j” in the file name would be disastrous! Note that labels in the file name are case sensitive. a-z are reserved for the labels defined in dovecot-keywords. “a” does not have the same meaning as “A” in the info field of the file name.

Holding status information in the info field of the file name gives Maildir a big advantage in terms of easy manipulation. Let’s take this behavior and use the messages labeled as junk in Thunderbird to periodically move to our Spam folder and then feed those messages to sa-learn. Teaching SpamAssassin missed messages enhances its Bayesian database, which in turn increases the effectiveness of tagging spam. You can use the turnkey SpamAssassin configuration wizard to tweak delivery rules. For example, I deliver messages that score between a 5 and 10 into “Spam”, but generate a delivery failure notice. This allows me to inform the user that (a) there was a delivery problem, but (b) I can still return later to the message to determine whether it was spam or ham. If ham, then I can reply to it with a note about the delivery error. Anything scoring above a 10 is automatically deleted. Having a well-trained Bayesian database enhances the scoring capability of SpamAssassin.

#!/bin/sh
# Change this to the correct "Junk" label
JUNK=j
# Target mail folder
HOLD_FOLDER=~/Mail/.Spam/cur/
# Number of days to hold messages in mailbox and purgatory after label change
DAYS=7

find $HOLD_FOLDER -ctime +$DAYS -maxdepth 1 -type f -not -regex ',[^,]*T[^,]*$' -exec sa-learn --spam {} > /dev/null \;  -exec rm -f {} \;
find ~/Mail/cur/ -ctime +$DAYS -maxdepth 1 -type f -regex ".*,[^,$JUNK]*$JUNK[^,$JUNK]*\\$"  -exec mv {} $HOLD_FOLDER \;

If you would like to get learning status of which messages were learned, then change the first find command checking $HOLD_FOLDER to (find $HOLD_FOLDER -ctime +$DAYS -maxdepth 1 -type f -not -regex ',[^,]*T[^,]*$' -exec awk '($0 ~ /^Subject:/) { print substr($0,10) ; system("sa-learn --spam '{}' > /dev/null"); }' {} \; -exec rm -f {} \;) 2>&1 | mail -s "SA Learn Status" msaladna@apisnetworks.com

Of course you would replace msaladna@apisnetworks.com with your current e-mail address. The following options may be configured to meet your needs:

• HOLD_FOLDER: messages labeled as Junk will be moved to this IMAP folder after DAYS days. Messages in this folder will be fed to sa-learn as spam
• DAYS: number of days a message will remain labeled as “Junk” or sit in the HOLD_FOLDER before going to the next step
• JUNK: custom label set by the e-mail client to denote spam. Check ~/Mail/dovecot-keywords for the correct label position.

There are only two commands, but the syntax may be daunting, so let me walk you through what happens. First, we check HOLD_FOLDER for any messages last changed n DAYS ago. These are fed to sa-learn as spam and then deleted. A regular expression is used to ensure messages with a T status in the info field are not fed to sa-learn. “T” is another special indicator that means the message has been moved to another IMAP folder. These dangling messages will exist whenever you move them to a different folder (this includes deleting!) without compacting the folder. In Thunderbird that option is accessible by right-clicking on the mailbox in the left pane and selecting “Compact Folder“. Imagine if you improperly labeled a message as junk and moved it to HOLD_FOLDER. Shortly after realizing your mistake, you dragged the message out of HOLD_FOLDER back into your main mailbox. If the “T” flag wasn’t checked, then this message would (a) be fed to sa-learn as spam and (b) deleted from the mailbox.

After HOLD_FOLDER has been purged it’s time to bring in a new batch of messages labeled as “Junk”. The find command will search for all messages labeled with the JUNK flag which are older than DAYS days. Messages matching these criteria will be moved to HOLD_FOLDER… and the cycle repeats itself the next time the script is run.

You probably want to automate these commands, so setup a cronjob in the control panel under “Cronjob Manager” and paste the code to a file named relearn_spam.sh. Upload the file to your home directory and add a cronjob set to run the command “sh ~/relearn_spam.sh” at 0 0 * * 0 (every Sunday at midnight). And that’s how you create value between your e-mail client, Thunderbird in my example, and spam filtering.

Final thoughts: because you’re the one marking missed messages in Thunderbird, it’s a good idea to disable automatic tagging by Thunderbird. Visit Tools -> Account Settings -> <account name> -> Junk Settings and untick “Enable adaptive junk mail controls for this account“. Remember that you have a week after tagging a message as junk to remove it from the junk folder before it is fed to sa-learn as spam! Be sure to setup a set time like every Friday before you leave the office to scour over messages and remove anything improperly tagged as junk.

That wraps up the tip for this week. Who knows what’s in store next week, but I’m keeping my fingers crossed that I can continue the fantasy football theme.

The Web server, Apache, is scheduled for an upgrade from 2.2.4 to 2.2.6 on Saturday, September 8th between 1:00 AM - 1:15 AM EDT. This is a proactive upgrade to address several potential vulnerabilities. Upgrades on each server should take no longer than 2 minutes to complete.

1:15 AM Update: the maintenance window is now closed.

Perhaps it’s the shock of the passing of SysAdmin Magazine or maybe the onset of football season, but regardless which catalyst sparked it we need education. What is a better way of educating our beloved nerds who religiously follow each trite blog posting outlining a series of software updates? Why sharing some tips I’ve picked up along the way of course! Hopefully I can keep the flow of information coming to provide interesting content ad infinitum. An important disclaimer: most of these tip topics require shell access.

Actually, I’m not sure what this has to do with football season now that I think about it. Wait, I know! It leads into a very important discussion of using OpenSSL to encrypt sensitive data, like your pre-draft player rankings in football. Sometimes we foolishly join cutthroat leagues where first place is everything. Your opponents? They want to know your planned rosters, but with a little help from the openssl tool you can keep your personal data encrypted on the server and keep those preying eyes away from the number one pick.

openssl is the Swiss Army knife of OpenSSL used for all things encryption. Let’s first look at some of the commands offered:

Standard commands
asn1parse      ca             ciphers        crl            crl2pkcs7
dgst           dh             dhparam        dsa            dsaparam
enc            engine         errstr         gendh          gendsa
genrsa         nseq           ocsp           passwd         pkcs12
pkcs7          pkcs8          rand           req            rsa
rsautl         s_client       s_server       s_time         sess_id
smime          speed          spkac          verify         version
x509

Message Digest commands (see the `dgst' command for more details)
md2            md4            md5            rmd160         sha
sha1

Cipher commands (see the `enc' command for more details)
aes-128-cbc    aes-128-ecb    aes-192-cbc    aes-192-ecb    aes-256-cbc
aes-256-ecb    base64         bf             bf-cbc         bf-cfb
bf-ecb         bf-ofb         cast           cast-cbc       cast5-cbc
cast5-cfb      cast5-ecb      cast5-ofb      des            des-cbc
des-cfb        des-ecb        des-ede        des-ede-cbc    des-ede-cfb
des-ede-ofb    des-ede3       des-ede3-cbc   des-ede3-cfb   des-ede3-ofb
des-ofb        des3           desx           rc2            rc2-40-cbc
rc2-64-cbc     rc2-cbc        rc2-cfb        rc2-ecb        rc2-ofb
rc4            rc4-40

That’s a lot of stuff. We just need to know about enc to encrypt our plaintext file. There are a few other interesting commands to play around with. Usage instructions for all of the commands may be invoked by running openssl <command name> help [aside: an invalid third parameter will bring up usage information, so you could replace “help” with “dsfjkhfdjk” if you like]

• s_client: used to emulate an SSL HTTP request. Handy for verifying a SSL certificate on a Web site. Also provides a raw interface for sending arbitrary HTTP protocol commands like GET / HTTP/1.1 … Host: www.apisnetworks.com … *blank line*
  • Example: openssl s_client -quiet -showcerts -CAfile /usr/share/ssl/certs/ca-bundle.crt -connect apisnetworks.com:443
• genrsa/req/x509: generate a SSL key (genrsa), certificate signing request (req), and optionally self-sign the certificate (x509). CSRs are unnecessary if you intend on using a self-signed certificate. Self-signed certificates will display warning messages prior to accessing the site, because the certificates are not signed by a trusted authority like Verisign or Thawte.
  • Example: openssl req -newkey rsa:1024 -keyout server.key -out server.crt -x509 -nodes -days 365
• dgst: creates one-way hashes of data. Supports MD5/SHA-1 checksums of text and files. Think of this as a much more complex solution to using the md5sum/sha1sum commands for MD5 and SHA-1 checksums respectively.
  • Example: openssl dgst -md5 /dev/null

Finally we’ve reached the meat and potatoes, enc. enc will encode/decode data using a specified cipher and special key. Note that the cipher chosen and key used are important. Forgetting either parameter will render your file useless. Avoid the more exotic choices like “-aes-128-ecb”, “-cast5-ecb”, and so on. Stick with simple ciphers like “-rc4″, “-aes256″, and “-des”. Let’s say our text file contains the top 3 picks [note: if you’re scoping this entry out for recon on my potential picks, then this list is 100% accurate and you should draft these players ahead of me].

1. Joey Harrington
2. Ronnie Brown
3. LaMont Jordan

openssl -in /players.txt -out /players.enc -e -k mysecret -bf

Verify the command worked right:
[santa /]# cat players.enc
Salted__N©©‡ü†“+< V[bzM¦¯§GÕ¦Tݱ ®†äåiá–ÍÀÁŒèêÒÎewâCY¶èL3mÕÐÛXz™¯-ž7K

Success, now your picks are safe! If you omit a cipher (-bf in this example), then the data is passed through unencrypted. To decrypt your data, replace -e with -d:

[santa /]# openssl enc -in /players.enc -d -k mysecret -bf
1. Joey Harrington
2. Ronnie Brown
3. LaMont Jordan

Because the data in the file may represent non-representable text characters, it’s a good idea to encode the encrypted output in Base64 — or quadrosexagesimal as I like to call it — to ensure data won’t become corrupted (or corrupt your terminal screen) if viewed as if it were a plaintext document. Add -a to the list of parameters to the openssl command to enable Base64 encoding/decoding (depending upon whether encryption (-e) or decryption (-d) is used).

Finally, specifying the secret key on the commandline bears the problem of it appearing in your history. Not very furtive if someone has access to your account or your ~/.bash_history file, but there is an easy workaround. You can create a temporary file to house your secret key. Change -k <key> to -kfile <file> to instruct openssl to read the first line from the named file <file> as the encryption key.

Pretty neat, huh? Well, if not then stay tuned next week as we explore using multiple servers for distributed computing to calculate optimal roster arrangements to guarantee first place in an ultra-competitive fantasy football league… Or how to use ImageMagick’s set of utilities to decipher ultrasound maps of Giants Stadium to ensure that police won’t find the buried remains of the dearly missed first place coach.

If you would like to poke my brain and become the topic of discussion for one of these installments, then drop me an e-mail at msaladna@apisnetworks.com.

SpamAssassin’s rules used in determining spam/ham will be updated once a week every Sunday night beginning next week on September 9th.  Frequent rule updates should provide better adaptability to the constant mutations spam goes through every day.