Recently in Postfix Category

Important update to my ldap auxprop demo plugin

| | TrackBacks (0)
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 from 2.1.22 to 2.1.23!



Obsolete things can be nice. They can be useful. These "cmusaslsecret"-Thingies are.
But let's start from the beginning. You may however start to play with them!

You are using Cyrus SASL for authentification purposes? Supposedly with the Cyrus IMAP server or Postfix (the two major applications using Cyrus SASL)? Then you'll know the problem: You may use saslauthd(8) to connect to an authentication database as Unix PAM or LDAP. Problem: You will only be able to use plaintext logins. Why?

If using saslauthd, the SASL-enabled server gets the password given by the user/client, and asks saslauthd whether it is correct or not.

Plaintext authentication can be sufficient when using it with SSL/TLS. In IMAP environments this may be a good solution if all mail clients can be configured in that way. With SMTP you will have a problem. Many Mailservers being able to initiate authenticated outgoing SMTP connections do not use SSL/TLS. Many of them want to use CRAM-MD5 as it is defined in many standard drafts.

Updated mailgrey graylisting policy scripts

| | TrackBacks (1)
for my dual (My)SQL-Server Postfix graylisting policy service mentioned in
this blog entry about the two-node redundant SQL postfix graylisting service
are available:


You will need an MySQL Database Version 5 or greater (for InnoDB performance), perl with DBD::mySQL and Digest::MD5, and Postfix capable of using Policy servers.

With this update, changes to the whitelist databases (postmap) are detected automatically. The literal script in the former blog article was updated also.

Graylisting stats after 19 days

| | TrackBacks (0)
As mentioned before, I set up a graylisting combo on two incoming mailservers using Postfix, MySQL and Perl (on Solaris 10). This solution runs now for 19 days and I took the time to analyze the database a little bit. Here's a plot of the number of positive graylisted entries since the beginning (X-axis represents the number of days since the beginning):

w.gif

The number of new entries per day is going slowly down, as expected.
These servers deliver mail for approx 12,000 users. So at the moment every user statistically receives mail from 40 correspondents.

The two SQL databases are running fine, and every night between 2.5 and 6 million rows are deleted (inactive graylisting entries which did not become active after 48 hours):

Jul 14    Inactive deleted:  2646153    Active deleted:        0
Jul 15    Inactive deleted:  4268527    Active deleted:        0
Jul 16    Inactive deleted:  5531953    Active deleted:        0
Jul 17    Inactive deleted:  4406925    Active deleted:        0
Jul 18    Inactive deleted:  3413663    Active deleted:        0
Jul 19    Inactive deleted:  3422004    Active deleted:        0
Jul 20    Inactive deleted:  2864347    Active deleted:        0


First:

On our running Postfix-Graylisting Setup, the two MySQL nodes are quite loaded:

Uptime:                 1 day 8 hours 54 min 29 sec

Threads: 320  Questions: 20519246  Slow queries: 15205  Opens: 522  Flush tables: 1  Open tables: 516  Queries per second avg: 173.204


And this is the result of implementing graylisting:

greylisting.png

But let's start from the beginning.

The scenario was like that:
Two mail servers are acting like an MX for an educational institution. 1.2 million spam mails came in per day. The two Ironport appliances behind did their best to sort them out, but in that institution spam cannot be deleted, there are laws against that. So the central cyrus mail server sorts them out via sieve scripts and puts them in the Spam boxes of every user, wasting disk space and - more important - disk i/o.

So I had the idea to implement a graylisting setup.

Each of the two Postfix nodes has its own MySQL database server running. But how to replicate data between them?




[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).


Accessing Postfix dbm and hash tables from Perl

| | TrackBacks (0)
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



December 2015

Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

About

This blog is owned by:

Pascal Gienger
J├Ągerstrasse 77
8406 Winterthur
Switzerland


Google+: Profile
YouTube Channel: pascalgienger