RootForum Community

Hi zusammen,

der Titel ist leider eher nichtssagend, aber ich mir fiel nichts besseres ein. Mein Problem ist schon recht speziell:

Seit gefühlten zwei Tagen (und ich weiß nicht, was sich dort verändert haben soll) sind meine kompletten eingehenden Mails im Body leer!

Nach langem Suchen habe ich festgestellt, dass das an der Verbindung zwischen MTA und IMAP-Server liegt, wenn diese im selben Maildir arbeiten.

Reproduzierbar: Wenn ich den IMAP-Server stoppe, packt mein MTA neue Mails unter /home/mail01/mails/new ab, die Datei sieht dann so aus:

1338415769.V86If4f80cbM525985.vs251077.vserver.de:2,S

Wenn der IMAP-Server mitläuft, legt er die Mails von "new" nach "cur" und die Datei sieht so aus:

1338415897.M451244P3969.vs251077.vserver.de,S=253,W=262:2,

Stichprobenartig würde ich sagen, dass diese S- und W-Flags nur bei den korrupten Mails auftauchen.

Primär nutze ich Postfix mit Dovecot, habe aber sowohl Exim und auch Courier testweise probiert, macht keinen Unterschied.

Hat vielleicht irgendwer eine Idee? Ich bin mit meinem Latein am bitteren Ende :-?

Das der Imap Server abgerufene und herunter geladene emails nach cur verschiebt ist völlig normal.

Und auch der Dateiname ist völlig i.O.
1338403256.M388893P26100.wep001aa,S=15972,W=16349:2,S
Ich würde mal mit less oder anderem Tool prüfen, ob in der Mail de Body enthalten ist.
Oftmals liegt es am Client z.B. inkompatibler char set. z.B. utf8 versuse latin1.

Du betreibst doch opensuse? Über Probleme im Zusammenhang mit Horde bin ich auch schon mal gestossen und es lag tatsächlich an einem charset problem.

Nachdem einige Updates eingespielt wurden und das System rebootet wurde, war das Problem wieder behoben.
Das ist zwar kein toller Lösungsansatz aber das Problem bestand tatsächlich nur temporär.

Gegen das Verschieben per se habe ich ja nichts ;) Allerdings sind dann die Mails im Body leer. Direkt im Filesystem, auch wenn kein Client vorher dran war.

Die S- und W-Flags hatte ich bisher nicht, daher die Verwunderung.

Das Ganze läuft unter Debian 6 und ohne Groupware oder sonstigem Gedöns, reines Postfix und Dovecot (nicht selbstgebaut, alles aus den offiziellen Repos).

Was auch der Fall ist: Solange Dovecot gestoppt ist und die Mails unter "new" liegen, kann ich sie mit less lesen. Dort ist alles ok. Sowie ich Dovecot starte und die Mails unter "cur" landen, sind die Bodies leer. Von denselben Mails! Der Header passt (Subject, Date etc.), nur im Body ist kein Bit

Dann stell doch mal die Konfiguration zu postfix und dovecote mal ein.
Verschieben sollte dovecote erst, wenn die Emails abgerufen werden und nicht automatisch sofort. Das ist in der Tat merkwürdig. vielleicht fingert ja ein content Filter herum.
Das Filesystem selbst ist aber sauber?
checkfs ggf. ausführen und prüfen. Filesystem ist auch nicht voll gelaufen?

ddm3ve wrote:Dann stell doch mal die Konfiguration zu postfix und dovecote mal ein.

Im Prinzip ist das durch ein Stoppen des Dovecot Daemons gegeben oder?

Natürlich hast du Recht, die Mails werden verschoben, wenn irgendein Client das initiiert.

Einen Content-Filter gibt es auch nicht, auch keinen Anti-Viren-Scanner (mehr).

Ein fsck auf / kann ich nicht machen, da es für ReiserFS kein fsck auf dem System gibt. Dazu muss ich sagen, dass es sich um einen kleinen VServer von Server4You handelt.

Filesystem ist nicht voll, 13% disk used, 5% inodes used.

Stell hier dennoch mal die main.cf sowie die dovecote Konfiguration ein.
So ist es ein Rätsel raten erster Güte.

Reboot wäre ggf. noch eine Idee, wer weiss, ob Dein Provider dir nich einen neuen Kernel untergeschobene hat.

Welcher MDA und wie ist er konfiguriert?
Die Ausgaben von `postconf -n` und `doveconf -n` bitte.

dovecot.conf: http://pastebin.com/w29sFaig
main.cf: http://pastebin.com/hWKk0hvM

Reboot tat leider auch nicht gut ;)

Einen separaten MDA gibt es nicht.

Ähm, sind die Configs vollständig? Falls ja, dann hast Du ein Open-Relay und bei Dovecot könntest Du Dich gar nicht einloggen.

Poste bitte die Ausgaben von `postconf -n` und `doveconf -n` die sind zuverlässiger.

http://pastebin.com/0wXhEZzL

doveconf gibts auf dem System nicht, weder im PATH noch sonstwo als Binary.
Pakete sind aktuell.

Stimmt, bei dem alten Dovecot war es noch im Hauptbinary: Bei postconf war nichts disbezüglich Auffälliges zu finden.

http://pastebin.com/4TG8U8m5

Kann da irgendeine Art Locking reinspielen? Denn auch wenn ich Dovecot gegen Courier-Imap tausche, passiert das selbe. Ich schließe _eigentlich_ ein Bug in Dovecot aus

OK, auch sauber. Das macht die Fehlersuche nun deutlich schwieriger.

Kannst Du mal ein neues Mailkonto zum Debuggen anlegen und dann per Freemailer eine Testmail schicken. Den vollständigen Weg dieser Mail bitte im Maillog verfolgen und die entsprechenden Logzeilen hier posten.

Gegebenenfalls Postfix und Dovecot für diese Testmail(s) auf debug loggen lassen.

Was ich in seiner Postfix Konfig vermisse ist:

main.cf
virtual_transport = dovecot

Eventuell ist das ja gar nicht notwendig.

Und in der master.cf musste dann sowas zu finden sein:

dovecot unix - n n - - pipe flags=DRhu user=vmail:mail argv=/usr/lib/dovecot/deliver -d $(recipient)

Ob das bei Debian auch anders kann....

So legte ich den User an:
http://pastebin.com/tGgCEhhc

Hier das Postfix-Log nach dem Versenden via web.de:
Sorry für das Zensieren, aber ein Lookup-Problem liegt nicht vor und es geht um meine privaten Mails ;)
http://pastebin.com/e3wZSMtn

Wenn ich mir die Mail jetzt im Filesystem anschaue, ist alles ok:
http://pastebin.com/mrzKebv9

Nach einem Login per IMAP-Client (in dem Fall KMail) mit folgendem Log: http://pastebin.com/QnZgAsJN

--> Geht das!

Habe das gleiche Prozedere gerade nochmal an die besagte richtige Mailadresse geschickt, wieder leer.

Helfen die Logs davon auch?

Spontan fallen mir nur die fehlenden Hochkommata beim echo beim Anlegen des Mailkontos auf, wodurch die /etc/postfix/virtual eventuell teilweise unbrauchbar sein könnte.

Ja, die Logs einer Testmail zum kaputten Mailkonto wären nützlich.

ddm3ve wrote:Was ich in seiner Postfix Konfig vermisse ist:

main.cf
virtual_transport = dovecot

Eventuell ist das ja gar nicht notwendig.

Und in der master.cf musste dann sowas zu finden sein:

dovecot unix - n n - - pipe flags=DRhu user=vmail:mail argv=/usr/lib/dovecot/deliver -d $(recipient)

Ob das bei Debian auch anders kann....

Ich habe jetzt mal den Dovecot LDA konfiguriert..._irgendwie_ ist mir das wohl untergegangen :oops:

Die Mails haben wieder einen Body, zumindest vorerst. Mal abwarten, was die Stunden/Tage noch passiert. Ich kann nur nicht nachvollziehen, warum vorher alles funktioniert hat.

Vielen Dank euch beiden.

Gruß
dante

Leider zu früh gefreut...

Hier der Test der richtigen Empfängeradresse:

• Dovecot ist aus
• Postfix Log: http://pastebin.com/Lpt6a1Hp
• So schaut die Mail zugestellt aus: http://pastebin.com/E5bL2UeP
• Dovecot wird wieder aktiviert
• Resultat: http://pastebin.com/btXNnZK6

Was mir wieder auffällt sind diese Flags, die bei Mails, die vernünftig ankommen, nicht vorhanden sind.

Ich sehe in dem Resultat einen Header eines Anti-Virus-Produkts, der ist im Original nicht vorhanden und Anti-Viren-Produkte mit Schhluckauf sind nicht selten.

Hier etwas mehr Debugging Infos:

Die Zustellung der Testmailer-Mails klappen immernoch, also habe ich mal das eigentliche Postfach von mail01 weggesichert und komplett leer gemacht. Das Zustellen von Mails klappt dann auch.

Ich benutze kein Quota, jedenfalls nicht wissentlich. In diesem Fall sollte aber ein Bounce oder Temporary Fail kommen meine ich.

Einen Anti-Viren-Scanner ist auch nicht im Einsatz, daher wundert mich der entsprechende Header Eintrag.

So schaut das Postfach aus, aber Dovecot sollte damit eigentlich klarkommen:
Any ideas :? ?

Lass mich raten: Es tritt nur bei Mails auf, die HTML oder Links enthalten. Bei solchen Mails spielt so mancher Anti-Viren/Spam-Scanner gerne Reinigungskraft und putzt den Body blitzeblank. Daher musst Du erstmal diesen Anti-Viren/Spam-Scanner finden und ausschalten (lassen).

Der Header kommt jedenfalls weder von Postfix noch von Dovecot.

Und da die kaputte Mail in cur liegt, wurde sie definitiv von einem IMAP-Client angefasst und vermutlich auch vom Client auf Viren/Spam geprüft.

Joe User wrote:Lass mich raten: Es tritt nur bei Mails auf, die HTML oder Links enthalten.

Nein, Textmails waren auch betroffen.

Joe User wrote: Und da die kaputte Mail in cur liegt, wurde sie definitiv von einem IMAP-Client angefasst und vermutlich auch vom Client auf Viren/Spam geprüft.

Das war der entscheidene Hint!

Mein KMail hat mittels ClamAV diesen ganzen Mist verzapft. Als ich die entsrechenden Filter gesehen habe, kams mir auch wieder ganz dunkel...ich habe mal irgendwann vor einigen Tagen KMail und ClamAV verheiratet, aber eher unbewusst, darum hatte ich das schon wieder ganz vergessen ](*,)

Vielen Dank, das Problem sollte nun gelöst sein.

Gut, dass das nun doch noch einfach zu lösen war, sobald man eben Configs, Logs und Header hat.

Kleine Anmerkung nebenbei: ClamAV stinkt (nette Idee, miserable Umsetzung).
Wenn schon AV, dann lieber ein paar EUR/Jahr hinlegen und zumindest eine reellere Chance auf Entdeckung unliebsamer Codeschnipsel haben.

Sicherheit kann es nicht zum Nulltarif geben...