Ich habe Dovecot2 installiert und via yast der Firewall erklärt, dass die Ports für den Server freigegeben werden sollen. Dennoch kann ich den Server von entfernten Rechnern aus nicht erreichen. Ich habe versuche via telnet den Port 143 zu erreichen, aber dies scheitert, von verschiedenen Rechnern aus.
Wenn ich allerdings via ssh zum Server verbinde und dort dann eine Verbindung zu dovecot via telnet aufbaue, sehe ich dass der Server läuft und funktioniert.
Daher vermute ich, dass der Fehler irgendwo bei der Firewall liegt, allerdings habe ich diese via yast mehrfach neu eingestellt und neu gestartet, ohne dass Problem zu beheben.
Hat jemand eine Idee, wo das Problem liegen können?
In welcher Datei kann ich die Firewall-Einstellungen den Manuell ändern ?
Was hast du den an der Firewall eingestellt?
Vielleicht Source-Port 143 geöffnet??
Naja, ich habe in Yast halt aus der Liste den Dovecot-Server gewählt und “Hinzugefügt” für die “externe Zone”. Gehe davon aus, dass das dazu führt, dass die Ports für POP, IMAP und IMAPs freigegeben werden. Es gibt auch einen anderen Eintrag “Imap” als Server den man auswählen kann, den habe ich mal dazu mal raus genommen. Danach immer gespeichert. Yast startet ja da auch die Firewall mit den neuen Einstellungen, soweit ich sehe. Habe aber nie Verbindung von außen auf Post 143 bekommen.
Würde gerne jetzt für das Testen IMAP nutzen und IMAPs einrichten und später nur IMAPs offen haben und IMAP und POP3 geschlossen halten. Soweit das Endziel…
Bei der Zone musst du die gleiche auswählen wie die, die der Netzwerkadapter
hat. Kannst du unter Schnittstellen einstellen.
Wenn das nicht funktioniert, kannst du auch mal versuchen benutzerdefinierte
Regeln einzufügen.
Wenn auch das nicht funktioniert, kannst die die Firewall auch mal
kurzzeitig stoppen. Wenn du dann immer noch nicht auf den Server kommst,
liegt es nicht an der Firewall.
Zu IMAP/IMAPs: Du kannst auch über den Standard-Port 143 mit STARTTLS
verschlüsselte Verbindungen aufbauen. Jeder vernünftige Client unterstützt
TLS (Dovecot auch).
Such einfach mal nach “dovecot tls”. In Dovecot sollte die Option aber
sowieso schon aktiv sein.
Danke für den Tipp.
Ich habe die Firewall ausgeschaltet und dennoch keine Verbindung mit telnet zu dovecot bekommen, übrigens auch nicht zu Port 80 (apache2), was ich schon seltsam finde. Allerdings zu Port 22 (ssh).
Auch Thunderbird hat die Verbindung nicht hin bekommen.
Ich habe mit und ohne Firewall den Port-Scanner von Online Port Scan | Port Scanning | Port Scanner | Port Checker bemüht und in beiden Fällen wird behauptet der Server antworte auf Port 143 (imap).
Ich habe dann statt dem Windows-Telnet mal Putty verwendet um den Port anzusprechen und die Antwort war eine Meldung “Connection Closed by Remote Host”.
Auch dabei ist egal ob die Firewall läuft oder nicht.
EDIT: Okay, dass ist strange. Von einem Rechner habe ich mittlerweile Kontakt bekommen, mittels Putty, wenn ich statt “Telnet” die Übertragungsart “RAW” gewählt habe. Dovecot meldet dann zurück was es unterstützt und endet mit “dovecot ok”. Ich habe mit “a login user pass” eingeloggt und auch dass hat funktioniert. Erklärt wohl auch, warum der Portscanner sagt, der Port sein offen. Jetzt kapier ich aber noch weniger, warum Thunderbird den Server nicht einrichten kann.
Schon mal in die Logfiles von Dovecot geschaut? Wenn der Server auf Port 143
antwortet muss ja irgend ein Server laufen.
Habe ich rausgesucht und reingeschaut. Die erfolgreichen logins sind auch geloggt, aber wenn die Verbindung gar nicht zustande kommt, stand über den Versuch auch nichts im log.
Ich habe mal die entsprechende conf Datei so geändert, dass alles geloggt wird, was mir sinnvoll erschien, das brachte aber keine Änderung…
Sitzt der Rechner noch hinter einer anderen Firewall/NAT/etc.?
Dovecot sollte auch erfolglose Verbindungen mit loggen. Und nachdem Apache2
auch nicht funktioniert …
Spätestens wenn die Firewall deaktiviert ist, sollte die Verbindung klappen.
Nein, da ist keine andre Firewall oder sonst was.
Ich bin mit auch net sicher, dass Apache2 nicht funktioniert, sondern würde meinen, dass das Problem mit telnet zusammen hängt. Denn alle Browser zeigen http so an, wie sie sollten, nur https will nicht, aber das ist eine Baustelle die ich später weiter bearbeite. Es ist nur so, dass wenn ich mit telnet (Windows) den Port 80 aufrufe keine Verbindung zu Stande kommt. Tut es aber mit putty (Windows) auch nicht.
Da aber der Online-Portscanner und putty (in der Methode raw statt telnet) wohl eine Verbindung zu dovecot bekommen, scheint das ja zu klappen. Was ich halt nicht verstehe, ist wieso Thunderbird das nicht hin bekommt…
Kann es sein, dass Failed Attempts, bei denen nicht mal das Passwort übermittelt wurde sondern einfach nichts passierte einfach nicht geloggt werden?
Ich bin nicht sicher, was Dovecot alles logt. Hast du die Optionen
aktiviert:
http://wiki.dovecot.org/Logging
Hast du vielleicht mal einen anderen Client als Thunderbird probiert?
Ich habe die dovecot logs angesehen. Wenn ich von der Konsole aus mittels telnet den Port 143 anspreche und ein- und auslogge wird das protokolliert.
Aber Versuche vom meinem Rechner aus scheitern.
Interessanter Weise kann ich von anderen Rechnern aus nun Zugreifen.
Es kann sein, dass der Fehler also nicht mehr besteht und die Probleme mit dem Zugriff von meinem Rechner auf eine Sperrung von Port 143 zurück zu führen ist.
Allerdings habe ich von dem anderen Rechner aus versucht mit Windows Mail den Server zu erreichen und während das einloggen klappt und auch geloggt wird, scheitert er beim Zugriff auf den Posteingang. Der Server teilt einen Serverfehler an Windows Mail mit, loggt aber keinen näheren Infos…
Ich verwende Windows Mail nicht, aber vielleicht hilft der der Auszug aus
der meiner dovecot.conf:
Workarounds for various client bugs:
delay-newmail:
Send EXISTS/RECENT new mail notifications only when replying to NOOP
and CHECK commands. Some clients ignore them otherwise, for example
OSX
Mail (<v2.1). Outlook Express breaks more badly though, without this
it
may show user “Message no longer in server” errors. Note that OE6
still
breaks even with this workaround if synchronization is set to
“Headers Only”.
netscape-eoh:
Netscape 4.x breaks if message headers don’t end with the empty "end
of
headers" line. Normally all messages have this, but setting this
workaround makes sure that Netscape never breaks by adding the line
if
it doesn’t exist. This is done only for FETCH BODY[HEADER.FIELDS…]
commands. Note that RFC says this shouldn’t be done.
tb-extra-mailbox-sep:
With mbox storage a mailbox can contain either mails or
submailboxes,
but not both. Thunderbird separates these two by forcing server to
accept ‘/’ suffix in mailbox names in subscriptions list.
The list is space-separated.
#imap_client_workarounds =