Kommentardatenbank repariert
Geschrieben in
Technik
Freitag, 7. Dezember 2007
Tja, das tut mir echt leid. Ich hab' heute mal so ca. eine Stunde an der Datenbank rumgespielt, die die Kommentare enthielt, und irgendwie... na ja, ich bin da nicht mehr so fit. An all' die Leute, die plötzlich mit meiner oder sonstigen fremden Mailadresen aufgetaucht sind: Tut mir leid. Fehler behoben, Zeit für's Wochenende!
Nachtrag: Ok, es hatte wohl noch etwas mehr erwischt als nur die Adressen. Macht nichts, wofür hat man Backups
Nachtrag: Ok, es hatte wohl noch etwas mehr erwischt als nur die Adressen. Macht nichts, wofür hat man Backups
Keine Mailannahme
Geschrieben in
Technik
Mittwoch, 7. November 2007
Wer eine Internetpräsenz betreibt, für die er keine Mails annehmen will, der hinterlegt bei der betreffenden Adresse normalerweise keinen MX-Eintrag. Da Spammer doof sind, verbinden sie sich dann direkt mit der IP-Adresse, die zu der Internetseite gehört. Und da hat Leonard Orb ein schönes, kleines Skript gezaubert:
Gefällt mir gut, RFC-konform wird mit 554 gegrüßt und dann abgesehen von „QUIT” jedes Kommando mit 503 beantwortet. Einbinden kann man das ganze dann z.B. via (x)inetd.
Man kann natürlich auf dem betreffenden Host auch gar nichts auf Port 25 lauschen lassen - wenn man sich denn um die Mailqueues von legitimen Servern, die evt. einliefern wollen, keine Gedanken macht
CODE:
#! /bin/bash
echo -e "554 we do not accept email from anyone\r"
while read CMD; do
CMD="$(echo "$CMD" | tr A-Z a-z | tr -d "\r")"
test "x$CMD" == "xquit" && break
echo -e "503 expecting QUIT\r"
done
echo -e "221 goodbye\r"
Gefällt mir gut, RFC-konform wird mit 554 gegrüßt und dann abgesehen von „QUIT” jedes Kommando mit 503 beantwortet. Einbinden kann man das ganze dann z.B. via (x)inetd.
Man kann natürlich auf dem betreffenden Host auch gar nichts auf Port 25 lauschen lassen - wenn man sich denn um die Mailqueues von legitimen Servern, die evt. einliefern wollen, keine Gedanken macht
Exchange, Du bist so wunderbar
Geschrieben in
Technik
Donnerstag, 25. Oktober 2007
Anonymisierter Screenshot von 14:31 Uhr:
Der Server relayed Mails „ins Internet” via dediziertem SMTP-Gateway, welches in einer anderen Stadt steht. Die Standorte sind via privatem WAN verbunden. Man beachte:
Was schließen wir daraus, wenn die gesamte „active queue” mit sowas zugeballert ist? Genau, klassischer Fall von „congestion” bzw. „saturation”. Laut Auskunft des Verantwortlichen lag es am fehlerhaft funktionierenden Bandbreitenmanagement. Ursächlich vielleicht richtig. Daß das eigentliche Problem die Fehlkonfiguration der Exchange-Server war (man hätte die Anzahl der „delivery slots” für große Nachrichten limitieren müssen, um dieses Phänomen, i.e. Füllen der Queue mit erneuten Zustellversuchen von großen Nachrichten, die höchstwahrscheinlich wieder in einen Timeout laufen, zu verhindern, aber wahrscheinlich ist Exchange für sowas zu doof), davon war keine Rede. Funktioniert unter normalen Umständen ja schließlich auch problemlos. Und kann auch garantiert nie wieder vorkommen („eins ausrufezeichen elf ”).
Wieso lasse ich mich eigentlich immer wieder mit solchen Aussagen abspeisen? Ich meine, ich weiß es doch eigentlich besser. 300k Mails am Tag (auf meinen Kisten) sprechen halt eine deutliche Sprache. Muß an der Sympathie liegen, die ich für die Verantwortlichen empfinde. Die stammt übrigens noch aus dem Jahr 2002.
Nachtrag: Ich sollte die Reports von postfix-logwatch auch mal lesen. 634k am Tag, seit einer Woche nicht unter 600k.
Der Server relayed Mails „ins Internet” via dediziertem SMTP-Gateway, welches in einer anderen Stadt steht. Die Standorte sind via privatem WAN verbunden. Man beachte:
- Die Anzahl der Nachrichten in der Warteschlange (rechts unten).
- Den Absendezeitpunkt der ersten Nachricht (rechts oben).
- Die Größe der Nachricht, die derzeit zugestellt wird (oben Mitte) - und ja, alle Nachrichten, die er auszuliefern versucht hat, waren „relativ groß” und es waren alles Retries von großen Nachrichten.
Was schließen wir daraus, wenn die gesamte „active queue” mit sowas zugeballert ist? Genau, klassischer Fall von „congestion” bzw. „saturation”. Laut Auskunft des Verantwortlichen lag es am fehlerhaft funktionierenden Bandbreitenmanagement. Ursächlich vielleicht richtig. Daß das eigentliche Problem die Fehlkonfiguration der Exchange-Server war (man hätte die Anzahl der „delivery slots” für große Nachrichten limitieren müssen, um dieses Phänomen, i.e. Füllen der Queue mit erneuten Zustellversuchen von großen Nachrichten, die höchstwahrscheinlich wieder in einen Timeout laufen, zu verhindern, aber wahrscheinlich ist Exchange für sowas zu doof), davon war keine Rede. Funktioniert unter normalen Umständen ja schließlich auch problemlos. Und kann auch garantiert nie wieder vorkommen („eins ausrufezeichen elf ”).
Wieso lasse ich mich eigentlich immer wieder mit solchen Aussagen abspeisen? Ich meine, ich weiß es doch eigentlich besser. 300k Mails am Tag (auf meinen Kisten) sprechen halt eine deutliche Sprache. Muß an der Sympathie liegen, die ich für die Verantwortlichen empfinde. Die stammt übrigens noch aus dem Jahr 2002.
Nachtrag: Ich sollte die Reports von postfix-logwatch auch mal lesen. 634k am Tag, seit einer Woche nicht unter 600k.
Qmail-Zitat des Tages
dk-filter und libmail-domainkeys-perl für Debian/etch
Geschrieben in
Technik
Freitag, 5. Oktober 2007
Der Titel sagt alles - ich habe dk-filter in mein Repository geworfen und die für Spamassassin benötigte Version von libmail-domainkeys-perl gleich mit.
Die üblichen Disclaimer gelten!
Die üblichen Disclaimer gelten!
