Suse9: fetchmail-Daemon -> Authentication error
Hallo Zusammen, gleich eines Vorweg, der Spruch "Never touch a running System" ist mir sehr wohl bekannt. Trotzdem konnte ich es nicht lassen meinen alten Server mit Suse 8.2 platt zu machen und mal wieder komplett neu (mit Suse 9 Prof.) aufzusetzen. Auf dem Server habe ich die Settings meines alten Mailservers (Fetchmail - Postfix - AntiVir - Spamassassin - Cyrus) soweit wieder hinbekommen. Aus Gründen, die sich meiner Kenntnis entziehen, will fetchmail nicht mehr so richtig. Hole ich meine Mails manuell ab, so klappt das wunderbar. Möchte ich fetchmail als Daemon laufen lassen, werden die Mails vom Mailserver meines Webhosters beim ersten mal abgeholt, bei den folgenden polls kommt dann nur noch folgende Log-Meldung: fetchmail: 6.2.3 querying pop3.foo.de (protocol POP3) at Tue Nov 18 21:57:38 2003: poll started fetchmail: POP3< +OK ready fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows fetchmail: POP3< TOP fetchmail: POP3< USER fetchmail: POP3< LOGIN-DELAY 0 fetchmail: POP3< EXPIRE 0 fetchmail: POP3< UIDL fetchmail: POP3< RESP-CODES fetchmail: POP3< AUTH-RESP-CODE fetchmail: POP3< X-MANGLE fetchmail: POP3< X-MACRO fetchmail: POP3< X-LOCALTIME Tue, 18 Nov 2003 21:57:38 +0100 fetchmail: POP3< . fetchmail: POP3> STLS fetchmail: POP3< -ERR Command not enabled fetchmail: Command not enabled fetchmail: POP3> CAPA fetchmail: POP3< +OK Pop server at server16.glai.de signing off. fetchmail: POP3> USER web###p1 fetchmail: POP3> PASS fetchmail: Unknown login or authentication error on web###p1@pop3.foo.de fetchmail: POP3> QUIT Um auszuschließen, dass es sich dabei um ein Problem bei meinem Hoster (Global Interactive) handelt, habe ich mich mit dessen Support in Verbindung gesetzt. Nach Auskunft des Supportmitarbeiters, sei dies ein Problem mit der Authenifizierung, das über den tcp-Port 113 zwischen Client und Server ausgehandelt wird. Daraufhin habe ich an meinem Hardware-Router den Port 113 aufgemacht, jedoch ohne Erfolg. Das Problem bleibt nach wie vor. Unter Suse 8.2 ist das .fetchmailrc-Skript ohne Probs gelaufen. Seit ich nun die 9.0 drauf habe geht nix mehr ;-((( Gab es größere Änderungen bei fetchmail oder verwandten Paketen, die ich möglicherweise nicht berücksichtigt haben könnte? Für jeden Hinweis bin ich dankbar. Gruß Andreas
Am Donnerstag, 20. November 2003 11:50 schrieb Andreas Rau:
gleich eines Vorweg, der Spruch "Never touch a running System" ist mir sehr wohl bekannt. Trotzdem konnte ich es nicht lassen meinen alten Server mit Suse 8.2 platt zu machen und mal wieder komplett neu (mit Suse 9 Prof.) aufzusetzen.
Auf dem Server habe ich die Settings meines alten Mailservers (Fetchmail - Postfix - AntiVir - Spamassassin - Cyrus) soweit wieder hinbekommen.
Aus Gründen, die sich meiner Kenntnis entziehen, will fetchmail nicht mehr so richtig. Hole ich meine Mails manuell ab, so klappt das wunderbar.
Was heisst "manuell" ? Starte mal fetchmail mit "-vvv" dann sagt er ganz ganz viel und vergleiche mal die ausgaben daemon/manuell.
Möchte ich fetchmail als Daemon laufen lassen, werden die Mails vom Mailserver meines Webhosters beim ersten mal abgeholt, bei den folgenden polls kommt dann nur noch folgende Log-Meldung:
fetchmail: 6.2.3 querying pop3.foo.de (protocol POP3) at Tue Nov 18 21:57:38 2003: poll started fetchmail: POP3< +OK ready fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows fetchmail: POP3< TOP fetchmail: POP3< USER fetchmail: POP3< LOGIN-DELAY 0 fetchmail: POP3< EXPIRE 0 fetchmail: POP3< UIDL fetchmail: POP3< RESP-CODES fetchmail: POP3< AUTH-RESP-CODE fetchmail: POP3< X-MANGLE fetchmail: POP3< X-MACRO fetchmail: POP3< X-LOCALTIME Tue, 18 Nov 2003 21:57:38 +0100 fetchmail: POP3< . fetchmail: POP3> STLS
Wieso versucht Dein fetchmail das denn? Hast Du das manuell gesetzt?
fetchmail: POP3< -ERR Command not enabled fetchmail: Command not enabled fetchmail: POP3> CAPA fetchmail: POP3< +OK Pop server at server16.glai.de signing off. fetchmail: POP3> USER web###p1 fetchmail: POP3> PASS fetchmail: Unknown login or authentication error on web###p1@pop3.foo.de fetchmail: POP3> QUIT
Um auszuschließen, dass es sich dabei um ein Problem bei meinem Hoster (Global Interactive) handelt, habe ich mich mit dessen Support in Verbindung gesetzt. Nach Auskunft des Supportmitarbeiters, sei dies ein Problem mit der Authenifizierung, das über den tcp-Port 113 zwischen Client und Server ausgehandelt wird. Daraufhin habe ich an meinem Hardware-Router den Port 113 aufgemacht, jedoch ohne Erfolg. Das Problem bleibt nach wie vor.
Hmm, also den Port aufzumachen, reicht nicht wirklich. Wenn Du den schon benutzen willst, muss da auch was lauschen. 113 ist identd, dazu gibt es einen Daemon, der muss dann installiert und getsartet sein. Wäre mir aber jetzt nicht so sicher, ob es überhaupt daran liegt. Den habe ich noch nie gebraucht und der wird auch in letzter Zeit aus Sicherheitsgründen nicht mehr installiert.
Unter Suse 8.2 ist das .fetchmailrc-Skript ohne Probs gelaufen. Seit ich nun die 9.0 drauf habe geht nix mehr ;-(((
Gab es größere Änderungen bei fetchmail oder verwandten Paketen, die ich möglicherweise nicht berücksichtigt haben könnte?
Für jeden Hinweis bin ich dankbar.
-- Andreas
Hallo, nachdem ich jetzt noch einige Tests mit dem fetchmailrc-Skript laufen hab´ lassen, liegt die Ursache wohl doch an diesem Skript: Neben meinen Mailboxen bei meinem Provider, werden weiter Postfächer bei anderen Anbietern (GMX, WEB.de, Yahoo) abgefragt. Ursache für mein Problem ist ein lokaler Anbieter. Nachdem dieser abgefragt wurde, taucht dann immer wieder "fetchmail: POP3> STLS" im Logfile auch. Hier Ausschnitt des Logfiles beim Poll auf diesen besagten Provider: fetchmail: POP3< +OK POP3 lokaler.provider.de v2001.78 server ready fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows: fetchmail: POP3< TOP fetchmail: POP3< LOGIN-DELAY 180 fetchmail: POP3< UIDL fetchmail: POP3< STLS fetchmail: POP3< USER fetchmail: POP3< SASL LOGIN fetchmail: POP3< . fetchmail: POP3> STLS fetchmail: POP3< +OK STLS completed fetchmail: Herausgeber-Organisation: Buergernetzverein Lokal e.V.. fetchmail: Herausgeber-CommonName: BN-Lokal fetchmail: Server-CommonName: lokaler.provider.de fetchmail: Server-CommonName stimmt nicht überein: lokaler.provider.de != pop3.provider.de fetchmail: pop3.provider.de-Schlüssel-Fingerabdruck: AA:44:5F:D6:9E:51:3A:36:23:0B:E5:3B:AD:37:14:AC fetchmail: Warnung: Server-Zertifikat-Überprüfung: unable to get local issuer certificate fetchmail: Herausgeber-Organisation: Buergernetzverein Lokal e.V.. fetchmail: Herausgeber-CommonName: BN-Lokal fetchmail: Server-CommonName: lokaler.provider.de fetchmail: Server-CommonName stimmt nicht überein: lokaler.provider.de != pop3.provider.de fetchmail: Warnung: Server-Zertifikat-Überprüfung: certificate not trusted fetchmail: Herausgeber-Organisation: Buergernetzverein Lokal e.V.. fetchmail: Herausgeber-CommonName: BN-Lokal fetchmail: Server-CommonName: lokaler.provider.de fetchmail: Server-CommonName stimmt nicht überein: lokaler.provider.de != pop3.provider.de fetchmail: Warnung: Server-Zertifikat-Überprüfung: unable to verify the first certificate fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows: fetchmail: POP3< TOP fetchmail: POP3< LOGIN-DELAY 180 fetchmail: POP3< UIDL fetchmail: POP3< USER fetchmail: POP3< SASL PLAIN LOGIN fetchmail: POP3< . fetchmail: POP3> USER ho1110 fetchmail: POP3< +OK User name accepted, password please fetchmail: POP3> PASS fetchmail: POP3< +OK Mailbox open, 0 messages fetchmail: POP3> STAT fetchmail: POP3< +OK 0 0 fetchmail: Keine Post für ho1110 bei pop3.bnhof.de fetchmail: POP3> QUIT fetchmail: POP3< +OK Sayonara fetchmail: 6.2.3 fragt ab lokaler.provider.de (Protokoll POP3) um Do 20 Nov 2003 14:01:34 CET: Abfrage beendet fetchmail: SMTP> QUIT fetchmail: SMTP< 221 Bye Ich vermute, dass durch diesen Umstand Fetchmail dann nicht mehr so tut wie er eigentlich soll. Den Identd-Daemon hab ich bereits nachinstalliert. Ich werde später mal testen, den Identd-Daemon abzuschalten und den Port 113 wieder zu schließen. Gruß Andreas
Am Donnerstag, 20. November 2003 11:50 schrieb Andreas Rau:
gleich eines Vorweg, der Spruch "Never touch a running System" ist mir sehr wohl bekannt. Trotzdem konnte ich es nicht lassen meinen alten Server mit Suse 8.2 platt zu machen und mal wieder komplett neu (mit Suse 9 Prof.) aufzusetzen.
Auf dem Server habe ich die Settings meines alten Mailservers (Fetchmail - Postfix - AntiVir - Spamassassin - Cyrus) soweit wieder hinbekommen.
Aus Gründen, die sich meiner Kenntnis entziehen, will fetchmail nicht mehr so richtig. Hole ich meine Mails manuell ab, so klappt das wunderbar.
Was heisst "manuell" ?
Starte mal fetchmail mit "-vvv" dann sagt er ganz ganz viel und vergleiche mal die ausgaben daemon/manuell.
Möchte ich fetchmail als Daemon laufen lassen, werden die Mails vom Mailserver meines Webhosters beim ersten mal abgeholt, bei den folgenden polls kommt dann nur noch folgende Log-Meldung:
fetchmail: 6.2.3 querying pop3.foo.de (protocol POP3) at Tue Nov 18 21:57:38 2003: poll started fetchmail: POP3< +OK ready fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows fetchmail: POP3< TOP fetchmail: POP3< USER fetchmail: POP3< LOGIN-DELAY 0 fetchmail: POP3< EXPIRE 0 fetchmail: POP3< UIDL fetchmail: POP3< RESP-CODES fetchmail: POP3< AUTH-RESP-CODE fetchmail: POP3< X-MANGLE fetchmail: POP3< X-MACRO fetchmail: POP3< X-LOCALTIME Tue, 18 Nov 2003 21:57:38 +0100 fetchmail: POP3< . fetchmail: POP3> STLS
Wieso versucht Dein fetchmail das denn? Hast Du das manuell gesetzt?
fetchmail: POP3< -ERR Command not enabled fetchmail: Command not enabled fetchmail: POP3> CAPA fetchmail: POP3< +OK Pop server at server16.glai.de signing off. fetchmail: POP3> USER web###p1 fetchmail: POP3> PASS fetchmail: Unknown login or authentication error on web###p1@pop3.foo.de fetchmail: POP3> QUIT
Um auszuschließen, dass es sich dabei um ein Problem bei meinem Hoster (Global Interactive) handelt, habe ich mich mit dessen Support in Verbindung gesetzt. Nach Auskunft des Supportmitarbeiters, sei dies ein Problem mit der Authenifizierung, das über den tcp-Port 113 zwischen Client und Server ausgehandelt wird. Daraufhin habe ich an meinem Hardware-Router den Port 113 aufgemacht, jedoch ohne Erfolg. Das Problem bleibt nach wie vor.
Hmm, also den Port aufzumachen, reicht nicht wirklich. Wenn Du den schon benutzen willst, muss da auch was lauschen. 113 ist identd, dazu gibt es einen Daemon, der muss dann installiert und getsartet sein.
Wäre mir aber jetzt nicht so sicher, ob es überhaupt daran liegt. Den habe ich noch nie gebraucht und der wird auch in letzter Zeit aus Sicherheitsgründen nicht mehr installiert.
Unter Suse 8.2 ist das .fetchmailrc-Skript ohne Probs gelaufen. Seit ich nun die 9.0 drauf habe geht nix mehr ;-(((
Gab es größere Änderungen bei fetchmail oder verwandten Paketen, die ich möglicherweise nicht berücksichtigt haben könnte?
Für jeden Hinweis bin ich dankbar.
-- Andreas
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Hallo, bitte kein TOFU (Text oben, Fullquote unten) fabrizieren. Danke. * Andreas Rau textete am 20.11.03:
nachdem ich jetzt noch einige Tests mit dem fetchmailrc-Skript laufen hab´ lassen, liegt die Ursache wohl doch an diesem Skript:
Neben meinen Mailboxen bei meinem Provider, werden weiter Postfächer bei anderen Anbietern (GMX, WEB.de, Yahoo) abgefragt. Ursache für mein Problem ist ein lokaler Anbieter. Nachdem dieser abgefragt wurde, taucht dann immer wieder "fetchmail: POP3> STLS" im Logfile auch.
Hier Ausschnitt des Logfiles beim Poll auf diesen besagten Provider:
fetchmail: POP3< +OK POP3 lokaler.provider.de v2001.78 server ready fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows: fetchmail: POP3< TOP fetchmail: POP3< LOGIN-DELAY 180 fetchmail: POP3< UIDL fetchmail: POP3< STLS fetchmail: POP3< USER fetchmail: POP3< SASL LOGIN fetchmail: POP3< . fetchmail: POP3> STLS fetchmail: POP3< +OK STLS completed fetchmail: Herausgeber-Organisation: Buergernetzverein Lokal e.V.. fetchmail: Herausgeber-CommonName: BN-Lokal fetchmail: Server-CommonName: lokaler.provider.de fetchmail: Server-CommonName stimmt nicht überein: lokaler.provider.de != pop3.provider.de
Hier steht doch was. Einmal macht er was mit lokaler.provider.de und einmal mit pop3.provider.de Prüf mal dein Script auf den Servernamen, ob da alles paßt.
fetchmail: pop3.provider.de-Schlüssel-Fingerabdruck: AA:44:5F:D6:9E:51:3A:36:23:0B:E5:3B:AD:37:14:AC fetchmail: Warnung: Server-Zertifikat-Überprüfung: unable to get local issuer certificate fetchmail: Herausgeber-Organisation: Buergernetzverein Lokal e.V.. fetchmail: Herausgeber-CommonName: BN-Lokal fetchmail: Server-CommonName: lokaler.provider.de fetchmail: Server-CommonName stimmt nicht überein: lokaler.provider.de != pop3.provider.de
Hier nochmal.
fetchmail: Warnung: Server-Zertifikat-Überprüfung: certificate not trusted fetchmail: Herausgeber-Organisation: Buergernetzverein Lokal e.V.. fetchmail: Herausgeber-CommonName: BN-Lokal fetchmail: Server-CommonName: lokaler.provider.de fetchmail: Server-CommonName stimmt nicht überein: lokaler.provider.de != pop3.provider.de
Und nochmal.
fetchmail: Warnung: Server-Zertifikat-Überprüfung: unable to verify the first certificate
Das Server- Zertifikat kann er auch nicht prüfen.
fetchmail: POP3> CAPA fetchmail: POP3< +OK Capability list follows: fetchmail: POP3< TOP fetchmail: POP3< LOGIN-DELAY 180 fetchmail: POP3< UIDL fetchmail: POP3< USER fetchmail: POP3< SASL PLAIN LOGIN
Und wenn er es mit "SASL PLAIN LOGIN" versucht, klappt die Anmeldung, mit "SASL LOGIN" nicht... Ich nehme mal an, daß SASL verschlüsselt überträgt? Das klappt nicht. Nur wenn die Daten im Klartext kommen, geht's.
fetchmail: POP3< . fetchmail: POP3> USER ho1110 fetchmail: POP3< +OK User name accepted, password please fetchmail: POP3> PASS fetchmail: POP3< +OK Mailbox open, 0 messages fetchmail: POP3> STAT fetchmail: POP3< +OK 0 0 fetchmail: Keine Post für ho1110 bei pop3.bnhof.de fetchmail: POP3> QUIT fetchmail: POP3< +OK Sayonara fetchmail: 6.2.3 fragt ab lokaler.provider.de (Protokoll POP3) um Do 20 Nov 2003 14:01:34 CET: Abfrage beendet fetchmail: SMTP> QUIT fetchmail: SMTP< 221 Bye
Hier war die Abfrage erfolgreich. Spricht der Server deines Providers überhaupt sasl? cu flo --
Wo finde ich eigentlich die FAQ dieser Gruppe? auf der Rückseite dieses Postings. [Sascha El-Mehallawy und Roland Jacob in dag°]
participants (3)
-
Andreas Rau
-
Andreas Winkelmann
-
Florian Gross