TLS via SMTP is opportunistic which makes connections vulnerable to man-in-the-middle-attacks. In order to prevent mitm-attacks, DANE could be used. The sender-server will first check the domain-records if dnssec is in use(and valid) and if a TLSA-record is published(and valid). If a TLSA-record is valid and matches with the certificate of the recipient-server the connection could be encrypted and the encryption is verified.
I wrote a role for managing MaraDNS with Ansible.
- Ansible 2.1+ (might ork with prior versions too)
- Debian-based Linux-distribution
ansible-galaxy install whotwagner.maradns
Check_MK is a great monitoring tool. One of it's strengths actually is, that it can automatically detect services and monitors it. I always monitored all public ip-addresses of my servers if they are listed on any dns-blacklist. I had to add new public ip's manually, so I reached out for a new solution. I found a nice little plugin in a GitHub-repository of HeinleinSupport. The plugin waIs great, but I missed two things.
If I enable postscreen on a Debian-Host I'll get this strange message in my mail.log:
Feb 13 08:38:37 tardis postfix/postscreen: close database /var/lib/postfix/postscreen_cache.db: No such file or directory (possible Berkeley DB bug)
It looks like the postscreen_cache.db-file is located in /var/lib/postfix instead of the postfix-jail /var/spool/postfix/var/lib/postfix. So we can fix it by moving the file into the jail:
dr@tardis$ psql -U postgres psql (9.4.9) Type "help" for help. postgres=# update pg_database set datallowconn = TRUE where datname = 'template0'; UPDATE 1 postgres=# \c template0 You are now connected to database "template0". template0=# update pg_database set datistemplate = FALSE where datname = 'template1'; UPDATE 1 template0=# drop database template1; DROP DATABASE template0=# create database template1 with template = template0 encoding = 'UTF8'; CREATE DATABASE template0=# update pg_database set datistemplate = TRUE where datname = 'template1'; UPDATE 1 template0=# \c
I experienced an interesting problem: on a Debian Jessie host with squidguard: update-squidguard threw the following error-message:
root@34697f9f06a2:/# update-squidguard /usr/sbin/update-squidguard: 69: test: dbhome: unexpected operator Rebuild SquidGuard database - this can take a while.
On Debian Wheezy it returns with the following error: