Mittwoch, 26. März 2008
ORDB kills my mail
Heute früh habe ich mich gewundert, wo denn meine tägliche Portion Spam bleibt.
Mein privater Linux-Rechner ruft hier brav periodisch die Mails vom Webserver ab, und zwar mittels fetchmail.
Der fing gestern gegen 16 Uhr an, Mails einfach stur abzuweisen:
Erst nach längerer Recherche kam ich darauf, dass mein Exim-MTA folgende Eintragung hatte:
Der ORDB.org-Server meldete jedoch schon seit 2006, dass er nicht mehr benutzt werden will. Das habe ich einfach mal überlesen, und seit gestern wies er die Mails wohl hart ab. Nach Deaktivierung kam dann wieder alles rein, aber die Mails von gestern Nacht sind im Nirvana verpufft.
Die Moral von der Geschicht: Rejection Blacklists ab und zu mal auf Funktionsfähigkeit testen. Mehr Details auf heise, deren Nachricht für mich leider 4 Stunden zu spät kam.
Mein privater Linux-Rechner ruft hier brav periodisch die Mails vom Webserver ab, und zwar mittels fetchmail.
Der fing gestern gegen 16 Uhr an, Mails einfach stur abzuweisen:
CODE:
Mar 25 17:26:51 mostlyharmless fetchmail[8666]: reading message gh@mailserver:1 of 1 (12335 octets) (log message incomplete)
Mar 25 17:26:51 mostlyharmless fetchmail[8666]: SMTP error: 550 mail from 127.0.0.1 rejected: administrative prohibition (host is blacklisted)
Mar 25 17:26:51 mostlyharmless fetchmail[8666]: can't even send to garvin!
Mar 25 17:26:51 mostlyharmless fetchmail[8666]: SMTP error: 550 mail from 127.0.0.1 rejected: administrative prohibition (host is blacklisted)
Mar 25 17:26:51 mostlyharmless fetchmail[8666]: can't even send to garvin!
Erst nach längerer Recherche kam ich darauf, dass mein Exim-MTA folgende Eintragung hatte:
CODE:
rbl_domains = or.orbl.org/warn : spews.relays.osirusoft.com/warn : ordb.org/reject
Der ORDB.org-Server meldete jedoch schon seit 2006, dass er nicht mehr benutzt werden will. Das habe ich einfach mal überlesen, und seit gestern wies er die Mails wohl hart ab. Nach Deaktivierung kam dann wieder alles rein, aber die Mails von gestern Nacht sind im Nirvana verpufft.
Die Moral von der Geschicht: Rejection Blacklists ab und zu mal auf Funktionsfähigkeit testen. Mehr Details auf heise, deren Nachricht für mich leider 4 Stunden zu spät kam.
Mittwoch, 12. März 2008
Work-Notiz: Symlinks und ProFTPD
Schon lange kein Web-Entwickler-Content mehr hier, dem kann Abhilfe geschaffen werden.
Ich habe daheim einen kleinen Linux-Server, der mir als Mail+Fileserver, Router und Spielwiese dient. Eigentlich ist es ein Single-User-System, weshalb ich wenig Aufwand dazu betreibe das Permission-System von Linux vollständig aufzudröseln und einzusetzen.
Wie auch immer, dort habe ich gelegentlich Dateien, die ich anderen Personen oder Freunden über FTP bereitstellen möchte. Dafür läuft bei mir ProFTPD, und über angelegte Linux-User kommen die Personen direkt in ihr Homedir. Da die Dateien für sie aber meist tief verschachtelt in meiner eigenen Filesystem-Hierarchie liegen, habe ich bisher immer nur einen symbolische Verzeichnislink im Homedir der User angelegt um auf meine Dateien zu verweisen.
Bis ich heute dann nebenbei bemerkte, dass das bei ProFTPD ein kapitales Problem eröffnet: Die FTP-User kommen auch aus ihrem homedir heraus auf jede andere Hierarchie des Servers. Und da liegt ja dann doch ab und an irgendwas, was man eigentlich nicht anbieten möchte (Geheimdienstakten, Terrorpläne und meine Nacktfotos).
Nachdem ich in der proftpd.conf die Zeile DefaultRoot ~ eingefügt hatte, war die Sache Geschichte. Jeder User kommt aus seinem Homedir nun nicht mehr raus. Aber dafür halt auch nicht in die symlink-Verzeichnisse rein - auch doof.
Ein kurzes Googeln hat mir die Lösung offenbart: Anstelle von Symlinks einfach self-mounts benutzen:
mount --bind /usr/development/downloads /home/guest/download
Somit wird quasi ein auf dem Server existierendes Verzeichnis nochmals im User-Verzeichnis gemounted, und der User kann trotz chroot drauf zugreifen.
Ich habe daheim einen kleinen Linux-Server, der mir als Mail+Fileserver, Router und Spielwiese dient. Eigentlich ist es ein Single-User-System, weshalb ich wenig Aufwand dazu betreibe das Permission-System von Linux vollständig aufzudröseln und einzusetzen.
Wie auch immer, dort habe ich gelegentlich Dateien, die ich anderen Personen oder Freunden über FTP bereitstellen möchte. Dafür läuft bei mir ProFTPD, und über angelegte Linux-User kommen die Personen direkt in ihr Homedir. Da die Dateien für sie aber meist tief verschachtelt in meiner eigenen Filesystem-Hierarchie liegen, habe ich bisher immer nur einen symbolische Verzeichnislink im Homedir der User angelegt um auf meine Dateien zu verweisen.
Bis ich heute dann nebenbei bemerkte, dass das bei ProFTPD ein kapitales Problem eröffnet: Die FTP-User kommen auch aus ihrem homedir heraus auf jede andere Hierarchie des Servers. Und da liegt ja dann doch ab und an irgendwas, was man eigentlich nicht anbieten möchte (Geheimdienstakten, Terrorpläne und meine Nacktfotos).
Nachdem ich in der proftpd.conf die Zeile DefaultRoot ~ eingefügt hatte, war die Sache Geschichte. Jeder User kommt aus seinem Homedir nun nicht mehr raus. Aber dafür halt auch nicht in die symlink-Verzeichnisse rein - auch doof.
Ein kurzes Googeln hat mir die Lösung offenbart: Anstelle von Symlinks einfach self-mounts benutzen:
mount --bind /usr/development/downloads /home/guest/download
Somit wird quasi ein auf dem Server existierendes Verzeichnis nochmals im User-Verzeichnis gemounted, und der User kann trotz chroot drauf zugreifen.
