Nun hab ich den ganzen Sonntag Nachmittag über meinem Mailserver gesessen und dabei einige eklatante Probleme zumindest beseitigen können. Netterweise hat mich Tormentor drauf hingewiesen, daß mein postfix eine ziemliche Spam-Schleuder sein könnte – der SMTPd war offenen wie ein Scheunentor. Wie das passieren konnte ist mir dabei aber etwas unklar, immerhin war er eigentlich mit SASL2 abgedichtet.

So richtig gefunden hab ich den Fehler letztlich auch nicht – zumindest tendiere ich dazu es nicht zu verstehen. Im Prinzip habe ich nach einem Haufen HowTos lediglich zwei Einträge in der /etc/postfix/main.cf ergänzt:

smtpd_sasl_path = smtpd
smtpd_recipient_restrictions = permit_sasl_authenticated, permit_mynetworks, permit_mx_backup, reject_unauth_destination, check_relay_domains

Letzterer Eintrag war schon soweit vorhanden, jedoch wurd er um die letzten drei Optionen nur noch ergänzt. Jedenfalls verwirft postfix nun Mails von Usern, die sich nicht per erfolgreichem Abgleich mit der SASLDB am Server angemeldet haben.

Danach stand das Zusammenspiel zwischen AMaViS und postfix an. Auch da hab ich an der Konfiguration letzten Endes nicht viel verändert. Im Prinzip habe ich den AMaViS-Daemon nur auf die IP des vServers hören lassen. Nun jagt postfix eingehende Mails auch durch AMaVis, aber irgendwie ist da noch ein Port zu viel nach Außen offen.

Zu guter Letzt hab ich mich noch an einigen serverseitigen Sortierungen via procmail versucht, was soweit immerhin auch bisher erfolgreich erscheint. Nun müßte man wohl nur noch diese ominösen Bayes-Filter von AMaViS trainieren, wenn ich das System dahin zumindest richtig verstanden hab.

Mailserver sind und bleiben für mich einfach ein Buch mit sieben Siegeln. Das neben mir liegenden “Postfix-Buch” aus dem Open Source Press-Verlag ist ja immerhin auch vom Schwierigkeitsgrad des Themas her für “Gurus” (es gibt noch Novice und Wizard) eingestuft.

und ich kann in Ruhe die Migration des IMAP vom Gateway auf den vServer in Angriff nehmen. Vielleicht sogar schon morgen – obwohl es eher unrealistisch erscheint.

Aus einem Tag sind nun auch wieder zwei Wochen geworden und so richtig motiviert war ich nicht wirklich, als ich das Thema “vServer & IMAP” gestern angegangen bin. Jedoch brauchte es nicht zwingend eines besonderen Konfigurationsaufwandes. Immerhin lief hier schon der courier-pop3 Server und entsprechend dieser Konfiguration nimmt auch der IMAPd Verbindungen entgegen. Also für ein 1-Personen-System nichts großartiges mit MySQL-Tabellen und übermäßigem bearbeiten von Konfig-Dateien. Wie “sicher” das ist will ich aber grad in diesem Moment nicht wirklich wissen.

Naja, aber mal im Ernst – auch wenn POP3 über authpam(?) zumindest zufriedenstellend abgesichert ist und den lokalen User anspruchsvolle Passwörter zugewiesen wurden sollte das hoffentlich soweit reichen. Wichtiger ist da vermutlich, daß der postfix nicht als offene Spam-Maschine arbeitet. Nach der großen Hürde den IMAPd zu installieren brauchte ich also nur noch mein Maildir vom lokalen Server zum vServer kopieren. Performance ist – bei meinen paar Mails – durchaus akzeptabel.

Dann muß ich mich über meine eigene Ungeschicktheit hier mal auslassen: Seit mehreren Jahren läuft ein IMAP hier bei mir und ich bin die ganze Zeit zu blöd gewesen die Mail-Clients so zu konfigurieren, das ausgehende Mails im “Sent“-Ordner auf dem IMAP landen. Ich hätte einige ausgehende Mails mehr archivieren können.

Zu guter Letzt wollt ich mich noch an Filterwerkzeugen für Spam und Viren probieren, aber trotz des durchaus guten und umfangreichen HowTos von debianhowto.de zum Thema amavis kann ich in der Hinsicht keinen positiven Vollzug vermelden. postfix meldet in den Logfiles:

babytux postfix/qmgr[3806]: 06D25C4596: to=, relay=none, delay=1153, delays=1153/0/0/0, dsn=4.3.0, status=deferred (mail transport unavailable)
babytux postfix/qmgr[3806]: warning: connect to transport amavis : Connection refused

Wer gerne einen Blick in die Konfigurations-Dateien werfen mag, darf sich gerne melden. Irgendwie komm ich da zur Zeit nicht weiter. Vielleicht hilfts ja schon, wenn man einmal drüber schläft.

Es wurd langsam aber sicher mal Zeit, den vServer auf die aktuellste Stable-Version von Debian zu aktualisieren. Immerhin wurde Debian 4.0 aka Etch schon Anfang April veröffentlicht. Mit einem Backup der Daten im Rücken wurde die sources.list angepaßt und schon ratterterten die Status- und Erfolgsmeldungen durch’s Terminal. Bis auf – ja, bis auf … wieso sollte es auch mal direkt auf Anhieb glatt laufen?

Jedenfalls wollte sich proftpd mit dem MySQL-Modul nicht aktualisieren lassen. Ein paar --force-all und dem Überschreiben der alten Config-Datei später konnte dann proftpd erfolgreich ins System geprügelt werden. Lediglich meckerte nun der FTP-Client bei einem Verbindungsaufbau:

Protocol violation by server: blank line on control.
Remote host has closed the connection.

“Beheben” konnt ich den Fehler damit, daß ich in /etc/proftpd/modules.conf den Eintrag für das PostgreSQL-Modul (LoadModule mod_sql_postgres.c) auskommentiert habe. Jedenfalls läuft’s jetzt wieder und ich kann in Ruhe die Migration des IMAP vom Gateway auf den vServer in Angriff nehmen. Vielleicht sogar schon morgen – obwohl es eher unrealistisch erscheint.

Der ein oder andere neugierige Besucher mag es evtl bemerkt haben: Mein vServer hatte eine Downtime. Diesmal eine durchaus gewollte. Gestern habe ich ein Upgrade auf das neue Angebot bei meinem derzeitigen Hoster beauftragt, welches dann heute Nachmittag durchgeführt wurde. Nennenswerte Probleme traten dabei nicht auf. Das ein oder andere war noch zu prüfen, die ein oder andere IP noch zu aktualisieren. Neben den 5GB mehr Plattenplatz darf man nun auch den

Image by Actu-Lan.com

hostname des Systems frei vergeben, wie noch das ein oder andere auch nützliche Gimmick mehr. Jedenfalls bin ich nun “glücklich“. Die Suche hat ein Ende, ich bekomm ein IMHO gutes Preis/Leistungs-Verhältnis und weiß beim Support, was ich hab. Der ist bei vollmar.net nämlich wirklich sehr gut. Freundlich, unkompliziert, schnell, informativ – ja und durchaus kompetent. Das zahlt sich in meinen Augen letztlich doch aus.

Nun bin ich nur noch gespannt, ob MRTG weiterhin so will, wie ich mir das vorstelle, oder ob ich da auch mal wieder ‘n Crash-Kurs drin belegen muß. Ansonsten kann /var/log/apache/access.log nun fröhlich die noch freien 6,6GB füllen. Nochmal für alle, die möglicherweise auch auf der Suche sind:

Vollmar vServer v2

• 28 vServer/Host (Dual-Core)
• 10GB Festplatte (SATA2 RAID)
• 10GB Backup-Space
• 200GB Traffic (Cisco-Network)
• 0,29 Euro/GB Mehrtraffic
• wahlweise SuSE-, Debian- oder Ubuntu-Linux
• Debian incl. syscp
• nur ¤ 9,95 Monat
• Einrichtungsgebühr:
  • ¤ 19,95 Euro bei 3 Monaten Laufzeit
  • ¤ 0,- bei 12 Monaten Laufzeit
• monatliche Abbuchung möglich
• 1 IP
• Domain kost extra
• rDNS

Image by Actu-Lan.com

Wer erinnert sich noch dunkel an die bisher erfolglos verlaufende Suche nach einem neuen vServer? Vornehmlich waren mir die 5GB Plattenplatz zu wenig, weswegen ich mich nach Alternativen zum aktuellen Hoster umgesehn habe. Wie bekannt, konnte ich mich bisher nicht dazu durchringen, eines der seltenen, attraktiven Angebote anzunehmen. Letztlich vielleicht gar kein so großer Fehler. Bei commanderx bin ich drüber gestolpert,

daß vollmar.net ein neues Angebot für vServer im Programm hat. Scheinbar auch erst seit Kurzem. Warum also in die Ferne schweifen, wenn das – hoffentlich – Gute so nah liegt? Kurz hier nochmal die “Features” zusammen gefaßt:

• 10GB Festplatte (SATA2 RAID)
• 10GB Backup-Space (unerheblich – vServer Backup liegt auf meinem Router)
• 200GB Traffic (Cisco-Network)
• wahlweise SuSE-, Debian- oder Ubuntu-Linux (*seufz* überall Ubuntu)
• nur 9,95 Euro/Monat (zZgl Domain-Kosten)

Nun werde ich noch den Erfahrungsbericht des “Umzugs” von commanderx abwarten und danach hoffentlich/vermutlich bald ebenfalls einen Umzug auf das neue Angebot anstreben. Ich nehme an, solche Klimmzüge wie Domaintransfer und unfangreicher Neukonfiguration fallen dabei nämlich weg. Dann könnte man die gewonnene Zeit auch dafür nutzen, den vServer auf “Etch” zu aktualisieren.