About this series

The typical UNIX® administrator has a key range of utilities, tricks, and systems he or she uses regularly to aid in the process of administration. There are key utilities, command-line chains, and scripts that are used to simplify different processes. Some of these tools come with the operating system, but a majority of the tricks come through years of experience and a desire to ease the system administrator's life. The focus of this series is on getting the most from the available tools across a range of different UNIX environments, including methods of simplifying administration in a heterogeneous environment.

Examining e-mail logs

The logs generated by the different e-mail processes can contain a lot of useful information. What information is contained in the logs depends largely on the mail system you are using (sendmail, postfix, qmail, and so forth), but some examples of the information that you can extract include:

• E-mail rates and quantities
• Per-user e-mail rates
• Common hosts and domains sending and receiving e-mail
• Spam and virus quantities and filtering

Examining the logs can give you valuable information about how e-mail is used in your organization. Parsing the logs can be a complicated process, and the quality of the results largely depend on the format of the log and the complexity involved in parsing the file for information. For example, if you look at the log produced by the postfix mail transfer agent (MTA), you can see that the information for a single message is spread over a number of lines (see Listing 1).

                
Nov 17 03:17:34 narcissus postfix/smtpd[14281]: connect from localhost[127.0.0.1]
Nov 17 03:17:34 narcissus postfix/smtpd[14281]: 4F4CB1109404: 
  client=localhost[127.0.0.1]
Nov 17 03:17:34 narcissus postfix/cleanup[14278]: 4F4CB1109404:
  message-id=<Pine.SOC.4.64.0711162015280.16833@logical.logical-approach.com>
Nov 17 03:17:34 narcissus postfix/qmgr[104]: 4F4CB1109404: 
from=<zfs-discuss-bounces@opensolaris.org>, size=7632, nrcpt=1 (queue active)
Nov 17 03:17:34 narcissus postfix/smtpd[14281]: disconnect from localhost[127.0.0.1]
Nov 17 03:17:34 narcissus postfix/smtp[14279]: DBA5B11093FD: 
to=<dev@gendarme.example.com>, relay=127.0.0.1[127.0.0.1], delay=11, 
  status=sent (250 2.6.0 Ok, i
d=08640-07, from MTA([127.0.0.1]:10025): 250 Ok: queued as 4F4CB1109404)
Nov 17 03:17:34 narcissus postfix/qmgr[104]: DBA5B11093FD: removed
Nov 17 03:17:34 narcissus postfix/pipe[14283]: 4F4CB1109404: 
  to=<dev@gendarme.example.com>, relay=cyrus, delay=0, 
  status=sent (gendarme.example.com)
Nov 17 03:17:34 narcissus postfix/qmgr[104]: 4F4CB1109404: removed
Nov 17 03:20:07 narcissus postfix/smtpd[14355]: 
  connect from narcissus.example.com[192.168.0.110]
Nov 17 03:20:07 narcissus postfix/smtpd[14355]: 
  disconnect from narcissus.example.com[192.168.0.110]
Nov 17 03:20:07 narcissus postfix/smtpd[14355]: 
  connect from narcissus.example.com[192.168.0.110]
Nov 17 03:20:07 narcissus postfix/smtpd[14355]: 
  disconnect from narcissus.example.com[192.168.0.110]
Nov 17 03:23:16 narcissus postfix/smtpd[14410]: 
  connect from f048226119.adsl.alicedsl.de[78.48.226.119]
Nov 17 03:23:17 narcissus postfix/smtpd[14410]: 6CAAE1109461:
  client=f048226119.adsl.alicedsl.de[78.48.226.119]
Nov 17 03:23:17 narcissus postfix/cleanup[14411]: 6CAAE1109461:
  message-id=<000901c828c9$037c1e48$b9cc3eb7@ggpxddd>
Nov 17 03:23:17 narcissus postfix/qmgr[104]: 6CAAE1109461: 
  from=<maxwell@research.nokia.com>, size=2051, nrcpt=1 (queue active)
Nov 17 03:23:18 narcissus postfix/smtpd[14410]: 
  disconnect from f048226119.adsl.alicedsl.de[78.48.226.119]
Nov 17 03:23:30 narcissus postfix/smtpd[14414]: connect from localhost[127.0.0.1]
Nov 17 03:23:30 narcissus postfix/smtpd[14414]: 
  62E941109473: client=localhost[127.0.0.1]
Nov 17 03:23:30 narcissus postfix/cleanup[14411]: 62E941109473:
  message-id=<000901c828c9$037c1e48$b9cc3eb7@ggpxddd>
Nov 17 03:23:30 narcissus postfix/qmgr[104]: 62E941109473: 
  from=<>, size=3220, nrcpt=1 (queue active)
Nov 17 03:23:30 narcissus postfix/smtpd[14414]: 
  disconnect from localhost[127.0.0.1]

Fortunately, you can identify the process of a single message through the system by using the unique reference number that each e-mail is given. For example, Listing 2 shows an e-mail with the reference number 4F4CB1109404, which you can use to pull out relevant information to determine what to extract.

                
Nov 17 03:17:34 narcissus postfix/smtpd[14281]: 4F4CB1109404: 
  client=localhost[127.0.0.1]
Nov 17 03:17:34 narcissus postfix/cleanup[14278]: 4F4CB1109404:
  message-id=<Pine.SOC.4.64.0711162015280.16833@logical.logical-approach.com>
Nov 17 03:17:34 narcissus postfix/qmgr[104]: 4F4CB1109404: 
  from=<zfs-discuss-bounces@opensolaris.org>, size=7632, nrcpt=1 (queue active)
Nov 17 03:17:34 narcissus postfix/pipe[14283]: 4F4CB1109404: 
  to=<dev@gendarme.example.com>, relay=cyrus, delay=0, status=sent 
  (gendarme.example.com)
Nov 17 03:17:34 narcissus postfix/qmgr[104]: 4F4CB1109404: removed

From the extract, you can see the different types of information that you can remove from the logs, such as:

• Date and time
• Sender
• Recipient
• Message size
• Message count

By parsing the log file contents, you can create some interesting statistics on combinations of these different elements to gain a better idea of how e-mail is being used.

Parsing the log file for information

To parse the contents, you need to be able to identify each e-mail individually. This is possible because the MTA embeds a unique ID with each e-mail, which is often inserted into the log file output. For example, in this line:

Nov 17 03:17:34 narcissus postfix/pipe[14283]:
4F4CB1109404: to=<dev@gendarme.example.com>, \
relay=cyrus, delay=0, status=sent (gendarme.example.com)

the unique ID is the hex value 4F4CB1109404, and you can also determine from this line the address of the recipient. The sender of this e-mail can be found in another line with the same embedded ID:

Nov 17 03:17:34 narcissus postfix/qmgr[104]:
4F4CB1109404: from=\
<zfs-discuss-bounces@opensolaris.org>, size=7632, nrcpt=1 (queue active)

The information is not always sequential, as the MTA might be handling multiple e-mails at the same time, and the information all gets written to the log as different parts of the process are completed.

You can also see from the line above the total size of the e-mail (7632 bytes) and the number of recipients (one).

Listing 3 shows a Perl script that collates the information and then outputs some summary statistics of the number of e-mails and their total size.

                
#!/usr/bin/perl
#
# Script to extract email statistics from log files

# Time::ParseDate will be used parse the time into an epoch
# value, and then DateTime can be used to reformat the date
# again

use Time::ParseDate;
use DateTime;

# Parse the first file on the command line

open(MAIL,$ARGV[0]) or die "Couldn't open $ARGV[0]: $!\n";

# Create a structure to hold the stats

my $mails = {};

# Parse each line of the file

while(<MAIL>)
{
    chomp;
    my $mailid = 0;

# Look for the 12 digit hex mail ID

    if (m/: ([A-Z0-9]{12}):/)
    {
        $mailid = $1;
    }

# Extract the date and parse it into an Epoch value

    if (m/(\S+ \d+ \d{2}:\d{2}:\d{2}) .*? $mailid/)
    {
        $mails->{$mailid}->{date} = parsedate($1);
    }

# Extract the sender address and email size

    if (m/$mailid: from=<(.*?)>, size=(\d+),/)
    {
        $mails->{$mailid}->{from} = $1;
        $mails->{$mailid}->{size} = $2;
    }

# Extract the recipient

    if (m/$mailid: to=<(.*?)>/)
    {
        $mails->{$mailid}->{to} = $1;
    }
}

close(MAIL);

# Compile together the stats by parsing the formatted
# information into another summary structure

my $mailstats = {};

foreach my $mailid (keys %{$mails})
{

# Don't create a summary entry if we don't have enough information
# (sender/recipient is empty)

    if (!defined($mails->{$mailid}->{to}) ||
        !defined($mails->{$mailid}->{from}) ||
        $mails->{$mailid}->{to} !~ m/[a-z]/ ||
        $mails->{$mailid}->{from} !~ m/[a-z]/)
    {
        next;
    }
# Count the number of emails to each recipient
    $mailstats->{$mails->{$mailid}->{to}}->{count}++;

# Sum up the email size to each recipient
    $mailstats->{$mails->{$mailid}->{to}}->{size} +=
        $mails->{$mailid}->{size};

# Count the number of emails from each sender
    $mailstats->{$mails->{$mailid}->{from}}->{count}++;

# Sum up the email size from each sender
    $mailstats->{$mails->{$mailid}->{from}}->{size} +=
        $mails->{$mailid}->{size};

# Sum up the same information, but organized on a date by date basis
    if (defined($mails->{$mailid}->{date}))
    {
        my $dt = DateTime->from_epoch(
            epoch => $mails->{$mailid}->{date})->ymd('');
        my $mailto = $mails->{$mailid}->{to};
        my $mailfrom = $mails->{$mailid}->{from};

        $mailstats->{$mailto}->{_date}->{$dt}->{count}++;
    $mailstats->{$mailto}->{_date}->{$dt}->{size} +=
            $mails->{$mailid}->{size};

        $mailstats->{$mailfrom}->{_date}->{$dt}->{count}++;
    $mailstats->{$mailfrom}->{_date}->{$dt}->{size} +=
            $mails->{$mailid}->{size};
    }
}

# Dump out the information show mail counts and mail sizes
# on a mail address basis

foreach my $address (sort keys %{$mailstats})
{
# Only show information    from email addresses that are    
# local
    if ($address =~ m/@.*example\.com$/)
    {
        printf('%-40s %5d %9d',
               $address,
               $mailstats->{$address}->{count},
               $mailstats->{$address}->{size});
    print("\n");
    }
}

Running the script on a sample log file produces some statistics showing the mail counts and sizes for the domain specified (see Listing 4). The actual information that you print is significantly smaller than the amount of information you could produce. The statistics compiled can also output the information on a day-by-day basis, and that could help to indicate mail counts for each day so that you can get an idea of the level of load on the mail server.

                
023649@gendarme.example.com                    5      8922
admin@gendarme.example.com                     5     13141
answersquad@gendarme.example.com              50    348712
buy@gendarme.example.com                      79    806097
buy@example.com                                2      2911
dev@gendarme.example.com                     165   1010980
dev@example.com                                8     94430
finance@gendarme.example.com                   4     14493
flummox@gendarme.example.com                 203    858775
klhxs@example.com                              4      8080
dj@gendarme.example.com                       96    703754
dj@example.com                                 2      2063
mcwhoever@gendarme.example.com                 7    137185
mlists@gendarme.example.com                   38    473165
play@gendarme.example.com                     26    155220
postmaster@gendarme.example.com                5     15561
fhf@gendarme.example.com                     101    836863
fhffilter@gendarme.example.com                14    225081
spam@gendarme.example.com                     49    349750
tmbg-org-dj@gendarme.example.com              16    126144
ybxmbjw@gendarme.example.com                   1      1342

You can see from this example data that certain users are receiving large amounts of mail while others are comparatively light users.

In this case, the information tells you that the users receiving large amounts of mail probably merit closer attention to determine whether they are using their e-mail effectively.

If you were using a single mail server that you knew was reaching an overload point, you might consider splitting out the users so that a small number of heavy users are moved to a single server, and the users with "lighter" usage are placed on to another server to split the load effectively.

For now, let's use the information as a guide to look at some of the heavier users more closely and see how they are actually storing and organizing their e-mail.

Mailbox storage formats

One of the more extensive (and possibly controversial) methods for monitoring your mail usage is to look at how individual users are using and examining their e-mail. The problem with this approach is that some users see such examination as an intrusion, and others feel that how they organize and archive their e-mail is up to them.

The reality is that knowing how your users are organizing their e-mail can have an impact on performance, backup strategies for e-mail, and capacity planning by enabling you to determine which parts of the system are being used the most.

Actually, reading the e-mail of individuals is a bad idea, but you can still glean a lot of information from mailboxes of users by using fairly simple techniques that do not require you to look at individual messages. Also bear in mind that the e-mail solution that you are using also affects the information that can be gleaned.

Most modern e-mail solutions use the Internet Mail Access Protocol (IMAP) system for storing e-mail. Here the e-mail is stored on the server and the client accesses the e-mail folder to read the contents. This system allows different clients to connect to the server and access the information, which is an advantage. Because all the e-mail is on a single server, backups and access to e-mail while traveling (either directly or from a hotel) are much easier.

The back-end of the IMAP server is where the individual e-mail is stored. The majority of systems use one of two storage methods, single file or Maildir. The former method uses a single file to hold all of the e-mail, occasionally changing this to a system where a single file holds the mail for each folder. Using a single file is problematic, especially in a multi-user system because of issues of file locking and the performance problems associated with working with a single, large file.

The best solution is the Maildir format, where standard directories on the file system are used to refer to mail folders and individual files are used to refer to each individual e-mail message. This provides for quicker and more efficient access.

However, there are potential problems with large amounts of mail in a single location with both systems. With the single-file solution, performance and possibility of corruption are large. With the Maildir format, some systems suffer when you have a large number of files in a single directory. This is a file system, not mail system, issue, but it still needs to be addressed.

You can use the mailbox usage report to determine whether a new server would alleviate the problems or whether a user needs to organize their e-mail to better improve the overall performance of the server.

Getting some basic mailbox usage statistics

One of the simplest ways to examine the way your users are organizing their e-mail is to run a simple disk usage report. This helps to highlight whether some users are storing large quantities of e-mail on the server and presenting a larger proportion of the heavy load that needs to be addressed.

The mail server used for these examples is Cyrus IMAP, which uses the Maildir format, but the same basic principles apply to solutions that use a single file for their mail store. Listing 5 shows a simple disk usage report for some of the users.

                
$ du -sk *
20      admin
1020    appleby
45828   applicants
13264   buy
11704   dev
11200   finance
52      gordon
25720   mc
472     mcantrip
4340    mlists
120952  myeling
12      nutshell
1812    play
1104    postmaster
1468    quarantine
36      questions
78940   fhf
4156    fhfarc
2444    spam

If you want to enforce mail quotas, you could compare the information output at this stage with a global or per-user quota, and provide the user with some kind of warning. Quotas, however, only tell the user if they are using up disk space. They do not mention if there is a better way of organizing their e-mail or making better use of the space available.

To find out whether a user is making use of the ability to store e-mail in different folders, use find to perform some more detailed examinations. For example, you can request a disk usage report on a directory-by-directory basis with the Maildir format. find searches for directories, and sort ensures that the information is returned in directory name order (see Listing 6). The output has been trimmed slightly to highlight specific areas.

                
$ find . -type d -exec du -sk {} \; |sort -t. +1
...
45828   ./applicants
1964    ./brady
616     ./brady/Article Comments
1304    ./brady/Editors
...
11200   ./finance
4160    ./finance/Banking
12      ./finance/Insurance
1192    ./finance/Other
5476    ./finance/Rewards
296     ./finance/Surveys
...
78940   ./sandra
...
460     ./sandra/Nutshell
3444    ./sandra/Orders
1484    ./sandra/SANDRA-general
40920   ./sandra/Sent Mail
1264    ./sandra/Tracey
1984    ./sandra/eBay
...

Here you have three users at sensible extremes. applicants is using a single mail folder to store all their mail, and finance has sensibly split their e-mail into different folders for easy organization. Meanwhile, sandra seems to be ordering the e-mail correctly, but has one massive folder with all her sent e-mail.

Both applicants and sandra would probably benefit from some sage advice on how to better organize their e-mail. But is there anyway you could help them?

Filing e-mail automatically

There are many solutions for filing and automatically organizing your e-mail. Some of them are built into your client and some are built into the mail server. For example, the Cyrus IMAP server comes with the Sieve system (see Resources) for automatically filtering e-mail when it's delivered to the mailbox of the user.

While this obviously helps new e-mail, existing e-mail needs to be organized by hand. One way to do this is to use a script that accesses the mailbox just like any other client, and then organizes and filters your e-mail based on some rules built into the script.

Listing 7 shows a Perl script that accesses the e-mail folder as a client and processes the contents. In this example, the script creates a new sub-folder structure under the original folder that organizes the e-mail by date, with a folder for each year, and a folder for each month within that year.

                
#! /usr/bin/perl

# Mail filter to file mail on a date basis

use Mail::IMAPClient;
use Date::Parse;
use Data::Dumper;
use strict;
use warnings;

# The IMAP Server
my $Server     = 'imap.example.com';

# The Mailbox we want to filter
my $INBOX      = "Sent-Mail";

# Open the server connection
my $IMAP = Mail::IMAPClient -> new (Server   => $Server,
                                    User     => 'user',
                                    Password => 'password',);

# Open the mailbox we want to filter

$IMAP->select($INBOX) or die "Couldn't select $INBOX";

# We want to filter every message, so obtain a list of every
# message by the message ID

my @msgids = $IMAP->search("ALL");

# Don't do anything if there's nothing to process

exit(0) if (scalar @msgids == 0);

# Now parse the message contents to determine
# the From, To, Subject and Address of each message
my $parsed = $IMAP->parse_headers(
                                  $IMAP->Range(\@msgids),
                                  "From",
                                  "To",
                                  "CC",
                                  "Subject",
                                  "Date",
                                  );

# Set up some message counters

my $toprocess = scalar @msgids;
my $processed = 0;
my $counter = 0;

# Process each message

foreach my $msgid (keys %{$parsed})
{
    $processed++;

    # Extract the date, and build a new folder path
    # The new path will split up emails first by
    # year and then by month, all as subfolders
    # of the current folder

    my ($ss,$mm,$hh,$day,$month,$year,$zone) =
      strptime($parsed->{$msgid}->{Date}->[0]);

    # Try another date if the first one couldn't be identified
    if (!defined($year))
    {
        ($ss,$mm,$hh,$day,$month,$year,$zone) = 
          strptime($parsed->{$msgid}->{Date}->[1]);
    }
    # default to 2004 if we can't find a year
    if (!defined($year))
    {
         $year = 2004;
    }
    # Make some assumptions about the year
    # Occasionally a date will contain only two digits
    # So assume it's either in the year 2000, or 1990+
    $year += 2000 if ($year <10);
    $year += 1900 if (($year >90) && ($year <= 200));
    $year = 2004 if $year <= 1990;
    $month += 1;

    # Construct the new folder path

    my $destfolder = sprintf('%s/%s/%02d',$INBOX,$year,$month);

    # Grab the entire message

    my $Message = $IMAP -> message_string($msgid);

    # Try to change to the destination folder,
    # or create it if we couldn't select the folder

    my $selectstat = $IMAP->select($destfolder);
    unless ($selectstat)
    {
         $IMAP->create($destfolder);
    }

    # Go back to the Inbox so that we select the right message
    # next time round

    $IMAP->select($INBOX);

    # Add the original message to the new folder

    my $AppendStatus = $IMAP -> append_string($destfolder,$Message);

    # When you add a message to a folder, the message
    # is marked as unread, so mark all the messages
    # in the folder as read by reading them

    $IMAP->select($destfolder);
    my @unseenMIDs = $IMAP->unseen();
    foreach my $MID (@unseenMIDs)
    {
         $IMAP->message_string($MID);
    }

    # Go back to the original folder, and delete the message
    # if it was successfully moved

    $IMAP->select($INBOX);
    if ($AppendStatus)
    {
        $IMAP -> delete_message($msgid);
    }
    $counter++;
}

# Print out a summary of what we achieved

printf("Processed %5d out of %5d msgs\r",$counter,$toprocess);

# Make sure we clean out the folder where we deleted messages
# and then disconnect

$IMAP->expunge();
$IMAP->disconnect();

The script relies on you having the user's login and password, but you could easily adapt the script to accept this information on the command line where user could execute the script when needed.

Running this script on a folder, such as the Sent Mail folder, nicely organizes the information, as you can see here in Listing 8 when you run the script again.

                
28932    ./martin/Sent Mail
15288    ./martin/Sent Mail/2006
416      ./martin/Sent Mail/2006/03
812      ./martin/Sent Mail/2006/04
684      ./martin/Sent Mail/2006/05
2068     ./martin/Sent Mail/2006/06
2576     ./martin/Sent Mail/2006/07
772      ./martin/Sent Mail/2006/08
708      ./martin/Sent Mail/2006/09
1104     ./martin/Sent Mail/2006/10
3308     ./martin/Sent Mail/2006/11
2840     ./martin/Sent Mail/2006/12
13632    ./martin/Sent Mail/2007
908      ./martin/Sent Mail/2007/01
884      ./martin/Sent Mail/2007/02
1596     ./martin/Sent Mail/2007/03
864      ./martin/Sent Mail/2007/04
1532     ./martin/Sent Mail/2007/05
1448     ./martin/Sent Mail/2007/06
1116     ./martin/Sent Mail/2007/07
2092     ./martin/Sent Mail/2007/08
2220     ./martin/Sent Mail/2007/09
972      ./martin/Sent Mail/2007/10

A modification of the original script is to parse the message contents and file the mail according to the e-mail sender or subject.

The main benefit of this solution over the typical server or client mail filing systems is that you can use it on existing mailboxes. Many server and client mail systems only file mail on "incoming" or "new" e-mail and become useless once the e-mail reaches the user's mailbox.

In some situations, you can even use it as an automatic process that just becomes part of the e-mail system. You can set up the various auto-filers to execute automatically, where the user drops the e-mail on to an e-mail folder and each night the e-mail is automatically moved to a predetermined location.

Other uses for this technique include warning the user when they have a high level of e-mail in a folder, particularly the inbox, or simply for automatically "archiving" e-mail away into a folder so that the user only has their recent inbox contents available. If you use global mailboxes (for example, in support or queries from customers), then the auto-filing approach can be an effective way of organizing and filtering the e-mail so that it can be located again later.

When using an automated customer relationship management (CRM) system, the issue is often tracked with a number. You can easily set up an auto filer, such as the one demonstrated above, to filter the e-mail by the issue number into an appropriate folder.

Note that this doesn't replace the need for server-side or client-side filtering, but it can be an extension to that process that provides more flexibility and additional information and support.

Summary

In this article, you've examined some of the main ways in which you can extract more information about the e-mail usage of the server at a user level. This information is not about determining whether the server as a whole is running efficiently, but whether your users are getting the best out the services available and how effectively they are using the systems.

Parsing the e-mail logs to determine high-volume users is a good way to start that process. You can find out who is sending and receiving the most e-mail, and determine whether there are users who should move to other servers or who need more attention to determine their e-mail use.

For the latter, a closer inspection of the user's mailbox and mail filing is a good idea, as it can help. Even better, you can re-filter the contents of the mailbox by parsing the information with a script and moving mail messages into a more suitable structure.

Resources

Learn

• Use an RSS feed to request notification for the upcoming articles in this series. (Find out more about RSS feeds of developerWorks content.)
  
  
• System Administration Toolkit: Check out other parts in this series.
  
  
• "System Administration Toolkit: Standardizing your UNIX command-line tools" (Martin Brown, developerWorks, May 2006): Read this article to learn how to use the same command across multiple machines.
  
  
• "System Administration Toolkit: Time and event management" (Martin Brown, developerWorks, May 2006): This article covers the creation and organization of time scripts using cron and at.
  
  
• Read Scheduling recurring tasks in Java (Tom White, developerWorks, November 2003) to learn how to build a simple, general scheduling framework for task execution conforming to an arbitrarily complex schedule.
  
  
• "Scheduling recurring tasks in Java" (Tom White, developerWorks, November 2003): This article shows you how to build a simple, general scheduling framework for task execution conforming to an arbitrarily complex schedule. .
  
  
• For an article series that teaches you how to program in bash, see:
  • "Bash by example, Part 1: Fundamental programming in the Bourne again shell (bash)" (Daniel Robbins, developerWorks, March 2000)
  • "Bash by example, Part 2: More bash programming fundamentals" (Daniel Robbins, developerWorks, April 2000)
  • "Bash by example, Part 3: Exploring the ebuild system" (Daniel Robbins, developerWorks, May 2000)
  
  
• "Making UNIX and Linux work together" (Martin Brown, developerWorks, April 2006): Use this article as a guide to getting traditional UNIX distributions and Linux working together.
  
  
• IBM® Redbooks® : Different systems use different tools, and Solaris to Linux Migration: A Guide for System Administrators helps you identify some key tools.
  
  
• "Exploring the Linux memory model" (Vikram Shukla, developerWorks, January 2006): This model helps you understand how Linux uses memory, swap space, and exchanges pages and processes between the two.
  
  
• Popular content: See what AIX® and UNIX content your peers find interesting.
  
  
• Check out other articles and tutorials written by Martin Brown:
  • Across developerWorks and IBM
  
  
• AIX and UNIX: The AIX and UNIX developerWorks zone provides a wealth of information relating to all aspects of AIX systems administration and expanding your UNIX skills.
  
  
• New to AIX and UNIX?: Visit the "New to AIX and UNIX" page to learn more about AIX and UNIX.
  
  
• AIX Wiki: A collaborative environment for technical information related to AIX.
  
  
• Search the AIX and UNIX library by topic:
  • System administration
  • Application development
  • Performance
  • Porting
  • Security
  • Tips
  • Tools and utilities
  • Java™ technology
  • Linux
  • Open source
  
  
• Safari bookstore: Visit this e-reference library to find specific technical resources.
  
  
• developerWorks technical events and webcasts: Stay current with developerWorks technical events and webcasts.
  
  
• Podcasts: Tune in and catch up with IBM technical experts.
  
  

Get products and technologies

• The Sieve mail filtering system is used by some mail transfer and delivery agents to filter incoming e-mail automatically.
  
  
• IBM trial software: Build your next development project with software for download directly from developerWorks.
  
  

Discuss

• Participate in the developerWorks blogs and get involved in the developerWorks community.
  
  
• Participate in the AIX and UNIX forums:
  • AIX —technical forum
  • AIX 6 Open Beta
  • AIX for Developers Forum
  • Cluster Systems Management
  • IBM Support Assistant
  • Performance Tools—technical
  • Virtualization—technical
  • More AIX and UNIX forums
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• About this series
• Examining e-mail logs
• Parsing the log file for information
• Mailbox storage formats
• Getting some basic mailbox usage statistics
• Filing e-mail automatically
• Summary
• Resources
• About the author
• Comments

Local resources

• IBM Innovation Center - Austin, TX
• IBM Innovation Center - Chicago, IL
• IBM Innovation Center - Dallas, TX
• IBM Innovation Center - San Mateo, CA
• IBM Innovation Center - Waltham, MA
• Technical Briefings in North America

My developerWorks community

Dig deeper into AIX and UNIX on developerWorks

Calling all developers

Download no charge Lotus Domino Designer

Special offers