Archive for February, 2006

Fine tuning Postfix mail logs

February 23rd, 2006 Mark No comments

For some reason, by default, after installation via apt-get of Postfix on Debian, Postfix log output gets logged to /var/log/syslog, /var/log/mail.log and /var/log/ all with the same information

On one of my servers, syslog-ng takes care of the syslog.. the edits to this (syslog-ng.conf) comprised:


filter f_syslog { not facility(auth, authpriv); };


filter f_syslog { not facility(auth, authpriv,mail); };

and also comment out this:

#log { source(src); filter(f_mail); destination(mail); };

On another one of my servers, the default syslog is in use.. the edits to this (syslog.conf) comprised:


*.*;auth,authpriv.none; /var/log/syslog


*.*;auth,authpriv.none;mail.none; /var/log/syslog

and also comment out this:

#mail.*                         -/var/log/mail.log

now restart the daemons and your log files won’t have a shedload of duplicated information!

Categories: Linux, SysAdmin Tags:

Bind8 Logging problems

February 23rd, 2006 Mark No comments

On my vds (virtual dedicated server) I run Bind8 due to issues getting Bind9 to run properly

I’ve been trying to debug a problem with the zone transfer of a certain domain (turns out I had input the wrong secondary nameserver). I wanted get Bind8 to log basically everything.. so I stuck in a custom “logging {}” section in named.local.options but for some reason, the file was never created.

Unfortunately, it took me quite a while to realise that there was already a logging section in named.conf and that my section was being read but ignored (would give syntax errors if they existed in the new section but wouldn’t make my damned log file!)

I merged the two logging sections together in named.conf and it actually worked, the file being created in /var/cache/bind/

Categories: Linux, SysAdmin Tags:

Postfix XForward annoyance

February 20th, 2006 Mark No comments

I run our company’s email server – it’s Postfix on Debian.

I decided to create a script which would scan the mail logs and list clients that tried to send SPAM, so that I could add them to a blacklist.

A brief spell of messing about trying to implement this made me realise that the easiest way for me to parse the log would be for AMAVIS to output the actual client IP. However, since the source can be faked in the mail envelope, I wanted Postfix to pass the client IP onto AMAVIS, which brings me to XForward.

XForward is an SMTP extension which allows a trusted client/server to pass on the original client IP to a destination server (which could pass this on further, etc.)

I spent a while wondering why AMAVIS wasn’t getting the XForward’d IP, eventually realising that it wasn’t implemented in the version that I was running.. trying up apt-get the latest unstable/testing version yielded a nice message telling me that e2fsprogs needed to be updated (which is not something trivial).. I therefore decided to manually update amavis to a version which didn’t require the Perl library update which relied on the e2fsprogs, etc, etc being updated (see here for more details)

Eventually I got the whole thing working but then I realised a small problem – spammers often don’t care about which prority MX they use, i.e. they’ll use a backup MX sometimes, trying to bypass filters, etc.

I decided to try to get Postfix on the backup MX to XForward the original client to the primary mail server. This turned out to be a complete ball-ache.. After hours of pissing about trying to get it to work, I decided to install the very latest version of Postfix on the backup MX – even though 2.1 onward (according to all the Postfix documentation) supports XForward… lo and behold it worked! So either the documentation is wrong or there’s a bug in the version of Postfix I was using… very annoying

Thankfully, it’s all working fine now and my blacklist is growing :)

Categories: Linux, SysAdmin Tags: