Moin, ich habe da mal eine Frage zu fetchmail: Kann man fetchmail so konfigurieren, dass es geholte Mails auf dem pop-Server belässt diese aber nach einer einstellbaren Zeit aber doch löscht? Bei Eudora (Mailprogramm für Windows) gab es eine sehr nützliche Einstellung: - [x] Leave Mails on server - Delete after [10] days. So was würde ich gerne nachbauen. Vor allem müsste natürlich verhindert werden, dass schon einmal geladene Mails nochmal geladen werden. Hat jemand einen Tip für mich? Gruß Hannes
Moin, moin ... hannes.vogelmann@imk.fzk.de wrote:
Bei Eudora (Mailprogramm für Windows) gab es eine sehr nützliche Einstellung:
- [x] Leave Mails on server - Delete after [10] days.
So was würde ich gerne nachbauen. Vor allem müsste natürlich verhindert werden, dass schon einmal geladene Mails nochmal geladen werden.
iirc, kann fetchmail entweder eMails auf dem Server belassen oder vom Server löschen. Du könntest einen Teil-Würgaround machen, indem Du Deinem Standard-Fetchmail per .fetchmailrc sagst, daß er eMails saugen aber nicht löschen soll. Zusätzlich dann alle 10 Tage einen Fetchmail-Lauf, welcher Dein Postfach leerfegt. Wie gesagt: Teil-Würgaround ;-) bis dahin - kind regards Martin Mewes -- http://webmin.mamemu.de/ Official Webmin/Usermin Translation Co-Ordinator 2003/2004 Proud Agent 2.0 Beta Tester
hannes.vogelmann@imk.fzk.de am Montag, 10. November 2003 17:21:
Moin,
ich habe da mal eine Frage zu fetchmail:
Kann man fetchmail so konfigurieren, dass es geholte Mails auf dem pop-Server belässt diese aber nach einer einstellbaren Zeit aber doch löscht?
Bei Eudora (Mailprogramm für Windows) gab es eine sehr nützliche Einstellung:
- [x] Leave Mails on server - Delete after [10] days.
So was würde ich gerne nachbauen. Vor allem müsste natürlich verhindert werden, dass schon einmal geladene Mails nochmal geladen werden.
Hat jemand einen Tip für mich?
Mit fetchmail geht das nur hilfsweise: 1. die Option --keep beim Aufruf oder in der .fetchmailconf verhindert das Löschen der Mails auf dem Server. Sie werden also beim nächsten mal wieder geladen. (1a. die Option --nokeep macht genau das Entgegengesetzte) 2. die Option --uidl legt eine Liste der abgeholten Mail-IDs an und verhindert so das doppelte Abholen. Den Rest überlass ich deiner Phantasie ;-) -- Gruß MaxX 8-)
Am Mon, 10 Nov 2003, schrieb Matthias Houdek:
hannes.vogelmann@imk.fzk.de am Montag, 10. November 2003 17:21:
Moin,
ich habe da mal eine Frage zu fetchmail:
Kann man fetchmail so konfigurieren, dass es geholte Mails auf dem pop-Server belässt diese aber nach einer einstellbaren Zeit aber doch löscht?
Bei Eudora (Mailprogramm für Windows) gab es eine sehr nützliche Einstellung:
- [x] Leave Mails on server - Delete after [10] days.
So was würde ich gerne nachbauen. Vor allem müsste natürlich verhindert werden, dass schon einmal geladene Mails nochmal geladen werden.
Hat jemand einen Tip für mich?
Mit fetchmail geht das nur hilfsweise:
1. die Option --keep beim Aufruf oder in der .fetchmailconf verhindert das Löschen der Mails auf dem Server. Sie werden also beim nächsten mal wieder geladen.
(1a. die Option --nokeep macht genau das Entgegengesetzte)
2. die Option --uidl legt eine Liste der abgeholten Mail-IDs an und verhindert so das doppelte Abholen.
Letzteres ist schon mal gut. Aber die Lösung mit fetchmail auch so wie von Martin Mewes vorgeschlagen ist wirklich nur eine Krücke, denn dadurch dass ich alle 10 Tage ein fetchmail mit Löschen über die Mailbox laufen lasse, wird das eigentliche Problem nicht gelöst sondern lediglich vertagt. Die Problematik ist folgende: Auf meine Mailbox kann ich jetzt endlich nach vielen Diskussionen mit den Admins von außen via pop zugreifen, dass erledigt ein fetchmaildaemon auf einem weit entfernten Rechner alle 100s mit der option --keep und --uidl. Es könnten weitere entfernte Rechner hinzukommen, die es auch so machen. Soweit so gut. Jetzt gibt es aber einen Rechner, der mit seinem fetchmail die Mailbox final lesen und entleeren soll. Wenn dieser jetzt alle mails flusht, kann es passieren, dass Mails final gelöscht werden, bevor die entfernten daemonen die Mail holen konnten. Leider kann ich den Mailserver (MSExchange) in keinster Weise konfigurieren und dort auch keine Mailweiterleitung zu einer besser konfigurierbaren pop3-Mailbox einrichten. cu Hannes
Hallo, Am Tue, 11 Nov 2003, hannes.vogelmann@imk.fzk.de schrieb:
2. die Option --uidl legt eine Liste der abgeholten Mail-IDs an und verhindert so das doppelte Abholen. [..] Auf meine Mailbox kann ich jetzt endlich nach vielen Diskussionen mit den Admins von außen via pop zugreifen, dass erledigt ein fetchmaildaemon auf einem weit entfernten Rechner alle 100s mit der option --keep und --uidl. Es könnten weitere entfernte Rechner hinzukommen, die es auch so machen. Soweit so gut. Jetzt gibt es aber einen Rechner, der mit seinem fetchmail die Mailbox final lesen und entleeren soll. Wenn dieser jetzt alle mails flusht, kann es passieren, dass Mails final gelöscht werden, bevor die entfernten daemonen die Mail holen konnten. Leider kann ich den Mailserver (MSExchange) in keinster Weise konfigurieren und dort auch keine Mailweiterleitung zu einer besser konfigurierbaren pop3-Mailbox einrichten.
Dann hast du ein grundsaetzliches Problem, das geht prinzipbedingt nicht mit POP3. Wie sollen die verschiedenen Clients denn auch miteinander absprechen, wer jetzt schon welche Mails geholt hat? Eine Idee waere vielleicht, wenn du eine Art "zentrale" DB mit den UIDLs (z.B.) fuehrst und jeweils vermerktst, welcher Client welche Mails schon geholt hat... Evtl. koennte man z.B. auch fetchmail durch ein perl-script (mit Net::*) ersetzen, das die Mails holt (mit keep/uidl oder sonstwie) und dann die geholten Mails (UIDLs) an den zentralen Server meldet. Oder man liest die UIDLs, die fetchmail speichert (wo? wie? keine Ahnung!) und meldet diese dann "irgendwo zentral"... Das waere wohl einfacher... Im Prinzip warest du aber wohl mit IMAP besser bedient. -dnh -- Give a man fire, and he will be warm for a day, set a man on fire, and he will be warm for the rest of his life.
Am Die, 11 Nov 2003, schrieb David Haller:
Auf meine Mailbox kann ich jetzt endlich nach vielen Diskussionen mit den Admins von außen via pop zugreifen, dass erledigt ein fetchmaildaemon auf einem weit entfernten Rechner alle 100s mit der option --keep und --uidl. Es könnten weitere entfernte Rechner hinzukommen, die es auch so machen. Soweit so gut. Jetzt gibt es aber einen Rechner, der mit seinem fetchmail die Mailbox final lesen und entleeren soll. Wenn dieser jetzt alle mails flusht, kann es passieren, dass Mails final gelöscht werden, bevor die entfernten daemonen die Mail holen konnten. Leider kann ich den Mailserver (MSExchange) in keinster Weise konfigurieren und dort auch keine Mailweiterleitung zu einer besser konfigurierbaren pop3-Mailbox einrichten.
Dann hast du ein grundsaetzliches Problem, das geht prinzipbedingt nicht mit POP3. Wie sollen die verschiedenen Clients denn auch miteinander absprechen, wer jetzt schon welche Mails geholt hat?
Warum sollte das nötig sein? Wenn jeder client holt aber nicht löscht bis auf einen, der so stark zeitversetzt nach Holen löscht, dass sichergestellt ist, dass alle anderen clients zwischenzeitlich geholt haben, braucht es doch keine Absprache.
Eine Idee waere vielleicht, wenn du eine Art "zentrale" DB mit den UIDLs (z.B.) fuehrst und jeweils vermerktst, welcher Client welche Mails schon geholt hat...
Viel zu aufwendig. Es reicht doch, wenn die sichergestellt ist, dass die Lebensdauer einer Mail auf dem Server nur länger ist als die wiedrholrate des Holens jedes einzelnen Clients.
Evtl. koennte man z.B. auch fetchmail durch ein perl-script (mit Net::*) ersetzen, das die Mails holt (mit keep/uidl oder sonstwie) und dann die geholten Mails (UIDLs) an den zentralen Server meldet. Oder man liest die UIDLs, die fetchmail speichert (wo? wie? keine Ahnung!) und meldet diese dann "irgendwo zentral"... Das waere wohl einfacher...
Im Prinzip warest du aber wohl mit IMAP besser bedient.
Mit IMAP habe ich mich noch nicht beschäftigt, aber auch hier wäre ja das Problem, den Mails eine Lebensdauer zu geben. cu Hannes
Hannes Vogelmann, Mittwoch, 12. November 2003 09:28:
Im Prinzip warest du aber wohl mit IMAP besser bedient.
Mit IMAP habe ich mich noch nicht beschäftigt, aber auch hier wäre ja das Problem, den Mails eine Lebensdauer zu geben.
IMAP verwaltet die Mails serverseitig, und ist genau für Problemstellungen wie Deine entworfen worden. -- Andreas Feile www.feile.net
Andreas Feile am Mittwoch, 12. November 2003 23:12:
Hannes Vogelmann, Mittwoch, 12. November 2003 09:28:
Im Prinzip warest du aber wohl mit IMAP besser bedient.
Mit IMAP habe ich mich noch nicht beschäftigt, aber auch hier wäre ja das Problem, den Mails eine Lebensdauer zu geben.
IMAP verwaltet die Mails serverseitig, und ist genau für Problemstellungen wie Deine entworfen worden.
... sofern der Server das kann (bzw. man den entsprechende Zugriff hat, das einzurichten) und die Performance der Anbindung gut genug ist (IMAP via Internet mit Modem stell ich mir ziehmlich öde vor ;-). -- Gruß MaxX 8-)
Am Don, 13 Nov 2003, schrieb Matthias Houdek:
Andreas Feile am Mittwoch, 12. November 2003 23:12:
Hannes Vogelmann, Mittwoch, 12. November 2003 09:28:
Im Prinzip warest du aber wohl mit IMAP besser bedient.
Mit IMAP habe ich mich noch nicht beschäftigt, aber auch hier wäre ja das Problem, den Mails eine Lebensdauer zu geben.
IMAP verwaltet die Mails serverseitig, und ist genau für Problemstellungen wie Deine entworfen worden.
... sofern der Server das kann (bzw. man den entsprechende Zugriff hat, das einzurichten) und die Performance der Anbindung gut genug ist (IMAP via Internet mit Modem stell ich mir ziehmlich öde vor ;-).
Ich eben keinen Zugriff auf den Server, d.h. ich keine dort keine Einstellungen wie Lebensdauer, Weiterleitung usw... vornehmen. Ich kann ihn eben einfach nur pop3 mäßig leeren oder, was aber ganz entsetzlich schlecht funktioniert, mit OnlineWebAccess zugreifen. Letztreres ist aber wirklich das allerletzte! cu Hannes
Hannes Vogelmann am Donnerstag, 13. November 2003 17:13:
Am Don, 13 Nov 2003, schrieb Matthias Houdek:
Andreas Feile am Mittwoch, 12. November 2003 23:12:
Hannes Vogelmann, Mittwoch, 12. November 2003 09:28:
Im Prinzip warest du aber wohl mit IMAP besser bedient.
Mit IMAP habe ich mich noch nicht beschäftigt, aber auch hier wäre ja das Problem, den Mails eine Lebensdauer zu geben.
IMAP verwaltet die Mails serverseitig, und ist genau für Problemstellungen wie Deine entworfen worden.
... sofern der Server das kann (bzw. man den entsprechende Zugriff hat, das einzurichten) und die Performance der Anbindung gut genug ist (IMAP via Internet mit Modem stell ich mir ziehmlich öde vor ;-).
Ich eben keinen Zugriff auf den Server, d.h. ich keine dort keine Einstellungen wie Lebensdauer, Weiterleitung usw... vornehmen. Ich kann ihn eben einfach nur pop3 mäßig leeren oder, was aber ganz entsetzlich schlecht funktioniert, mit OnlineWebAccess zugreifen. Letztreres ist aber wirklich das allerletzte!
Dann bleibt wohl nur noch der Weg über ein eigenes kleines Script, dass via telnet auf den POP-Server (Port 110) zugreift (sofern du kein entsprechendes Programm findest - ich hab keins gefunden, aber mir reicht auch die Lösung mit dem Sonntagnacht-Löschen). Nachdem du dich mit USER <name> und PASS <passwort> am Server angemeldet hast, steht dir das entsprechende Postfach zur freien Verfügung. Mit LIST werden alle Mails mit lfd. Nummer und Länge in Byte zeilenweise aufgerufen. Leider kann man das nicht weiter verwenden, außer evtl. für die Anzahl aller Bytes. Du könntest z.B. hier ansetzen und immer die erste Hälfte aller Mails löschen (oder die ersten 10 % oder so). Oder du rufts Mail für Mail mit RETR <x> (x ist die laufende Nummer) auf und entscheidest jetzt nach best. Kriterien im Header, ob du sie löschen willst - z.B. über die Header-Zeile "Date ..." oder Arrival-Date ...". Mit DELE <x> wird die betreffende Mail dann gelöscht (richtig gelöscht wird eigentlich erst, wenn du die Sitzung ordnungsgemäß mit QUIT beendest - also nicht vergessen, sonst sind alle Mails das nächste Mal wieder da ;-). Tipp: Ich würde erst einmal die Variante 1 probieren (Anzahl aller Mails bestimmen, davon die ersten x % löschen). Variante 2 ist dann schon ein wenig anspruchsvoller. -- Gruß MaxX 8-)
Am Don, 13 Nov 2003, schrieb Matthias Houdek:
Hannes Vogelmann am Donnerstag, 13. November 2003 17:13:
Am Don, 13 Nov 2003, schrieb Matthias Houdek:
Andreas Feile am Mittwoch, 12. November 2003 23:12:
Hannes Vogelmann, Mittwoch, 12. November 2003 09:28:
Im Prinzip warest du aber wohl mit IMAP besser bedient.
Mit IMAP habe ich mich noch nicht beschäftigt, aber auch hier wäre ja das Problem, den Mails eine Lebensdauer zu geben.
IMAP verwaltet die Mails serverseitig, und ist genau für Problemstellungen wie Deine entworfen worden.
... sofern der Server das kann (bzw. man den entsprechende Zugriff hat, das einzurichten) und die Performance der Anbindung gut genug ist (IMAP via Internet mit Modem stell ich mir ziehmlich öde vor ;-).
Ich eben keinen Zugriff auf den Server, d.h. ich keine dort keine Einstellungen wie Lebensdauer, Weiterleitung usw... vornehmen. Ich kann ihn eben einfach nur pop3 mäßig leeren oder, was aber ganz entsetzlich schlecht funktioniert, mit OnlineWebAccess zugreifen. Letztreres ist aber wirklich das allerletzte!
Dann bleibt wohl nur noch der Weg über ein eigenes kleines Script, dass via telnet auf den POP-Server (Port 110) zugreift (sofern du kein entsprechendes Programm findest - ich hab keins gefunden, aber mir reicht auch die Lösung mit dem Sonntagnacht-Löschen).
Nachdem du dich mit USER <name> und PASS <passwort> am Server angemeldet hast, steht dir das entsprechende Postfach zur freien Verfügung.
Mit LIST werden alle Mails mit lfd. Nummer und Länge in Byte zeilenweise aufgerufen. Leider kann man das nicht weiter verwenden, außer evtl. für die Anzahl aller Bytes. Du könntest z.B. hier ansetzen und immer die erste Hälfte aller Mails löschen (oder die ersten 10 % oder so).
Naja, da gefällt mir Sonntag Nacht besser ;-)
Oder du rufts Mail für Mail mit RETR <x> (x ist die laufende Nummer) auf und entscheidest jetzt nach best. Kriterien im Header, ob du sie löschen willst - z.B. über die Header-Zeile "Date ..." oder Arrival-Date ...". Mit DELE <x> wird die betreffende Mail dann gelöscht (richtig gelöscht wird eigentlich erst, wenn du die Sitzung ordnungsgemäß mit QUIT beendest - also nicht vergessen, sonst sind alle Mails das nächste Mal wieder da ;-).
Mit dem Befehl TOP <x> kann man ja auch nur die Header runterladen. Jetzt müsste man nur noch ein perlscript haben, das das automatisch macht und das Datum aus den Headern extrahiert und dann mit DELE (x) die älteren Mails löscht und anschließend eines normales fetchmail auslöst. Leider mangelt es mir an dazu an den nötigen perl-Kenntnissen.
Tipp: Ich würde erst einmal die Variante 1 probieren (Anzahl aller Mails bestimmen, davon die ersten x % löschen). Variante 2 ist dann schon ein wenig anspruchsvoller.
Habe es mal händisch probiert und es funktioniert. Nur woher ein script nehmen, dass das für mich macht? Naja vielleicht schlage ich mich die Nacht doch mal mit dem Perl-Manual herum ;-). cu Hannes
Hannes Vogelmann am Donnerstag, 13. November 2003 21:55:
Am Don, 13 Nov 2003, schrieb Matthias Houdek:
Hannes Vogelmann am Donnerstag, 13. November 2003 17:13:
Am Don, 13 Nov 2003, schrieb Matthias Houdek:
Andreas Feile am Mittwoch, 12. November 2003 23:12:
Hannes Vogelmann, Mittwoch, 12. November 2003 09:28:
> Im Prinzip warest du aber wohl mit IMAP besser bedient.
Mit IMAP habe ich mich noch nicht beschäftigt, aber auch hier wäre ja das Problem, den Mails eine Lebensdauer zu geben.
IMAP verwaltet die Mails serverseitig, und ist genau für Problemstellungen wie Deine entworfen worden.
... sofern der Server das kann (bzw. man den entsprechende Zugriff hat, das einzurichten) und die Performance der Anbindung gut genug ist (IMAP via Internet mit Modem stell ich mir ziehmlich öde vor ;-).
Ich eben keinen Zugriff auf den Server, d.h. ich keine dort keine Einstellungen wie Lebensdauer, Weiterleitung usw... vornehmen. Ich kann ihn eben einfach nur pop3 mäßig leeren oder, was aber ganz entsetzlich schlecht funktioniert, mit OnlineWebAccess zugreifen. Letztreres ist aber wirklich das allerletzte!
Dann bleibt wohl nur noch der Weg über ein eigenes kleines Script, dass via telnet auf den POP-Server (Port 110) zugreift (sofern du kein entsprechendes Programm findest - ich hab keins gefunden, aber mir reicht auch die Lösung mit dem Sonntagnacht-Löschen).
Nachdem du dich mit USER <name> und PASS <passwort> am Server angemeldet hast, steht dir das entsprechende Postfach zur freien Verfügung.
Mit LIST werden alle Mails mit lfd. Nummer und Länge in Byte zeilenweise aufgerufen. Leider kann man das nicht weiter verwenden, außer evtl. für die Anzahl aller Bytes. Du könntest z.B. hier ansetzen und immer die erste Hälfte aller Mails löschen (oder die ersten 10 % oder so).
Naja, da gefällt mir Sonntag Nacht besser ;-)
Oder du rufts Mail für Mail mit RETR <x> (x ist die laufende Nummer) auf und entscheidest jetzt nach best. Kriterien im Header, ob du sie löschen willst - z.B. über die Header-Zeile "Date ..." oder Arrival-Date ...". Mit DELE <x> wird die betreffende Mail dann gelöscht (richtig gelöscht wird eigentlich erst, wenn du die Sitzung ordnungsgemäß mit QUIT beendest - also nicht vergessen, sonst sind alle Mails das nächste Mal wieder da ;-).
Mit dem Befehl TOP <x> kann man ja auch nur die Header runterladen. Jetzt müsste man nur noch ein perlscript haben, das das automatisch macht und das Datum aus den Headern extrahiert und dann mit DELE (x) die älteren Mails löscht und anschließend eines normales fetchmail auslöst. Leider mangelt es mir an dazu an den nötigen perl-Kenntnissen.
Das müsste auch ein Shell-Script schon packen. -- Gruß MaxX 8-)
Hannes Vogelmann am Donnerstag, 13. November 2003 17:13:
Ich eben keinen Zugriff auf den Server, d.h. ich keine dort keine Einstellungen wie Lebensdauer, Weiterleitung usw... vornehmen. Ich kann ihn eben einfach nur pop3 mäßig leeren oder, was aber ganz entsetzlich schlecht funktioniert, mit OnlineWebAccess zugreifen. Letztreres ist aber wirklich das allerletzte!
Nachtrag zu meinem Script-Vorschlag (man sollte immer erst zu Ende denken, bevor man abschickt): Die Anzahl der Mails geht ja viel einfacher als über LIST - nämlich mit STAT. Ergebnis: Anzahl der Mails und deren Gesamtspeicherbedarf. Und mit UIDL kannst du dir auch eine Liste mit den laufenden Nummern und nachfolgend der MSG-ID ziehen. Dann kannst du auch vorher über deine lokale UIDL-Datei auswerten [1], welche Datei du löschen willst und dann über die ID löschen (also über UIDL die betreffende lfd. Nummer bestimmen und dann löschen). [1] Z.B. indem du für jeden Tag eine neue UIDL-Datei anlegst und dann die jeweilige alte Datei mit dem Script abarbeitest. -- Gruß MaxX 8-)
David Haller am Dienstag, 11. November 2003 23:17:
Hallo,
Am Tue, 11 Nov 2003, hannes.vogelmann@imk.fzk.de schrieb:
2. die Option --uidl legt eine Liste der abgeholten Mail-IDs an und verhindert so das doppelte Abholen.
[..]
Auf meine Mailbox kann ich jetzt endlich nach vielen Diskussionen mit den Admins von außen via pop zugreifen, dass erledigt ein fetchmaildaemon auf einem weit entfernten Rechner alle 100s mit der option --keep und --uidl. Es könnten weitere entfernte Rechner hinzukommen, die es auch so machen. Soweit so gut. Jetzt gibt es aber einen Rechner, der mit seinem fetchmail die Mailbox final lesen und entleeren soll. Wenn dieser jetzt alle mails flusht, kann es passieren, dass Mails final gelöscht werden, bevor die entfernten daemonen die Mail holen konnten. Leider kann ich den Mailserver (MSExchange) in keinster Weise konfigurieren und dort auch keine Mailweiterleitung zu einer besser konfigurierbaren pop3-Mailbox einrichten.
Dann hast du ein grundsaetzliches Problem, das geht prinzipbedingt nicht mit POP3. Wie sollen die verschiedenen Clients denn auch miteinander absprechen, wer jetzt schon welche Mails geholt hat?
Ich denke mal, dass das Problem eher darin besteht, dass eine Mail weniger als eine bestimmte Mindestzeit auf dem Server liegt. Wenn eine Mail z.B. nach 5 oder 7 Tagen von einer "Außenstelle" nicht geholt wurde, kann man i.d.R. davon ausgehen, dass die Außenstelle zurzeit nicht aktiv ist. Dann kann sie nach dem Abholen ins zentrale Postfach in der Firma beim Provider gelöscht bedenkenlos gelöscht werden. Ich löse es hier so (ein zentraler Meilserver beim Provider, 3 lokale Standorte mit festem Mitarbeiter-Stamm und ca. 10 Mitarbeiter an wechselnden Plätzen), dass an den 3 Standorten alle Mails für die jeweils lokal verwalteten Postfächen laufend mit keep/uidl gePOPt werden. Damit kann trotzdem jeder MA seine Mail auch noch an anderer Stelle holen bzw. über den Web-Mailer des Providers lesen, aber sie sind auf jeden Fall auch zentral am Arbeitsplatz vorhanden. In der Nacht vom Sonntag zum Montag werden dann die Postfächer beim Privider löschend abgeholt und auch die UIDL-Datei lokal gelöscht (neue Woche - neue Liste). Wer also bis Sonntagabend seine Mails nicht woanders gelesen hat, muss dann ab Montag eben zu seinem Arbeitsplatz fahren, wenn er sie noch lesen will. Wenn du die Mails zielgerichtet nach Datum/Alter löschen willst, dann müsstest du dir dafür ein Script basteln, was die UIDL-Datei auswertet und die betreffenden Mails einzeln via POP löscht (IMHO sollte das über die Angabe der Mail-ID gehen).
Eine Idee waere vielleicht, wenn du eine Art "zentrale" DB mit den UIDLs (z.B.) fuehrst und jeweils vermerktst, welcher Client welche Mails schon geholt hat...
Naja, ich denke mal, es soll für eine bestimmte Zeit möglich sein, die Mails auch ggf. mehrfach abholen zu können.
Evtl. koennte man z.B. auch fetchmail durch ein perl-script (mit Net::*) ersetzen, das die Mails holt (mit keep/uidl oder sonstwie) und dann die geholten Mails (UIDLs) an den zentralen Server meldet. Oder man liest die UIDLs, die fetchmail speichert (wo? wie? keine Ahnung!) und meldet diese dann "irgendwo zentral"... Das waere wohl einfacher...
Im Prinzip warest du aber wohl mit IMAP besser bedient.
... wenn es der Provider denn unterstützt. Oder man holt die Mails selbst auf einen eigenen Postserver, der die Nachrichten dann via IMAP anbietet. -- Gruß MaxX 8-)
participants (6)
-
Andreas Feile -
David Haller -
Hannes Vogelmann -
hannes.vogelmann＠imk.fzk.de
-
Martin Mewes -
Matthias Houdek