Postfix,Cyrus Imap 2.2,CLAMAV,MYSQL – Inst mit Tücken
Posted by Olli on 19. Oktober 2008 under .NET, mal kurz erklärt | 
Schreibe den ersten Kommentar
Heute mal ein Erfahrungsbericht aus 12 Stunden Mailserverinstallationserfahrungen.Nein Erfahrungen ist falsch. Sagen wir lieber mal Armageddon…. 
Wer dem ersten Link folgt und danach meinen zusätzlichen Tipps und Anmerkungen folgt, sollte selbigen innerhalb von 2 Stunden aufsetzen können.
Follow NOW Hierlang..Genau hier..Traut..euch
Genau das habe ich gemacht. Alles neu gestartet und versucht mit I-Mail auf den IMAP Port des Servers zuzugreifen. Es kam wie erwartet. Error…Tilt.. Du kommst hier net rein. Mein Client sagte
"Authorisation fehlgeschlagen"
Ja herrlich den Fehler mag ich ja am liebsten. Schnell in die Serverlogs geschaut. Ja Serverlogs. Wir hätten da im Angebot auth.log – mail.info – mail.log – syslog – mail.err
Dazu muss ich sagen, dass ich wie im Howto Debian Etch benutze. Zurück zum Log. Lang suchen musste ich nicht, denn der Fehler wurde in allen 5 Logs angezeigt.
Failed password for invalid user "mein test user" from "x.x.x.x"
Tolle Log Ausgabe, oder? Und mit dieser Meldung schlug ich mich nun 3 – 6 Stunden rum. Nachdem ich mich mal ein etwas konzentriert habe, nagut nachdem ich irgendwann das Bier beiseite gestellt habe ( ohne machts einfach kein Spass, da könnte ich ja auch in der Firma sitzen ) viel mir ein, das mein test user eigentlich nur in der MySQL DB existiert. Nur wadd funzt da nicht?
pam_mysql ? oder saslauthd ?
Wasn Glück das uns der syslog Deamon ja die PID`s mit rausrückt. Also ein flauschiges
strace -e open -p <PID>
und den Mail Client wieder bemüht. Na schau an, der saslauthd zieht sich die /etc/pam.d/imap ( HEUREKA – steht auch im WIKI ) und ruft darauf hin mit den Parametern /lib/security/pam_mysql.so auf.
Und wie hilft mir das jetzt? Durch exzessives googlen fand ich dann heraus das es einen Paramter verbose für den pam_mysql gibt. Wenn man diesen dann in /etc/pam.d/imap setzt, kann man den ersten van-der-veldschen Freudentanz aufführen. Denn nun erscheint ein komplettes SQL Statement im Log. Halt der Parameter, so sieht er aus.
auth sufficient pam_mysql.so user="User" passwd="PWD" host=127.0.0.1 db="DB" table=accountuser
usercolumn=username passwdcolumn=password crypt=1 logtable=log logmsgcolumn=msg
logusercolumn=user loghostcolumn=host logpidcolumn=pid logtimecolumn=time verbose=0
Und was schiesst uns sofort ins Auge? Der User erscheint kleingeschrieben. Wir haben den User aber in großen Lettern angelegt. Der Fehler ist nun klar, anscheinend substituiert das pam_mysql Modul den Usernamen. Die Lösung, grundsätzlich die Mailuser in kleinen Lettern anlegen.
Nachdem der Zugriff nun endlich funktioniert erscheinen diverse Meldungen vom Typ “file not found” im Log. Mir ist aufgefallen das nach der Installation per aptitude noch einige Directories fehlen. Unter anderem für spamassasin. Hier sollte man das Work Directory per Hand anlegen und dies in der /etc/default/spamassasin konfigurieren.
OPTIONS="--create-prefs --max-children 5 -x -u nobody --virtual-config-dir=/var/cache/spamassassin"
Das Directory /var/cache/spamassassin legen wir natürlich an und vergeben die
Rechte nobody:nogroup. Falls noch weitere Directories fehlen müssen auch diese angelegt werden. Dabei immer auf die Owner der Prozesse achten cyrus,root,nobody
Der letzte große Fallstrick war eigentlich keiner, sondern die Funktionalität von postgrey. Falls ihr postgrey einsetzt werden grundsätzlich die ersten Mails die ihr an euren neuen Mailserver schickt gebounct, also abgelehnt. Dies nennt man greylisting. Hintergrund dafür ist, das man davon ausgeht, das Spam nur einmal geschickt wird, wird diese Mail abgelehnt wird sie nicht nochmal geschickt. Richtige Mailprovider ( WEB:DE / GMX) versuchen dagegen die Mail noch ein zweites Mal zuzustellen. Beim zweiten Mal erkennt Postgrey das Absender,Empfänger und Provider schonmal ne Mail loswerden wollten und lässt diese durch. Kann man in den Logs sehr schön nachvollziehen.
Eins noch zum Schluss, macht nicht den gleichen Fehler wie ich und konfiguriert euch am Mailserver tot, vergesst aber eure Domainkonfiguration. Bei meinem Domainhoster zeigten die MX Records noch zum Domainanbieter selbst und nicht zu meinem Rootserver. So könnt ihr zwar Mails schicken aber mit dem emfpangen wirds schwer…
Kommentar