Postfix: June 2008 Archives

[Update 2009/06/25] Due to a variable scope bug Cyrus timsieved() can crash. The issue is resolved in version 1.2.2.

In case you are using this plugin, please update your installation. The source package can be found here:

giengerldap_auxprop-1.2.2.tar.gz

The md5 checksum is 636e8261198ea69372058e858fc496e9.
You will need Cyrus SASL 2.1.23 to compile it! Please update your SASL 2.1.22 installation, a security fix has been introduced.


[Update] Version 1.2.1 now accesses any attribute requested by SASL, so the use of cmusaslsecret* is possible. In this version the parameter "gl_attribute" has been omitted.

Downloadlinks in this article have been corrected to get the 1.2.1 version.


NOOOOO! Don't talk about saslauthd(8). Customer wanted CRAM-MD5 and DIGEST-MD5 as authentication mechanism for his Postfix authenticated SMTP service. No, not just PLAIN. So saslauthd is out of the game.

Customer has a "mail password" in cleartext in his LDAP structure [Update: he is using cmusaslsecretCRAM-MD5 now] - especially for this kind of thing. Is it possible to use Postfix with that?

First - this is not a postfix issue. Customer had Postfix linked with cyrus sasl. Not a bad idea - but to use these LDAP entries you have to have an appropriate cyrus sasl auxprop. Why?

CRAM-MD5 and DIGEST-MD5 are shared secret algorithms. The server MUST know the cleartext password or the mechanisms' secrets in order to validate the answer sent by the client.

At the first look, I saw a "ldapdb" auxprop plugin which should just do that - and it failed because we did not have a SASL enabled OpenLDAP so ldapdb authentication failed. "*cmusaslsecretCRAM-MD5" (in the case of CRAM-MD5, replace it with DIGEST-MD5 when using DIGEST-MD5) and userPassword are requested from the sasl auxprop.

So here it goes - I had to write my own ldap auxprop. You may use it if you want. I will expain the way to write SASL auxprops in the next days to come, but for now - here is the source.

Use syslogd(8) to get debug messages (loglevel debug, facility auth).

On  the other day, I wanted to access Postfix dbm: and hash:-tables, created by postmap, from Perl. I am setting up a greylisting system and my whitelist should be a postfix table, so I won't have to use another database format.

I used this as a test table:

test1   myentry
test2   yourentry
test3   funny

I saved it as "testmap". After that, I used:

postmap testmap

Result:

-rw-r--r-- 1 pascal users    42 2008-06-16 10:14 testmap
-rw-r--r-- 1 pascal users 12288 2008-06-16 10:14 testmap.db

You may access this hash-type postfix-db just by using DB_File:

#!/usr/bin/perl

use Fcntl;
use DB_File;

my %tab;
my $null=chr(0);

tie %tab,'DB_File','testmap.db',O_RDONLY,0400,$DB_HASH;

# Sample query
my $key='test2';

my $value=$tab{$key.$null};
chop $value;  # chop null byte

print $key." = ".$value."\n";

Result:

test2 = yourentry

As you can see, the key must be terminated by a null byte, and the result itself is also null-terminated.

In case you use the dbm:-Format in postmap:

-rw-r--r--   1 root     root          42 Jun 16 11:30 testmap
-rw-r--r--   1 root     root           0 Jun 16 11:30 testmap.dir
-rw-r--r--   1 root     root        1024 Jun 16 11:30 testmap.pag

In Perl, just use NDBM_File instead and use the filename without .dir or .pag:

#!/usr/bin/perl

use Fcntl;
use NDBM_File;

my %tab;
my $null=chr(0);

tie %tab,'NDBM_File','testmap',O_RDONLY,0400;

# Sample query
my $key='test2';

my $value=$tab{$key.$null};
chop $value;  # chop null byte

print $key." = ".$value."\n";

The Keys and values are also null-terminated in this case.

Result is the same as with our hash:-Postfix-Table:

test2 = yourentry