Posts about qmail (old posts, page 3)

2006-11-23 16:03

My qmail-courier-whatever munin plugins

A few people have asked me for the code. Ok, here it goes.

First, get qmrtg.

Then you need this: qmunin.tar.bz2

Then build and install it. You may need to modify the sources, depending on just how your qmail works. There are some example munin plugins included (in spanish, I am not translating them ;-), which 99% surely will not work for you, but they are simple shell scripts, so you should be able to hack them.

Creating a real release of this is just useless, because everyone's qmail logs look different, so take it and hack it.

And that's it.

2006-11-14 15:40

ra-plugins 0.2.9 is coming closer

Version 0.2.9 of ra-plugins, my qmail-spp plugin collection is coming soon.

Including lots and lots of new plugins, a real build system, and even two patches by someone else :-)

So, now is a good time to let me know if you are using ra-plugins, if you have any problems with it, and if you have any ideas for cool plugins. I can write them.

2006-10-02 09:52

A different UNIX Part I: Mail in not-mail-servers

I have been procrastinating about creating my own Linux distro for at least three years. Guess what? I will still procrastinate about it for a few more, but that doesn mean I can't write about how it's supposed to work ;-)

So, here is a first piece of the puzzle...

What do I mean by "Main in not-mail-servers"?

If by mail server we mean a box that has the responsability to handle sending mail for users, non-mail-servers are all the rest.

And what is it they do with mail? They generate it. Both the users and the processes of those boxes generate mail. They do it for cron jobs, they do it for maintenance processes, they do it for alerts, whatever.

And what is it they do with that email? They send it somewhere.

Usually, they send it to themselves. Which is a pretty useless thing.

Go now and check the root mailbox in your computers. I bet most of you have a bunch of mails in them you never checked. Either it's important, in which case you should have placed it in a mailbox you actually read, or it's not, in which case it's useless to store.

In any case, it shouldn't be there.

How does your box send those mails? Using either the sendmail binary, or the mail program (probably mailx), which uses the sendmail binary.

Just because it's called sendmail it doesn't mean it is sendmail, of course. Postfix and qmail provide a sendmail wrapper to inject mail into their queues.

But the main problem is that using those means you need to have a well configured mail server in every box, even if they are not mail servers! Yes, your distro gives you a decent configuration by default which makes things usually work... for local mail delivery at least. Which is probably not really what you want.

Enter nullmailer. A sort of heavily sedated, neutered qmail.


  • Default domain name of outgoing mail in /etc/nullmailer/me

  • List of SMTP servers in /etc/nullmailer/remotes: smtp --user=ralsina --pass=notmyrealpass

You can put several, it will try them in order.

And that's that. A tiny service, which uses no TCP ports. The whole thing is 59KB (or less if you use diet libc), has one SUID binary (but it is not SUID root), two config files (both one-liners), no need for aliasing the system users.... and you can remove postfix/sendmail/qmail from most of your servers.

Sounds like a good idea to me.

2006-09-08 18:41

Graphing qmail/courier-imap stats using munin

Traditionally, you graphed your system's status using MRTG but nowadays, there are much nicer tools, and I like Munin.

For MRTG+qmail there are many scripts, but I couldn't find one I liked for Munin.

Since munin is modular, it's easy to fix, of course.

First, get the excellent qmrtg which gives you great, quick, awesome multilog-crunching tools.

Then, check the cods, check the munin plugin docs, and it's pretty much a 20-line thingie. In shell.

I would post it, but my blogging tool hates shell code :-)

And you get your graphs. I am probably going to write a collection of these and publish it somewhere.

2006-09-01 22:01

Need a flat DB? Use TDB!

No, do not use gdbm. Probably not bdb either.

TDB allows for concurrent writes. So, if you want to store some data in a file in your application/tool/command/whatever, and there is a chance that you need concurrent writes... TDB is really the only reasonable choice I know.

You can even have distributed TDBs.

I found out about TDB while writing a persistant cache for a little tool (a qmail plugin). Since by its nature it would have concurrent writes all the time, I was aiming for something like memcached, or its disk-based version... but TDB solves the problem nicely and effortlessly.

So, if you need a flat DB (a.k.a anonymous blobs with a single index, a.k.a a hash in a file)...

2006-08-14 15:42

Ideas for SMTP plugins

The only current software I wrote that some people actually use is called RA-Plugins. It's a series of proggies you plug in your SMTP server's conversation, and do diverse things with it, like rejecting messages that fail certain criteria, checking the status of the recipient's account, whatever.

Injecting this stuff in the middle of SMTP is good because it means you will reject the messages before they get into your server. But... I am running out of ideas, so... have any you can spare? :-)

You can see the current plugin list here and the only ideas I have left are:

  • A plugin that calls back to the sender's email server and tries to email him, ala milter-sender to catch forged senders.
  • A plugin to autowhitelist in spamassassin those addresses to which you send mail.
  • A plugin to keep an account of how many connections you hold to each IP, and limit them. (Not currently possible)

If you understand what I wrote, and have any ideas... feel free to post them as comments and/or email me with them!

2006-08-11 14:42

CMake is nice. Or not?

I am playing with CMake. Specifically, I am trying to replace the simplistic handmade Makefiles for my RA-Plugins project.

The parts about detecting libraries and conditionally compiling plugins based on what you have were surprisingly easy!

Until I ran into ... man pages.

Here is a Makefile that would build all the manpages for the plugins:

MANPAGES=plugins-ra.8 authchecks.8 rcptchecks.8
man: \$(MANPAGES)
      txt2man -t \${basename $< .man.txt} < $< > [email protected]

As you can see... trivial. All I need to do in order to add a man page is add whatever.8 to the list, and it will be created from

But... how does one do that using CMake?

I started thinking of using a FILE (GLOB *.man.txt) and then a FOREACH over that, and then... then what? Really, I am stumped. I am a newbie, though, and getting the big, difficult stuff done is enough to switch. I should generate these before distribution anyway.

So, I wrote a wee Makefile.manpages and added this for CMAKE:

ADD_CUSTOM_TARGET ( manpages make -f Makefile.manpages )

But I am curious about finding the cmakeish way.

2006-05-13 13:21

Measure twice, crash once (or less)

Having running statistics on your systems is always a good idea.

Since I am a qmail freak, I have been using the venerable qmailmrtg7 for a long while.

In fact since I use my courier pop3/imap server with tcpserver, I can even use qmailmrtg7 to give me stats about POP3 and IMAP, which it susually doesn't.

But... qmailmrtg7 is kinda lame. In part it is lame because it uses mrtg. In part it is lame because it's one opaque thing.

Munin, based on rrdtool is much nicer to look at than mrtg, and has a much more reasonable architecture.

Then, I found qmrtg which is much nicer than qmailmrtg7, and also has a much nicer architecture.

So, why not make a qmunin based on qmrtg which will marry them?

Well, that's an idea.

It's not even very hard to do :-) I should probably do it and publish it.

2006-05-07 21:00

There is no excuse: your program should have a man page!

I wrote Linux/Unix applications for ten years before I wrote my first man page.

I used all the excuses:

  • My app has interactive help
  • My app is for private use
  • Someone will write it eventually

But of course there are only two reasons not to write man pages.

  • You think the man pages are obsolete.

This is what the FSF thinks. So, they give you info pages. And they put, at the bottom of each manpage some warning about how that may look like the docs, but the real docs are the info pages.

Then they don't provide a decent info reader outside of emacs. But hey, who cares. On KDE, just use a info: URL.

  • You hate writing man pages.

Which is perfectly understandable, since this is how a man page looks like (and yes, I know it's specially ugly example):

.de }1
.ds ]X \&\\*(]B\\
.nr )E 0
.if !"\\$1"" .nr )I \\$1n
.ll \\n(LLu
.in \\n()Ru+\\n(INu+\\n()Iu
.ti \\n(INu
.ie !\\n()Iu+\\n()Ru-\w^G\\*(]X^Gu-3p \{\\*(]X
.el \\*(]X\h^G|\\n()Iu+\\n()Ru^G\c

And it is even possible that for some man pages you need to write such a thing.

But for the average program? Just take something like txt2man and be happy.

I wrote man pages for each of my qmail-spp plugins in a few minutes. Although they probably are lacking in their man-pageness in matters of style, they are ok.

And they are not hard to write at all (full):




  This plugin is meant to be used on the AUTH command and does two things:

  1. Logs the user (see LOGGING)

  2. If the user is authenticated, it sets QMAILQUEUE "/var/qmail/bin/simscan-nospam",
  which is probably not what you want, but is what I use right now ;-)

And there is no reason why your program, be it KDE-based or not, should not have such a thing.

Contents © 2000-2019 Roberto Alsina