Monat: Mai 2007

Debian + jabber + SSL

von

Nach einem Server-Wechsel habe ich meinen Jabber-Server neu installiert. Dabei hatte ich Probleme das SSL wieder zum Laufen zu bekommen. Eigentlich dachte ich, dass es mit so einem Eintrag getan sei:

<ssl>
   <key ip='[IP-Adresse]'>/etc/jabber/jabber.pem</key>
</ssl>

Da lag ich leider falsch, da ich noch diese Zeile in der jabber.xml einkommentieren musste:
<ssl port='5223'>[IP-Adresse]</ssl>
Jetzt tuts wieder brav mit SSL. 🙂

Trojaner an Bord?

von

Nachdem ich meine WoW-Session beendet hatte, bemerkte ich nach einigen Minuten anhaltende Festplatten- und Netzwerk-Aktivitäten. Das machte mich stutzig, da ich keinen Download laufen hatte und auch kein Browser oder Mailprogramm lief. Ein netstat -a brachte einige offene Verbindungen zu Port 3724 zum Vorschein. Google offenbarte mir dann, dass es sich bei dem Täter um den WoW Background Downloader handelte. Danach fiel mir der folgende Text im WoW Launcher auf:

Download startet...

In den Optionen hat man für den Patch-Download nun folgende Möglichkeiten:

WoW Patch Download Optionen

Dann scheint das soweit in Ordnung zu sein. Der Patch 2.1 „Der Schwarze Tempel“ wird wohl in absehbarer Zeit erscheinen.

Postfix mit virtuellen und System-Accounts

von

Ich hatte schonmal auf einem Server einen Postfix Mailserver mit System-Accounts laufen. Das ganze sah so aus, dass Postfix für eine größere Anzahl von Domains eMails annimmt und diese Anhand der /etc/aliases Datei an lokale User verteilt. Das hatte den riesen Vorteil, dass ich nicht für jede einzelne Domain immer die selben eMail-Adressen anlegen mußte. Durch den Einsatz von SysCP dachte ich eigentlich, dass Postfix dieser Möglichkeit beraubt wird. Ich habe aber festgestellt, dass mich Postfix nicht daran hindert virtuelle und System-Accounts zu mischen. Ich kann einfach die Datei /etc/postfix/destinations anlegen und dort alle Domains eintragen, die Postfix unabhängig von SysCP verwalten soll. Die Datei teilt man Postfix in der main.cf folgendermassen mit:
mydestination = /etc/postfix/destinations
Wichtig ist nur, das die Datei keine Domains enthält, die SysCP verwaltet. Für SysCP wird weiterhin die virtual_mailbox_domains Einstellung benutzt:
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual_mailbox_domains.cf
Bei mir klappt dieser Mischbetrieb ganz gut. Ich lasse eMails über die /etc/aliases Datei allerdings an eine virtuelle Mailbox in SysCP zustellen, um über Courier die Mails abrufen zu können. Dann gibts nur noch eins zu sagen: Bei Änderungen an der Datei /etc/aliases sollte man den Aufruf von newaliases nicht vergessen.

Postfix Backup-MX

von

Bei einfachen Backup-MX Konfigurationen fällt auf, dass auf dem Backup-MX immer wieder Spam-Mails eingeliefert werden, obwohl der Primary-MX erreichbar ist. Ein möglicher Grund dafür könnte sein, dass gegenüber dem Primary-MX weniger Prüfungen über eingehende eMails laufen. Eine oft vernachlässigte Prüfung ist die der gültigen Empfänger-Adressen. Ein Backup-MX würde also einfach alle Empfänger-eMail-Adressen annehmen und versuchen diese dem Primary-MX zuzustellen. Dieser lehnt aber alle eMails an ungültige Empfänger ab. Also wird eine eMail an den Absender der Nachricht generiert. Bei Spam ist diese oft gefälscht, so dass der vermeintliche Absender eMail-Server unseren Bounce bounced. Dieser landet dann in der Regel beim Postmaster, was ein ziemliches Ärgernis darstellt.
Bei Postfix gibt es die Konfigurationsoption relay_recipient_maps, die eine Datei mit den gültigen Empfänger-Adressen auf dem Primary-MX setzt. Adressen die hier nicht vermerkt sind, werden gleich auf dem Backup-MX abgelehnt. Man darf nur nicht vergessen die Datei nach jeder Änderung mit postmap ins hash Format umzuwandeln. Die Konfiguration anhand der verlinkten Dokus klappte bei mir problemlos.

Debian Etch + SysCP + clamscan.sh

von

Heute habe ich eine Lösung für die clamscan.sh Problematik gefunden. Unter Debian Etch scheint das Device /proc/self/fd/0 nur für root zugänglich zu sein. Abhilfe schafft ein cat -, das auch von stdin einliest. clamscan.sh muss also wie folgt angepasst werden:


#start
#MSG=$(cat /proc/self/fd/0) # stdin -> $MSG
MSG=$(cat -) # So klappts unter Etch

Falls man sicher gehen will, dass clamscan.sh auch wirklich lief, kann man noch die folgende Header-Zeile einfügen lassen:

MSG=$(echo "$MSG" | reformail -i"X-Virus-Scanned: by clamscan.sh (Debian)")

Das ganze kann man vor oder nach dem X-Virus-Status: einbauen.

Debian Etch + SysCP + SpamAssassin

von

Die Geschichte nervt mich inzwischen echt. Von der Maildrop 2.0.x + courier-authlib Problematik blieb zuletzt noch das SpamAssassin Problem übrig. Es äußerte sich im mail.log wie folgt:

localhost spamd[19964]: config: not parsing, administrator setting:
                        bayes_path /path/to/bayes
localhost spamd[19964]: config: failed to parse line, skipping:
                        bayes_path /path/to/bayes

Es scheint wohl so zu sein, dass SpamAssassin in neueren Versionen das Setzen dieses Pfades nur noch über die Konfigurationsdateien erlaubt. Nebenbei sei bemerkt, das diese Konfiguration, die ich auf mehreren Servern eingerichtet hatte, inzwischen nirgendwo mehr funktioniert. 🙁 Also bleibt aktuell nur noch der Ausweg eine SQL-Datenbank für die Bayes-Daten zu benutzen. Da sitze ich zur Zeit dran und dann muß ich mir auch nochmal die clamscan.sh Problematik anschauen.