Wenn ja, so ist meines innerhalb von zwei Tagen um mind. 80 Jahre gealtert. Es kriecht nur noch ueber die Datenwege - E-Mail abholen dauert ewig und drei Tage. Woran kann das liegen? An dem kuerzlich neu aktiviertem "spamd" jedenfalls nicht - auch bei Deaktivierung verhaelt sich fetchmail wie ein alter Opa. Leider brachte Google (http://www.google.de/linux?q=fetchmail%20langsam) nicht wirklich brauchbare Ergebnisse. Daher bin ich ueber jeden Tipp dankbar, der meinem Fetchmail eine Verjuengungskur gibt. thx Bernd -- WhAT YoU HaCk iS WhAT YoU GeT
Bernd Langehegermann wrote:
Wenn ja, so ist meines innerhalb von zwei Tagen um mind. 80 Jahre gealtert. Es kriecht nur noch ueber die Datenwege - E-Mail abholen dauert ewig und drei Tage. Woran kann das liegen? An dem kuerzlich neu aktiviertem "spamd" jedenfalls nicht - auch bei Deaktivierung verhaelt sich fetchmail wie ein alter Opa.
Leider brachte Google (http://www.google.de/linux?q=fetchmail%20langsam) nicht wirklich brauchbare Ergebnisse. Daher bin ich ueber jeden Tipp dankbar, der meinem Fetchmail eine Verjuengungskur gibt.
Ruf doch fetchmail mal mit -v oder sogar -vv auf und schau wo es so lange braucht. Ansonsten ist das nur Raterei. -- Andreas
Fre, 26 Sep 2003 Bernd Langehegermann wrote:
Bernd Langehegermann wrote:
Wenn ja, so ist meines innerhalb von zwei Tagen um mind. 80 Jahre gealtert. Es kriecht nur noch ueber die Datenwege - E-Mail abholen dauert ewig und drei Tage. Woran kann das liegen? An dem kuerzlich neu aktiviertem "spamd" jedenfalls nicht - auch bei Deaktivierung verhaelt sich fetchmail wie ein alter Opa.
Leider brachte Google (http://www.google.de/linux?q=fetchmail%20langsam) nicht wirklich brauchbare Ergebnisse. Daher bin ich ueber jeden Tipp dankbar, der meinem Fetchmail eine Verjuengungskur gibt.
Ruf doch fetchmail mal mit -v oder sogar -vv auf und schau wo es so lange braucht. Ansonsten ist das nur Raterei.
Und das kommt dabei raus: fetchmail: forwarding to localhost fetchmail: SMTP> MAIL FROM:<bugtraq-return-11241-illuminatus=muenster.de@securityfocus.com> SIZE=4134 fetchmail: SMTP< 250 2.1.0 <bugtraq-return-11241-illuminatus=muenster.de@securityfocus.com>... Sender ok fetchmail: SMTP> RCPT TO:<user@localhost> fetchmail: SMTP< 250 2.1.5 <user@localhost>... Recipient ok fetchmail: SMTP> DATA fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself # fetchmail: IMAP< ) fetchmail: IMAP< A0243 OK FETCH completed. fetchmail: IMAP> A0244 FETCH 1 BODY.PEEK[TEXT] fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {2190} (2190 body octets) *************************.***************************.****** fetchmail: IMAP< ) fetchmail: IMAP< A0244 OK FETCH completed. fetchmail: SMTP>. (EOM) fetchmail: SMTP< 250 2.0.0 h8QIZhHJ029943 Message accepted for delivery flushed fetchmail: IMAP> A0245 STORE 1 +FLAGS (\Seen \Deleted) fetchmail: IMAP< * 1 FETCH (FLAGS (\Seen \Deleted \Recent)) fetchmail: IMAP< A0245 OK STORE completed. fetchmail: IMAP> A0246 EXPUNGE fetchmail: IMAP< * 1 EXPUNGE fetchmail: IMAP< * 1 EXISTS fetchmail: IMAP< * 1 RECENT fetchmail: IMAP< A0246 OK EXPUNGE completed fetchmail: IMAP> A0247 FETCH 1 RFC822.HEADER fetchmail: IMAP< * 1 FETCH (RFC822.HEADER {1619} reading message user@pop.citykom.de:3 of 3 (1619 header octets) About to rewrite Return-Path: <bugtraq-return-11231-illuminatus=muenster.de@securityfocus.com> Rewritten version is Return-Path: <bugtraq-return-11231-illuminatus=muenster.de@securityfocus.com> About to rewrite From: "Jonathan A. Zdziarski" <jonathan@nuclearelephant.com> Rewritten version is From: "Jonathan A. Zdziarski" <jonathan@nuclearelephant.com> About to rewrite To: full-disclosure@lists.netsys.com, bugtraq@securityfocus.com Rewritten version is To: full-disclosure@lists.netsys.com, bugtraq@securityfocus.com fetchmail: forwarding to localhost fetchmail: SMTP> MAIL FROM:<bugtraq-return-11231-illuminatus=muenster.de@securityfocus.com> BODY=7BIT SIZE=1827 fetchmail: SMTP< 250 2.1.0 <bugtraq-return-11231-illuminatus=muenster.de@securityfocus.com>... Sender ok fetchmail: SMTP> RCPT TO:<user@localhost> fetchmail: SMTP< 250 2.1.5 <user@localhost>... Recipient ok fetchmail: SMTP> DATA fetchmail: SMTP< 354 Enter mail, end with "." on a line by itself # fetchmail: IMAP< ) fetchmail: IMAP< A0247 OK FETCH completed. fetchmail: IMAP> A0248 FETCH 1 BODY.PEEK[TEXT] fetchmail: IMAP< * 1 FETCH (BODY[TEXT] {208} (208 body octets) ******** fetchmail: IMAP< ) fetchmail: IMAP< A0248 OK FETCH completed. fetchmail: SMTP>. (EOM) fetchmail: SMTP< 250 2.0.0 h8QIZhHK029943 Message accepted for delivery flushed fetchmail: IMAP> A0249 STORE 1 +FLAGS (\Seen \Deleted) fetchmail: IMAP< * 1 FETCH (FLAGS (\Seen \Deleted \Recent)) fetchmail: IMAP< A0249 OK STORE completed. fetchmail: IMAP> A0250 EXPUNGE fetchmail: IMAP< * 1 EXPUNGE fetchmail: IMAP< * 0 EXISTS fetchmail: IMAP< * 0 RECENT fetchmail: IMAP< A0250 OK EXPUNGE completed fetchmail: selecting or re-polling default folder fetchmail: 0 messages waiting after re-poll fetchmail: IMAP> A0251 LOGOUT fetchmail: IMAP< * BYE Courier-IMAP server shutting down fetchmail: IMAP< A0251 OK LOGOUT completed fetchmail: 5.9.13 querying pop.citykom.de (protocol IMAP) at Fri, 26 Sep 2003 20:49:15 +0200 (CEST): poll completed fetchmail: 5.9.13 querying pop.citykom.de (protocol auto) at Fri, 26 Sep 2003 20:49:15 +0200 (CEST): poll completed fetchmail: not swapping UID lists, no UIDs seen this query fetchmail: SMTP> QUIT fetchmail: SMTP< 221 2.0.0 marvin.localhost closing connection fetchmail: Deleting fetchids file. fetchmail: normal termination, status 0 fetchmail: Deleting fetchids file. Sieht fuer mich doch ganz normal aus, oder? Mercie Bernd -- WhAT YoU HaCk iS WhAT YoU GeT
Bernd Langehegermann wrote:
Fre, 26 Sep 2003 Bernd Langehegermann wrote:
Bernd Langehegermann wrote:
Wenn ja, so ist meines innerhalb von zwei Tagen um mind. 80 Jahre gealtert. Es kriecht nur noch ueber die Datenwege - E-Mail abholen dauert ewig und drei Tage. Woran kann das liegen? An dem kuerzlich neu aktiviertem "spamd" jedenfalls nicht - auch bei Deaktivierung verhaelt sich fetchmail wie ein alter Opa.
Leider brachte Google (http://www.google.de/linux?q=fetchmail%20langsam) nicht wirklich brauchbare Ergebnisse. Daher bin ich ueber jeden Tipp dankbar, der meinem Fetchmail eine Verjuengungskur gibt.
Ruf doch fetchmail mal mit -v oder sogar -vv auf und schau wo es so lange braucht. Ansonsten ist das nur Raterei.
Und das kommt dabei raus:
Sieht fuer mich doch ganz normal aus, oder?
;-) Ja, ich glaube Dir dass es funktioniert. Ich meinte auch, dass Du Dich davor setzen sollst, und schauen sollst bei welchem Vorgang sehr viel Zeit verbraucht wird. Bei -v(v) siehst Du halt recht gut, was er gerade macht. -- Andreas
Moin, Am Fr, den 26.09.2003 schrieb Bernd Langehegermann um 16:41:
Wenn ja, so ist meines innerhalb von zwei Tagen um mind. 80 Jahre gealtert. Es kriecht nur noch ueber die Datenwege - E-Mail abholen dauert ewig und drei Tage. Woran kann das liegen? An dem kuerzlich neu aktiviertem "spamd" jedenfalls nicht - auch bei Deaktivierung verhaelt sich fetchmail wie ein alter Opa.
Hast du eine neue Regel in .procmail, die nach B wie Body filtert? Hab ich auch, wegen Swen, seitdem dauert da alles etwas länger. Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Ratti wrote:
Hast du eine neue Regel in .procmail, die nach B wie Body filtert? Hab ich auch, wegen Swen, seitdem dauert da alles etwas länger.
Hast du dran gedacht, die Groesse als weiteres Kriterium anzugeben? Macht ja schliesslich keinen Sinn, den procmail jede 50 kb Mail durchstoebern zu lassen, wenn Swen 150 kb gross ist. -- Have fun, Peter
Fre, 26 Sep 2003 Bernd Langehegermann wrote:
Ratti wrote:
Hast du eine neue Regel in .procmail, die nach B wie Body filtert? Hab ich auch, wegen Swen, seitdem dauert da alles etwas länger.
Hast du dran gedacht, die Groesse als weiteres Kriterium anzugeben? Macht ja schliesslich keinen Sinn, den procmail jede 50 kb Mail durchstoebern zu lassen, wenn Swen 150 kb gross ist.
Mit Swen hatte ich noch keine Probleme! -- WhAT YoU HaCk iS WhAT YoU GeT
Fre, 26 Sep 2003 Bernd Langehegermann wrote:
Moin,
Am Fr, den 26.09.2003 schrieb Bernd Langehegermann um 16:41:
Wenn ja, so ist meines innerhalb von zwei Tagen um mind. 80 Jahre gealtert. Es kriecht nur noch ueber die Datenwege - E-Mail abholen dauert ewig und drei Tage. Woran kann das liegen? An dem kuerzlich neu aktiviertem "spamd" jedenfalls nicht - auch bei Deaktivierung verhaelt sich fetchmail wie ein alter Opa.
Hast du eine neue Regel in .procmail, die nach B wie Body filtert? Hab ich auch, wegen Swen, seitdem dauert da alles etwas länger.
Noe, habe nichts in der Hinsicht geaendert, na ja einige Regeln sind schon dazugekommen, aber die Filtern nach den Mailinglist(neu abboniert)-Kriterien. Sprich nach From etc. Mit Swen hatte ich noch keine Probleme, wieso gluecklicherweise auch immer -- WhAT YoU HaCk iS WhAT YoU GeT
Hallo, Am Fri, 26 Sep 2003, Joerg Rossdeutscher schrieb:
Hast du eine neue Regel in .procmail, die nach B wie Body filtert? Hab ich auch, wegen Swen, seitdem dauert da alles etwas länger.
Nach was filterst du? Vermutlich ist folgendes recht effektiv: ### LMB: M$-exe, base64 :0 B: * ^TV[qpro][iw5QJB]............\/\/[8+]...........AAQAA.AA.AAAA.AAAAAAAAAAAAAAAA /dev/null -dnh --
Hallo habe meinen ersten hack hintermir [...] Du bist ein Held. Wir bewundern Dich. Willst Du mich ficken? (Sabine Wieczorek zu Igor Gurinovic in de.org.ccc)
Moin, Am Fr, den 26.09.2003 schrieb David Haller um 23:20:
Hallo,
Am Fri, 26 Sep 2003, Joerg Rossdeutscher schrieb:
Hast du eine neue Regel in .procmail, die nach B wie Body filtert? Hab ich auch, wegen Swen, seitdem dauert da alles etwas länger.
Nach was filterst du?
Wie wahrscheinlich viele Leute derzeit: Mit einem unübersichtlichen procmail-Gestrüpp, das nicht nur den eigentlichen Swen erledigt, sondern auch die ganzen Mutationen, die dadurch entstehen, daß Schwachmaten-Mailserver alles mögliche mit Swen anstellen, zum Beispiel das EXE-Rausschnippelt, den Rest mit Virenwarnung versehen und dann trotzdewm weiterleiten und hab-brav-das-Stöckchen-geholt Meldung machen an everybody@internet.all .
Vermutlich ist folgendes recht effektiv:
### LMB: M$-exe, base64 :0 B: * ^TV[qpro][iw5QJB]............\/\/[8+]...........AAQAA.AA.AAAA.AAAAAAAAAAAAAAAA /dev/null
Ja, eben. Ein Body-Filter, und der zieht natürlich Performance. Ich habe vorher noch einen anderen (Auch irgendwo geklaut): :0: * -2^0 * 1^0 > 140000 * 1^0 < 165000 * 1^0 ^subject: (undeliverable|undelivered|returned)? ?(mail|message)(:? (returned to (mail|send)er|user unknown))? * 1^0 ^subject: (new(est)?|latest|last|current)? ?(net(work)?|microsoft|internet)? ?(critical|security)? ?(pack|patch|update|upgrade) * 1^0 ^subject: (abort|bug|error|failure)? ?(advice|announcement|letter|message|notice|report) /home/ratti/filtered_mail/swen-junk Der greif evtl. etwas zuviel, aber ehrlich gesagt ist mir das derzeit Latte. Ich filtere absichtlich nicht nach /dev/null, weil der gesammelte Mist auch noch manuell an sa-learn verfüttert wird, der scheint so langsam einiges zu greifen, was durch procmail durchrutscht, wegen siehe oben. Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Hallo, Am Sat, 27 Sep 2003, Joerg Rossdeutscher schrieb:
Moin,
Am Fr, den 26.09.2003 schrieb David Haller um 23:20:
Hallo,
Am Fri, 26 Sep 2003, Joerg Rossdeutscher schrieb:
Hast du eine neue Regel in .procmail, die nach B wie Body filtert? Hab ich auch, wegen Swen, seitdem dauert da alles etwas länger.
Nach was filterst du?
Wie wahrscheinlich viele Leute derzeit: Mit einem unübersichtlichen procmail-Gestrüpp, das nicht nur den eigentlichen Swen erledigt, sondern auch die ganzen Mutationen, die dadurch entstehen, daß Schwachmaten-Mailserver alles mögliche mit Swen anstellen, zum Beispiel das EXE-Rausschnippelt, den Rest mit Virenwarnung versehen und dann trotzdewm weiterleiten und hab-brav-das-Stöckchen-geholt Meldung machen an everybody@internet.all .
Ich hab hier antivir in procmail eingeklinkt, das erkennt den Kram ;)
Vermutlich ist folgendes recht effektiv:
### LMB: M$-exe, base64 :0 B: * ^TV[qpro][iw5QJB]............\/\/[8+]...........AAQAA.AA.AAAA.AAAAAAAAAAAAAAAA /dev/null
Ja, eben. Ein Body-Filter, und der zieht natürlich Performance.
Hm. Muss ich mal testen, wie schnell der im Vergleich ist. Ich schalt die Regel mal scharf ;) Jedenfalls ist antivir (plus mein filter drumrum) deutlich schneller als spamassassin, der kommt bei mir erst anschliessend... [..]
Ich filtere absichtlich nicht nach /dev/null,
Ich auch nicht. -dnh --
Jo 'Was ist eigentlich dieses Freizeit-Ding?' chen Wenn Du etwas für die Firma zu Hause (der Ort, der in Deinem Personalausweis steht. Genau, dort, wo mal wieder dringend abgewaschen werden müsste) tust. [Jochen Lillich und Florian Kuehnert in dasr]
Sam, 27 Sep 2003 Bernd Langehegermann wrote:
Hallo,
Am Sat, 27 Sep 2003, Joerg Rossdeutscher schrieb:
Moin,
Am Fr, den 26.09.2003 schrieb David Haller um 23:20:
Hallo,
Am Fri, 26 Sep 2003, Joerg Rossdeutscher schrieb:
Hast du eine neue Regel in .procmail, die nach B wie Body filtert? Hab ich auch, wegen Swen, seitdem dauert da alles etwas länger.
Nach was filterst du?
Wie wahrscheinlich viele Leute derzeit: Mit einem unübersichtlichen procmail-Gestrüpp, das nicht nur den eigentlichen Swen erledigt, sondern auch die ganzen Mutationen, die dadurch entstehen, daß Schwachmaten-Mailserver alles mögliche mit Swen anstellen, zum Beispiel das EXE-Rausschnippelt, den Rest mit Virenwarnung versehen und dann trotzdewm weiterleiten und hab-brav-das-Stöckchen-geholt Meldung machen an everybody@internet.all .
Jetzt wollte ich loslegen und in Ruhe mein Problemchen angehen und was ist ES laeuft von ganz alleine wieder ;-/ Lieber ISP, woran hat das jetzt gelegen? Dank trotzdem fuer die vielen auch weiterhin nuetzlichen Tipps Bernd -- WhAT YoU HaCk iS WhAT YoU GeT
participants (5)
-
Andreas Winkelmann -
Bernd Langehegermann -
David Haller -
Joerg Rossdeutscher -
Peter Wiersig