Reuben Budiardja's Blog

Here's a scenario that just happened to my wife that should not. This is on Fedora 8 with KDE.

1. Open a document from email attachment (with Kmail), that opens in OpenOffice.


2. "Save As" the document so that it can be edited.


3. OpenOffice "Save As" dialog open with the default directory "/tmp/kde-username" because that is where Kmail put its attachment.


4. Name the file something else, and save.


5. Edit the file, saving regularly, then shutdown the computer when finish.


6. Next time computer boot up, the document is gone, potentially loosing hours of work

I know all the arguments blaming the user. As a technical person, regrettably that was my first reaction also. On second thought, for regular user, who can tell what /tmp is ? Regular user does not know that /tmp are cleaned every reboot. Furthermore, in a hurry, if one just want to save quickly so that it can be used the next time computer boots up, it's understandable that user makes the mistake to save the document to whatever default directory is presented by the dialog box, thinking that she can always re-open it from "Recent Document" menu.

This is not limited to Kmail or Openoffice, I just tried and it's the same with KPDF, Kghostview, etc. Firefox opening files in application also has similar problem.

What should be the general solutions for this ? Should this be the responsibility of the desktop environment project (ie. KDE, GNOME) from their "Save As" dialog rather than each individual apps ? I'm thinking of filling a bug report but then I'm not sure whom I should file this with.

I can think of some hacky band-aid solution to prevent document loss next time like a rotating backup of /tmp for the next two reboot or edit the boot up script to not delete /tmp, etc, but none of those is a good enough general solution.

Maybe it should be sometime like:

1. Default to $HOME directory for saving if file is opened from /tmp


2. Have a shortcut in the dialog to go to the directory where the document is opened from (ie. "/tmp/kde-username") for the case where one would actually
   just want to save a temporary file there. Probably have a "warning" and a "don't warn me again" or "do this automatically next time" preference.

Do you have any thoughts ?

With the proliferations of online services, multiple online accounts and identities can become hard to manage. Remembering multiple passwords is certainly not the solution, and using the same passwords for all your accounts is certainly insecure. To deal with that, I pick a middle-of-the-road approach, which is, -- as always --, a trade between security and convenience, but without sacrificing either one of them. I share how to do this in this post.

I categorize every online account into the following category: Secure account, Privacy account, Insecure account, and Throw-away account.

Secure account would be accounts you have on the site you trusted most that holds very valuable and private data. Examples of these are probably your bank online account, your credit card website, email/webmail, online stores that hold your credit card data, or any other financial related account. You know, or at least think, the companies that hold these accounts to be trust-worthy, and expect them to protect your account or identities. Transaction with these companies are done in secure manner, for example via SSL-encrypted website.

Privacy account would be a step less secure than the secure account. You mainly want to protect your privacy on these account, prevent unauthorized access and your online profile, but in the worst case scenario that these accounts get compromised, it won't be particularly devastating to you or incur financial damage, although it may cause some inconvenience. A lot of social networking site such as Facebook, Friendster, Linked-in, etc. would probably fall into this category. Transactions with sites for this type of account may not even be secure (i.e. not SSL-encrypted via HTTPS).

Insecure account is just that, an account which not need be secure. You just mainly need an account to identify who you are, a first and last defense to whatever data is "protected" by the account. You expect that compromise to this type of account is not a big deal, and can be fairly easily rectified. The sites holding this type of account does not necessarily protect the account in very secure manner, and mainly use the account for identification. The site may even tells you so. Example of these is mailing-list membership account, since most of them email your password information in plain-text, or any other online services that does not hold anything of big value or any privacy sensitive data.

A Throw-way account is obviously an account which you probably use only once or twice, or an anonymous-like account which you don't want to be easily linked back to you (i.e. you use fake real name, fake personal information, etc). I sometime need this to try out new interesting online service which I am not sure I want to use more permanently, or maybe to post question in some software-related forum that I only need it for that once, etc.

So, having defined all of those, I create at least 4 different passwords. At least two of them must be strong passwords, and it's best if the rest are also strong password, but it is less important. I use the strong passwords to protect the "Secure" and "Privacy" accounts, one for each category. So every account in the "Secure" category has the same password, and every account in the "Privacy" category has the same password. Yes, in this case, we assuming the level of security for each member of the account category are the same, but this is what we trade security for more convenience, and I think it is acceptable. This is the whole point of creating these account categories.

There are few more things that can be done to increase security. If you own a domain name, you probably can easily create multiple or unlimited email accounts for that domain name. A lot of accounts use your email address as the username. In this case you can create a specific username (i.e email address) for that site, probably something in the form of account_name@yourdomain.com. This adds complexity to your account and also probably reduce the amount of spam you have.

Another way to increase security is to use a an automatically generated password for each account. A program called SuperGenPass can help you with that. SuperGenPass generates password based on the website domain name that you log in into, and your password seed. So you can use the password you have created as the seed of the SuperGenPass password generator for each different account. This protects you that if one of your more secure account gets compromised, it's not necessarily that all your secure accounts are compromised; at least it adds another layer of security.

Still you probably manage to have more than four passwords. You can use password manager software to help you manage theses. For example, Mozilla Firefox has one built in to the browser. If you do use this, it's a good idea to set a master password for it with strong password. That way, in the case that your computer gets compromised, at least there is another layer of defense protecting your password, which may gives you the chance to do some damage control.

Download fileDupFindr

fileDupFindr is a small program to find file duplicates, as the name implies, that I wrote over the holiday. It is written in C, and has been tested mainly in Linux, but should work with any Unix-based OS, Mac, and even Windows since it is such a simple C program. fileDupFindr recursively traverse the given directory path and calculate the hash value (sha1sum message digest) of the file. At the end it compares these values to find the files that are duplicates.

I wrote this as a chance for me to get familiar with SQLite C API, as it uses SQLite to store data in memory. I am really happy with SQLite. It is fast, lean and mean SQL database, and the API also quite pleasant and easy to use. The biggest advantage is that since it is a SQL engine, and I am quite familiar with SQL, I don't need to think about creating my own data structure. Once I got the data into the SQL table, I can manipulate the data anyway I want to. SQL was designed especially for that kind of data manipulation, so it is quite nice to use. I already have in mind several of other projects that I am going to use SQLite for and get rid of my "proprietary" data format.

I also use OpenSSLcrypto library to calculate the sha1sum of the file. This is done using OpenSSL's EVP library, which is quite nice to use. To read the file, I specify fixed buffer size to read the file per that chunk size, otherwise reading a big file would be a problem if your system does not have enough memory to hold the size of the big file at once. EVP library has a nice API to read this chunk-size data and then just update the data until all the content of the big file is read. One peculiarity I noticed is that, at first I thought that increasing the buffer size (or chunk size) would speed up the program if you have a lot of big files, since it would take less iteration to read one file. As it turns out, there is a turn-around point where specifying larger buffer size does not speed up the program, and in fact slows down the program. I am not quite sure if the problem is in the reading the file content itself or with the EVP library, and have not had a chance to look at this further. I will give update when I do.

So that's it, consider it a small Christmas present from me if you find this program useful .

Merry Christmas to all, let there be peace on this earth which badly needs it.

Sometimes we are using a publicly available Wifi hot spots and would like a better privacy when browsing the internet. Although our credit-card or bank account website are probably using secure connection, other websites are not and we simply would like to have more privacy. One way to do it is by setting up your own proxy server and using it as a private proxy.

However using our own proxy server still does not increase the privacy / security of our connection over the exposed wireless link, unless we use encryption. Encryption in this case is easily accomplished by using SSH tunneling. The benefits of this is two prongs. First, we have SSL level encryption, second, we keep our proxy server private by off-loading the authentication burden to the SSH server. In this entry I explain how to do it.

I assume that we are using a fairly modern linux distribution for our web proxy and SSH server. I also assume that we have SSH access to our machine set up securely. Most major linux distribution include Apache 2 web server and its proxy module in the distribution. It's better to use that than compiling Apache yourself, unless you know what you are doing. Assuming all that, then it is really easy to set up our proxy server.

First, we need to enable the web server to be a proxy server. The relevant configuration in

httpd.conf

file is as follow

LoadModule proxy_module modules/mod_proxy.so
#
# Proxy Server directives. Uncomment the following lines to
# enable the proxy server:
#
<IfModule mod_proxy.c>
ProxyRequests On
#
<Proxy *>
Order deny,allow
Deny from all
Allow from 127.0.0.1
</Proxy>
</IfModule>
# End of proxy directives.

The first line loads the proxy module to the web server. Proxy directives allow you specify by IP address the request that it will serve. In this case, we deny all request except request from

127.0.0.1

, which is

localhost

. This is how we keep your proxy server private, i.e. not an open proxy.

Now to use our proxy server from a different machine, -- let's call this is the laptop with wireless access --, we first have to connect to the server via SSH tunneling. This is both the encryption and authentication part. The simple proxy server cannot authenticate us, and hence only allows connection from

127.0.0.1

. The authentication part comes from the fact that we have to connect via SSH first to the proxy machine before we can use the proxy forwarding. To have SSH tunnel, simply do

$> ssh -L 3000:localhost:80 myproxyserver.myisp.net

This means, port 3000 in my laptop actually listen to port 80 on the proxy server via SSH tunneling, i.e. it is an encrypted tunnel. The port 3000 is random. We can use any port number that is unused in the laptop. Port 80 is the port where the web server binds to in the proxy server machine (of course one can set up the Apache to binds to different port in

httpd.conf

).

Now that we have tunneling set up to our proxy server, all we need to do is to configure web browser to use this. This differs slightly for different web browsers, but as an example, in Firefox 2, this is done via

Preference --> General tab --> Connection Settings

. Here we set

Pick "Manual Proxy Configuration:"
HTTP Proxy: localhost
Port: 3000
Use this proxy for all protocols: check

Now we can start browsing securely via this SSL encrypted tunnel to our proxy server. If we check the web server log in our proxy server machine, we should see that our request from the laptop's web browser is being forwarded by the proxy server. Also noticed that from the web server point of view, our request comes from

127.0.0.1

.

I have been using Sendmail as a personal mail server on my own domain. To send email, I use Sendmail's Smarthost to relay the mails through my ISP SMTP server. This is to avoid being flagged as "spam" by some spam filter since I am on dynamic IP.

Recently, my SMTP blocks port 25, which is the default port uses to relay mails, and require us to use Submission port 587. Some people thing this is a good thing (?) and has becoming standard with ISPs. (Whether you agree or not is beside the point of this post).

So anyway, I have to change my Sendmail configuration to do this. This post is a documentation / recipes on what I did. To change the smarthost relaying to use port 587, have the following in your sendmail.mc:

define(`SMART_HOST',`smtp.myisp.net')dnl
define(`RELAY_MAILER_ARGS', `TCP $h 587')
define(`ESMTP_MAILER_ARGS', `TCP $h 587')
FEATURE(`authinfo',`Hash -o /etc/mail/authinfo.db')dnl

The last line is to have sendmail authenticate as client to your ISP SMTP server. You also need to create your credential file, in this case

/etc/mail/authinfo.db

. First create

/etc/mail/authinfo

; in that file I have:

AuthInfo:ispdomain.net "U:my_username" "P:my_password" "M:PLAIN"
AuthInfo: "U:my_username" "P:my_password" "M:PLAIN"

In this case, I use the authentication mechanism

PLAIN

. You may need different authentication mechanism, depending on your ISP. Now generate the

authinfo.db

file by doing:

chmod 600 /etc/mail/authinfo
makemap hash /etc/mail/authinfo < /etc/mail/authinfo

The first line is to have your plain text authinfo file more secure by making it readable to root only. As usual, rebuild

sendmail.cf

and restart sendmail.

I have a collection of TrueType fonts that I would like to add to my Fedora 7 installation. Installing (TrueType) fonts on recent version of Fedora turns out to be quite easy. To install the font system wide, all you need to do is put it in the fonts in a directory. To be consistent, create a new directory under "/usr/share/fonts". For example, I created directory:

mkdir /usr/share/fonts/handwritten

to store a collection of handwritten-like font. To make sure that the fonts is accessible to the world, do

chmod 775 -R /usr/share/fonts/handwritten

Then all needs to be done is run "fc-cache" command on that directory, e.g

cd /usr/share/fonts
fc-cache handwritten

And voila! the new fonts appear on all applications such as Gimp, openoffice, koffice, etc.

Over the past several months I have been working with SILO library to write the output of our astrophysics simulation code. The primary reason is so that we can visualize the code output directly with VisIt, since it support SILO format natively. SILO is written in C, with some wrappers to be callable from Fortran. Unfortunately, while working with the SILO API, I sometime found some error and inconsistency in its manual and some gotchas that made me look into the its source code to figure out the problem. I couldn't find any publicly accessible bug database or its maintainer email, so my plan is just to document those problems here in for my own notes and in case it may be of some helps to someone else. I mostly uses the Fortran interface (since our code is in Fortran 95), so that's where most of these notes would apply. I will update this entry as necessary.

1. dbputca: Manual and API are inconsistent
The manual have

integer * nvalues

as the ninth argument to the function. This is a mistake. The API does not have this (plus

nvalues

is redundant since it can be inferred from

nelems

and elengths). Simply remove

nvalues

from the argument list when calling the function.

2. dbgetca: Manual and API are inconsistent
The documentation mentions

character*(*) enames

and

integer * lenames

as the fourth and fifth argument to the function. This should be flipped:

lenames

should be the fourth argument, and

enames

should be the fifth argument. Otherwise, you get Segmentation Fault. However, this makes it inconsistent with the function counterpart

dbputca

. Also note that one should pass the variable

datatype

, which would be used as a returned value by the function. The manual is somewhat ambiguous leading me to think that I should pass the predefined SILO datatype e.g.

DB_DOUBLE

or

DB_FLOAT

. Segmentation fault would occur also in this case.

Download gprofviz

This is a web-based tool (requires PHP with GD) to represent output of a flat profile of a code. I developed this tool to do some simple profiling on our astrophysics simulation code. What I needed to do was to see how the code scale on different / larger number of processors (i.e. MPI tasks).

The idea of the tool is simple. First, I run the code on a uniprocessor (after linking using -pg to generate profiling info gmon.out). Then, I output the flat graph profile of the code. Depending on your platform, this may be done by using "gprof" command and feeding the necessary argument. If you put the flat graph profile on the appropriate directory in gprofviz (see sampleApp1 inside the distribution for example), gprofviz draw color boxes representing subroutines / functions whose width correspond to the percentage of time spent inside that subroutines. gprofviz then uses this first flat profile as its standard, including the ordering of the subroutines on the flat profile, which should be from the highest time percentage to the lowest.

Now I can run the code again with different numbers of processors, and similarly generate flat graph profile for each set of run on different number of processors, and then feed those to gprofviz to plot. gprofviz draw boxes on these flat profile using the ordering found on the first flat profile (the one from uniprocessor) as the standard.

The key is this: in an ideal code that scale perfectly, the size of boxes on larger processor count should be similar / the same to the ones from uniprocessor. Furthermore, in an ideal code the boxes should be ordered from the widest to the smallest. If these are not fulfilled, then there is something we need to look at about the scaling of the code. Of course, there will be some fluctuation since this experiment is not ideal, so it's a judgment call to decide which problem is real or just artifact of the experiment. It should be pretty obvious too if the code does not scale well. You should see some subroutine dominates in when the code run with larger number of processor, i.e. some box has larger size on the place where they are not supposed to be.

Using this code I was able to quickly determines which of my subroutines did not scale well, and took a closer look into the subroutine specifically. The point is, if your code is to scale with larger processor number, each of its subroutine needs to scale as well. If not, then you need to be able to justify why. In some cases the subroutine may not scale due to the code design, or the fact that some problem are not trivially completely parallelizable. And that is probably fine, as long as you know why and that it's an overhead that you pay in going to parallel.

Download gprofviz

Here is some screenshot of gprofviz in action.

Suppose you have more than one email addresses that coming to same email server. For example you buy your own domain name, and you want to have address at yourname@newdomain.com, but you don't want to set up your own mail server. A lot of domain registrants also usually provide email forwarding service, so you can set up to foward yourname@newdomain.com to another email address, which you downloaded to an email client via POP or IMAP. An example is to use Google's gmail,

Now your problem is that you can receive email at yourname@newdomain.com, which you forward to your gmail account so that you don't have to set up your own mail servrer, but you cannot reply with "From: yourname@newdomain.com". That is simply not cool; unless you use an email client capable of multiple identities (that is why I pick gmail as example because it lets you download your email using POP, while other popular free service like Yahoo's Mail does not, not the free account, at least.)

Mozilla Thunderbird has the abilities to set up multiple identities. So you can set up to download POP from gmail, set up multiple identities (eg. one for your gmail identity, one for your newdomain.com identity), set a filter to put the email with certain "To: " header into a certain folder, and you're set. Or so I thought, until I found out that this is so prone to error. Which bring us to the next problem.

The problem is that there is no way to associate an identity with a folder in Thunderbird. Therefore if you have multiple identities (multiple "From: " email addressed), you have to make sure that you select the correct identity when sending. This way, you are bound to make a mistake at some point, and without realizing it, you could be giving away or using your other email address for someone or something you do not intend to. This is not the the case with KDE's Kmail, for example, which allow you to set the properties for each email folder and associate an identity different than the default with that folder. That way you can check your email for that account, and when you create / compose a new message while you are still browsing inside that folder, your new compose windows automatically uses the "From: " identity associated with that folder (which you can change if you are so incline).

So here is a workaround for Thunderbird, in a step by step recipes. The idea is to create a new fake "Account", and use that account to hold your incoming mail that comes to you with a certain "To: " header, eventhough you already have an account that does the actual polling from the same mail server.

1. Go to File --> New --> Account --> Email Account, click "Next"
2. Put Name: ie. "John Doe", Email address, eg.: "john@doe.com",
3. Type server: POP, Incoming server, eg.: "mail.doe.com",
4. Uncheck "Use Global Inbox",
5. Incoming User Name, eg.: john, Outoing user name: make it blank
6. Account Name, eg.: "Doe Bussiness",
7. Uncheck "Download Messages Now", FINISH

Now go to Edit --> Account Settings
1. Click on "Server Settings" right under "Doe Bussiness"
2. Uncheck everything under "Server Settings"

So what we did is tricking Thunderbird. There is actually no account with the server 'mail.doe.com'. This tricks is so that you can have a new identity (From: address) as "John Doe " and Inbox, outbox, draft, automatically associated with that address).

Now, create filter for incoming messages to that account
1. Go to Tools --> Message Filters, click New
2. Set up as:
check "Match any of the following"
"To or CC" Contains @doe.com,
Perform These Actions:
Move Message To: "Doe Bussiness" -> Inbox

Now when you check mail incoming messages for "john@doe.com" should automatically go to
Inbox for "Doe Bussiness" account. When you are in that Inbox, and click "Write", you should see that your identity is "From: "John Doe "". That's one way to get around the fact that there is no Identity to folder association in Thunderbird.

It's been a while since I wrote anything at all for this blog. One of the major reason is, I've been busy working on our project for the last several month. It's a new mashup that my friends and I have been doing together. And now it's here for public consumtion. It's called: Buzzoo.

What is Buzzoo ? Well, go ahead and check out the site first . Then you can also look at our manifesto.

I certainly have been very much enjoying working on it, and even better, using it. And eventhough it's launched, we are still hard at work improving it with many major plans in the future. In the meantime, I hope to have more time to update this blog more regularly.

Often time I have a group of people that I constantly exchanging emails with. This group is sometimes informal enough, fluid enough (a changing memberships or only temporary), or small enough to make it not worth the trouble to create a mailing-list for, but can benefit from having the most important feature of a mailing-list: the easyness to distribute email messages to its members. Sometimes the group is such that using a publicly hosted mailing list like Yahoo! group is not appropriate . Sometimes it's just not tech-savvy enough (no offense intended) that the process of registering to a mailing-list would become a hurdle, and it would be so much easies if only one person takes care of registering them all.

These are the cases that I deal with as a (self-)volunter sysadmin in small organizations. So instead of going through the trouble setting up Mailman/Mojordomo run lists, I choose a liberal use of /etc/aliases, formail, and procmail to set up a small scale mailing-list like system. Notice that I said "small organizations", plural, so setting up a Mailman on a single system would be inappropriate (different domains, machines, policies, etc). The following are quick notes on how I set the system up.

As I mentioned in my previous post, we can use an alias in virtual user table. So even if we have several virtual hosts on the mail server, this still works. So suppose we're creating this distribution list called: managers@company1.com. On /etc/mail/virtusertable, we should have:

managers@company1.com managers-company1

"managers-company1" is an alias, so define it at /etc/aliases for the real email addresses which the message should go to:

managers-company1: harry@company1.com, sally@company1.com, harry-home@homeaddress.net, bob@company1.com

Now we are pretty much done, all email sent to the virtual address "managers@company1.com" gets distributed to the real addresses. The problem, if the one of the people who gets the email reply to the email, the reply address would be the original person who sent the original message, not the "list address." This is because the email does not have the appropriate header that tells the mail client program whom to reply to. So here is where formail and procmail comes into play.

Header Munging with Formail
Formail is a linux mail re-formatter program, and can do mail header generation, munging, and extraction. To tell the mail client program whom to reply, we need to add either "Reply-To" header or "List-Reply" header. There has been arguments for and against "Reply-To" header which you can find easily on the web, but I won't comment on them here. I'll simply leave that decision to you. In my case, I choose to use the Reply-To header because I consider it appropriate. If you disagree, you can always use List-Reply header instead, since most modern mail clients program support it.

Anyway, we need to pass the message to formail before distributing it to the real email addresses. We do this by using procmail. So we call procmail, like before, from /etc/aliases. The procmail recipe will then call formail, and then distribute the message to the real addresses. So instead of the above, /etc/aliases should looks like:

managers-company1:  | procmail-managers-company1

Of course, we put the executable script "procmail-managers-company1" under /etc/smrsh so that sendmail can execute it using the restricted "smrsh" shell. On that file, we have the actual call to procmail with the correct procmailrc as argument, as follows:

exec procmail /etc/procmailrc.d/managers-company1-dist

Now on the procmailrc file is where we pass the filtered message to formail, do the header munging with formail, then distribute it to the real email addresses using procmail forwarding comand. So the recipes look like:

:0 fhw
| /usr/bin/formail -I "Reply-To: managers@company1.com"
:0 c
! harry@company1.com, sally@company1.com, harry-home@homeaddress.net,bob@company1.com

So that's it. Now you have a small-scale email distribution system with mailing-like feature using several simple scripts and readily available linux tools.

I am very protective of my personal email account. I don't usually want to give it away for anything other than to someone that I know personally. I am doing this to keep it from getting spamed, and it has been largely successful. I should probably have a server-based spam filter like spamassasin, and a probably even a virus scanner. But since I have my own mail server at home, setting up a spam filter feels like a pain and a big hassle. Plus mostly we runs linux (Fedora distro) anyway so we are less worry about viruses. Even when we use Windows, we use sane email program; my wife and I are also very cautius about opening any attachment (and we open them on linux if we are a little bit unsure). So as you can see, we hope that we can just use common sense to fight againts spams and viruses. But recently a very small amount of spams have managed to get into my personal mailbox, so I may just have to bit the bullet at some point and install a spam filter anyway, when the numbers start to get annoying.

Anyhow, one of the advantageous of having one's own mail server is that one can easily create (and remove) "pseudo" mail accounts. So that's what my mode of practice has been. For example, for creating account at Amazon, I would create a pseudo account something like "my-amazon-email@mydomain.com". The same thing for my bank accounts, credit card accounts, etc, I would have a "personalized" account for each and every single one of them. Sometimes I create a single account for registering at several different sites (ie. Slashdot, Digg), so it all depends on my mood and my discretion at the moment. I also create several throw-away accounts like "myself001, myself002, mywife001, etc" which we can use when we're pressed to give out email address to uncertain entity while travelling. This is done using Sendmail virtual user table for my domain which then route the email message to a valid local user.

The advantage of doing this is at least two fold. First, if the "personalized" email account get spammed, I can just remove them and create a new one easily. Secondly, I know which what service / website I registered that email accounts for, so if gets spammed, I could justify having a very strong suspicion that the company either intentionally spamming me, or sell / give out my email account to other companies / services. Then I will just have to make sure that I won't have anymore bussinesses with it, infact I would go so far as discouraging any people that I know that are considering doing bussiness with the company / website / service.

So this practice has been working well for me, except for one loophole. Having my own domain, I need to put an email address for domain registration, which is available publicly via Whois lookup. So this address really becomes the source of nearly all spams coming into my mailbox, other than the spam attempts to find random valid addresses on my domain (ie. "accounting, billing, sales, ..."). For all of that, I have a catch-all trap in my virtual user table that goes to an alias called "spam", which then re-route the messages to /dev/null.

The email account for domain registration, -- let's call that "dom_reg@mydomain.com"--, is routed directly to my local user from the virtual user table. So I've been trying to block this using several procmail recipes, but somehow some spam messages are clever enough to get though. My procmail recipes for this account basically say "if the email is to dom_reg AND from My Registrar, deliver to Inbox, otherwise send to /dev/null." But the spams come in like this, the "To: " header would make it seems that it's addressed to "accounting@mydomain.org", yet somehow it's sent to my domain registration email account. So the recipes never catch it! I am still not sure how this happens, but it does. The problem is, I have to filter on the "To:" header also in the recipes, otherwise the recipes will catch all messages send to my personal email account. If only I could directly invoke these recipes when the message comes, -- ie. go a level higher on when to filter these messages --, I'd be just fine.

But I could ! It just occured to me, that I could invoke procmail directly from the aliases file. So what I needed to do is to create alias for this dom_reg@mydomain.com and changed the virtual user table so that mail goes to this address is routed to the alias. So here is what I did.

First created a directory on the system where specific promail recipes for this situation would go, I called it /etc/procmailrc.d (following Redhat/Fedora convention for directory containing configurations). Then I created recipe file for this situation, basically it says "If the mail is from My Registrar, accept it, otherwise, throw it away." Now the problem is how to call procmail from /etc/aliases.

Sendmail uses smrsh to invoke programs, which is a restricted shell for security. It can only executes programs that are in /etc/smrsh directory (or symbolically linked from there). So I could create a symlink to /usr/bin/procmail in /etc/smrsh, but that would be the best way since procmail then can execute any program. So my solution is to create yet another wrapper for procmail under /etc/smrsh, which call procmail with the correct procmailrc as argument. So I have the following files:
/etc/smrsh/procmail-dom_reg:

exec procmail /etc/procmailrc.d/dom_reg

OK, so now in the /etc/aliases, I have the line:

dom_reg: |promail-dom_reg

And for completeness, in my virtual user table files, which is /etc/mail/virtusertable, I have the following:

dom_reg@mydomain.com dom_reg

and /etc/procmailrc.d/dom_reg contains something like:

:0
* ^From:.*godaddy\.com
! my_real_email@mydomain.org

So there you have it, a creative way of using virtual user table, aliases, and procmail. All this trouble is actually to fight spams that are coming to dom_reg account, and to catch email from my registrar which probably only comes once a year, if at all, to remind me when my domain registration is about to expire . Now I'm starting to wonder if installing a real spam filtering software would actually be easier.

It seems that in this day and age, everyone has a blog. So I decided to give this a try. Well, I have never been much of a writer. I did write some "technical" essays in the past, and even some philosophical essays, but most people would probably consider those boring and dry. Those are not the kind of writing I am talking about. I am talking more of the engaging writing that lots of people suddenly seem to have with the explosion of personal blogs and networking sites on the internet. Well, I guess I just want to try stretching myself further and see if I can do some of that too.

"So what's this all about ?" you ask. Well, that's my question too. What is this blogging all about ? What makes it so popular and addictive? People say you have to experience something to know it, so this is it. My attempt to experience blogism. I'm not sure yet what's gonna be here, but I do sometime have random thoughts, random ideas, things that I found out. The problem is, I never really tried to organize it or put it in writing. So I forget most of them, which probably is unfortunate. So this blog would be me thinking out loud, which could range from technical/computing stuffs, to science, to philosphy, to anything I might find amusing. Or it could be a way for me to generate new ideas.

So read away....