Spamhaus vs. nic.at

Klar ist Spam nicht toll. Und Phishing schon gar nicht. Wie heise online berichtet setzt Spamhaus.org Österreichs Domainverwaltung unter Druck, weil nic.at 15 Domains, über die Phising betrieben worden sein soll, nicht löschen will. Ich frage mich was ein Anwalt zu dem Spamhaus SBL-Eintrag sagen würde… Langsam aber sicher geht mir die Arbeitsweise von Spamhaus.org richtig auf die Nerven. Ich muß mir echt mal überlegen, ob der Einsatz dieser Blacklist noch tragbar ist.

Update 20.06.2007

Wie heise online berichtet relativiert Spamhaus.org das nic.at-Listing.

Update 21.06.2007

Wie heise online berichtet weist Nic.at die Spamhaus-Darstellung zurück. Der Eintrag scheint inzwischen allerdings entfernt worden zu sein, der Original-Link liefert nun folgendes:

The reference SBL55625 is not in the SBL database.
This may be because the issue has been resolved and removed from the SBL.

Spamhaus.org scheint sich mit dieser Aktion nicht viele Freunde gemacht zu haben…

Update 24.06.2007

Immer noch Neues: heise online – Spamhaus.org entfernt einen von zwei nic.at-Einträgen.

Update 09.07.2007

Heute gefunden: Kommentar: Spam-Ritter auf der schiefen Bahn – c’t-Redakteur Mirko Dölle kommentiert das Vorgehen von Spamhaus gegen nic.at.

Mir wird echt schlecht…

…wenn ich sowas lese:

Auf insgesamt 53 Seiten, die dem Bundesrat für seine Stellungnahme am 8. Juni dienen sollen, packen die Länderpolitiker aus dem Innen-, dem Rechts- und dem Wirtschaftsausschuss auf alles, was von Verfassungsrechtlern in den Bereich der höchst problematischen bis klar verfassungswidrigen Eingriffe eingestuft wurde, noch eins drauf. Die in dem Papier gemachten Vorschläge sind teilweise so klar grundgesetzwidrig, dass man eigentlich schon von einem Putschversuch gegen die Verfassung sprechen könnte.

Quelle: TP: Schäuble ohne Gesicht: Die Bundesratsausschüsse wollen alle Horrorszenarien der letzen Jahre zusammengefasst in die Neuregelung der Überwachung der Telekommunikation integrieren.

iPod, iTunes und QuickTime Schluckauf

Heute hat mir iTunes das Update auf Version 7.2 vorgeschlagen. QuickTime wurde gleich mit upgedated. Nach dem fälligen Reboot meldete QuickTime beim Starten einen Runtime-Fehler und iTunes weigerte sich zu starten mit dem Hinweis, das ein Problem mit meinem Soundsystem vorläge. Das Problem betraf aber QuickTime, das ja abstürzte beim Start und von iTunes gebraucht wird. Also habe ich die QuickTime Installation über die Windows Systemsteuerung reparieren lassen. Das hat auch geklappt, danach behauptete iTunes beim Syncen des iPods allerdings, das ich keine Rechte hätte über 100 gekaufte Songs auf den iPod zu übertragen. Nach einem kurzen Schock kam ich dann auf die Idee in den Shop zu gehen, worauf ich mein Passwort eingeben mußte. Das ist seltsam genug, denn normal fragt er mich danach nicht mehr, aber immerhin auch die Erklärung für mein Problem. Ohne gültiges Passwort sind die Songs durch das DRM gegen kopieren geschützt. Schöner Mist. 🙁 Aktuell synced iTunes meinen iPod wieder, nachdem er ein paar hundert Dateien scheinbar vom iPod gelöscht hat…

Debian + jabber + SSL

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?

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

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

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.