Postfix Monitoring With Mailgraph And pflogsumm On Debian Etch

Version 1.0
Author: Falko Timme
Last edited 06/07/2007

This article describes how you can monitor your Postfix mailserver with the tools Mailgraph and pflogsumm. Mailgraph creates daily, weekly, monthly, and yearly graphs of sent, received, bounced, and rejected emails and also of spam and viruses, if SpamAssassin and ClamAV are integrated into Postfix (e.g. using amavisd-new). These graphs can be accessed with a browser, whereas pflogsumm ("Postfix Log Entry Summarizer") can be used to send reports of Postfix activity per email.

In the following I will describe how to install and configure Mailgraph and pflogsumm on Debian Etch.

I do not issue any guarantee that this will work for you!


1 Preliminary Note

In this tutorial my Linux system has the IP address and hosts the web site with the document root /var/www/ and a cgi-bin directory of /var/www/, and I will send the pflogsumm reports to the email address


2 Mailgraph

Debian Etch has packages for Mailgraph and pflogsumm, so we simply install these. We also install rrdtool that stores the data which is needed by Mailgraph to draw the graphs:

apt-get install rrdtool mailgraph

Now we configure the mailgraph package like this:

dpkg-reconfigure mailgraph

You will be asked a few questions:

Should Mailgraph start on boot? <-- Yes
Logfile used by mailgraph: <-- /var/log/mail.log

Then there's also this question:

Count incoming mail as outgoing mail?

If you have integrated a content filter like amavisd (for spam and virus scanning) into Postfix (like in this tutorial: Integrating amavisd-new Into Postfix For Spam- And Virus-Scanning), then answer No to avoid that Mailgraph counts your emails twice (because Postfix delivers emails to amavisd which then - after successful scanning - delivers the mails back to Postfix). If you don't use a content filter, then answer Yes.

During the installation, the system startup links for Mailgraph are created automatically, and Mailgraph also gets started automatically, so we don't need to start it manually.

Now we must copy the mailgraph.cgi script (which draws the graphs and creates the output for our web browsers) to the cgi-bin directory of our web site:

cp -p /usr/lib/cgi-bin/mailgraph.cgi /var/www/

The script is already executable, so we don't need to chmod it. If you use suExec for the web site, you must chown mailgraph.cgi to the appropriate owner and group.

Now direct your browser to, and you should see some graphs. Of course, there must be some emails going through your system before you see the first results, so be patient.

After some time your graphs could look like this (the following output is customized, so it doesn't look exactly like yours):

Daily Statistics.

Weekly Statistics.

Monthly Statistics.

Yearly Statistics.

Please note: Mailgraph will report spam and viruses only if you have integrated a content filter like amavisd-new into Postfix which is configured to use SpamAssassin and ClamAV to tag spam and virus mails. If you don't do this, you will still see graphs, but without the spam and virus report.


3 pflogsumm

To install pflogsumm, we run

apt-get install pflogsumm

We want pflogsumm to be run by a cron job each day and send the report to Therefore we must configure our system that it writes one mail log file for 24 hours, and afterwards starts the next mail log so that we can feed the old mail log to pflogsumm. Therefore we configure logrotate (that's the program that rotates our system's log files) like this: open /etc/logrotate.conf and append the following stanza to it, after the line # system-specific logs may be configured here:

vi /etc/logrotate.conf

# system-specific logs may be configured here
/var/log/mail.log {
    rotate 7
    start 0

There's a logrotate script in /etc/cron.daily. This script is called every day between 06:00h and 07:00h. With the configuration we just made, it will copy the current Postfix log /var/log/mail.log to /var/log/mail.log.0 and compress it, and the compressed file will be /var/log/mail.log.0.gz. It will also create a new, empty /var/log/mail.log to which Postfix can log for the next 24 hours.

Now we create the script /usr/local/sbin/ which invokes pflogsumm and makes it send the report to

vi /usr/local/sbin/

gunzip /var/log/mail.log.0.gz

pflogsumm /var/log/mail.log.0 | formail -c -I"Subject: Mail Statistics" -I"From: pflogsumm@localhost" -I"To:" -I"Received: from ([])" | sendmail

gzip /var/log/mail.log.0
exit 0

We must make this script executable:

chmod 755 /usr/local/sbin/

Then we create a cron job which calls the script everyday at 07:00h:

crontab -e

0 7 * * * /usr/local/sbin/ &> /dev/null

This will send the report to It looks like this in an email client:


4 Links

Share this page:

4 Comment(s)

Add comment


From: at: 2007-07-26 06:56:59

In my situation Ubuntu 7.04 (Feisty) the script ( complained that the formail command was not found.

 It exists in the procmail package so you may need to install this package along with the pflogsumm.

From: at: 2007-12-04 01:57:11

In my enviroment using debian etch and suphp. Installing mailgraph I had to chown /var/www/ and /var/lib/mailgraph to the appropriate owner and group.

From: at: 2008-03-22 12:01:59


 First, thank you for this nice tutorial.

AFAIC, I prefer adding "delaycompress" option to logrotate stanza so that I always have yesterday logs readable as is and, so, don't have to gunzip and gzip back *.log.0 files.

BTW, rather than modifying /etc/logrotate.conf, I suggest to create a dedicated file in /etc/logrotate.d/, like /etc/logrotate.d/mail with the following content

/var/log/mail.log {
    rotate 7
    start 0

Finally, instead of editing the crontab, I prefer creating a symlink to the script, in this case, in /etc/cron.daily; or if you want a custom schedule, create an /etc/cron.d/pflogsumm file.

 Thank you again



From: Tom Bailey at: 2009-03-30 21:35:37

As with others here, thanks. I'm using Debian 5.0 but it runs the same.

Note that is you are using rsyslog you'll need to comment out the mail.log reference in /etc/logrotate.d/rsyslog or you'll get a duplicate log reference error when logrotate attempts to execute. If you don't notice it for a couple days it could be a real bitch as it prevents logrotate from running.

Snip from /etc/logrotate.d/rsyslog: