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