Courier-IMAP bricht öfters bestehende Verbindung ab

GwenDragon

Registered User
Anscheinend bricht bei Courier-Imap öfters mal die Verbindung zum Client ab.
Der Client meckert dann: Connection unexpectedly closed

Zu wenig Verbindungen können es eigentlich nicht mehr sein, denn in der /etc/courier-imap/imapd habe ich die Anzahl der Verbindungen schon länger auf MAXPERIP=10 gesetzt.

Ich finde nach greppen der Zeit:
Code:
/var/log/mail.log:Nov  7 09:21:09 server2 imapd: Unexpected SSL connection shutdown.
/var/log/mail.log:Nov  7 09:21:09 server2 imapd: 1320654069.442085 DISCONNECTED, user=test@******.de, ip=[::ffff:87.140.***.***], headers=0, body=0, rcvd=78, sent=648, maildir=/var/qmail/mailnames/********.de/test/Maildir
Nur seltsam, weil der Client auf das Konto gar nicht per SSL zugreift.

Das System ist:
Debian 6
Courier-IMAP (psa-courier-imap 3.08-debian6.0.build1012110621.15)

Kennt jemand solche Probleme?
 
Ich konnte mittlerweile die Abbrüche der IMAP-Verbindung (nach 30 Minuten oder mehr) mit Claws, Thunderbird, Opera und TheBat nachvollziehen.

Was kann ich beim Server tun, damit der Server nicht die Verbindung kappt?
Oder ist das ein Courier-Bug allgemein oder gar ein Problem des Plesk-Pakets?
 
Schau mal in deiner Courier-Config, welches .pem-File als Zertifikat verwendet wird und überprüf das mal mit openssl.

Code:
openssl x509 -noout -text -in /path/to/cert.pem

Idee dahinter ist der letzte Post in diesem Thread.
 
Das Zertifikat ist gültig, die Überprüfung bringt keinerlei Fehler.

Würde mich wundern, wenn es nicht wäre. Es wird ja mit Couriers Programm mkimapdcert erzeugt.

Außerdem erklärt sich dadurch nicht, warum die Abbrüche erst nach ca. 1/2 Stunde oder länger passieren. Wäre das Zertifikat ungültig, käme doch gar keine Verbindung zustande!
 
Wie sehen denn die Zeilen für IMAP_CAPABILITY und IMAP_ENHANCEDIDLE in deiner /etc/courier-imap/imapd aus?
 
Zeilen für IMAP_CAPABILITY und IMAP_ENHANCEDIDLE
gern.

egrep "(IMAP_CAPABILITY|IMAP_ENHANCEDIDLE)" /etc/courier-imap/imapd:
Code:
##NAME: IMAP_CAPABILITY:1
# IMAP_CAPABILITY specifies what most of the response should be to the
# authentication (see INSTALL), set IMAP_CAPABILITY as follows:
# IMAP_CAPABILITY="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=CRAM-SHA1 IDLE"
IMAP_CAPABILITY="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=PLAIN IDLE"
##NAME: IMAP_CAPABILITY_ORIG:1
IMAP_CAPABILITY_ORIG="IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA AUTH=CRAM-MD5 AUTH=CRAM-SHA1 AUTH=PLAIN IDLE"
##NAME: IMAP_CAPABILITY_TLS:0
# IMAP_CAPABILITY
IMAP_CAPABILITY_TLS="$IMAP_CAPABILITY"
IMAP_CAPABILITY_TLS_ORIG="$IMAP_CAPABILITY_ORIG"
##NAME: IMAP_ENHANCEDIDLE:0
# IMAP_ENHANCEDIDLE to 1 enables enhanced IDLE mode, where multiple
# in the IMAP_CAPABILITY list.
IMAP_ENHANCEDIDLE=0

ENHANCED_IDLE konnte ich nie aktivieren, trotz Installation von gamin und dessen Aktivierung für das fs ext3!
Siehe:
 
Last edited by a moderator:
Die Seite habe ich auch schon geshen, danke - nur: IDLE funktioniert ja, nur ENHANCEDIDLE nicht.
Ob das wirklich das Problem ist. :confused:

Wenn IDLE nicht funktionieren würde, müsste es ja gleich Probleme geben.
Davon mal ganz abgesehen, dass ohne ENHANCEDIDLE Courier dann alle 60 Sekunden die Verzeichnisse pollt.
 
Mein derzeitiger Workaround:
 
Plesks Courier-IMAP hat wohl immer noch erhebliche Probleme mit IDLE.
imapd: Unexpected SSL connection shutdown.
kommen immer wieder vor, trotz Erhöhung der Anzahl erlaubter Verbindungen über MAXPERIP und MAXDAEMONS.
 
Back
Top