fetchmail holt mails mehmals ab mit eigens gesetzem Datum

[ets]

hallo,
ich hab zwar mehrere Forum-Einträge gefunden, aber keine zufriedenstellende Lösung. Ich bin dabei einen Mail-Server einzurichten. Dabei hab ich versucht mich an c't soweit wie möglich zu halten, doch die Angaben dort sind viel zu optimistisch. Es geht um das Abholen von Mails mittels fetchmail (um sie der zarafa Gruopware bereit zu stellen).

Ich hab eine /etc/fetchmailrc erzeugt mit folgenden Einträgen:
set daemon 60
poll <provider server> protocol pop3 interval 10 user "<nutzername beim hoster>" password "<pw beim hoster>" options ssl smtpaddress localhost keep forcecr mda "/usr/bin/zarafa-dagent <username zarafa-Groupware>"

Laut Anleitung noch folgendes:
chmod 600 /etc/fetchmailrc
chown fetchmail /etc/fetchmailrc

Mit diesen Einstellungen werden die Emails beim Provider alle 10 min. abgeholt. Die nächtsten 10 min. erneut dieselben Nachrichten. Darüber hinaus sind Datum/Uhrzeit die beim abholen der Mails und nicht die originalen.

In /var/log/syslog ist manchmal folgendes zu sehen - aber nur manchmal. Das Ergebnis ist dasselbe:
Jul 1 22:08:39 ubuntu32 fetchmail[4959]: 10 messages for <Email-Adresse> (47128 octets).
Jul 1 22:08:39 ubuntu32 fetchmail[4959]: reading message <Email-Adresse>:1 of 10 (1178 octets) not flushed
Jul 1 22:08:39 ubuntu32 fetchmail[4959]: reading message <Email-Adresse>:2 of 10 (14943 octets) not flushed
Jul 1 22:08:39 ubuntu32 fetchmail[4959]: reading message <Email-Adresse>:3 of 10 (1131 octets) not flushed
Jul 1 22:08:40 ubuntu32 fetchmail[4959]: reading message <Email-Adresse>:4 of 10 (1715 octets) not flushed
Jul 1 22:08:40 ubuntu32 fetchmail[4959]: reading message <Email-Adresse>:5 of 10 (1709 octets) not flushed
Jul 1 22:08:40 ubuntu32 fetchmail[4959]: reading message <Email-Adresse>:6 of 10 (1454 octets) not flushed
Jul 1 22:08:40 ubuntu32 fetchmail[4959]: reading message <Email-Adresse>:7 of 10 (1330 octets) not flushed
Jul 1 22:08:40 ubuntu32 fetchmail[4959]: reading message <Email-Adresse>:8 of 10 (8586 octets) not flushed
Jul 1 22:08:41 ubuntu32 fetchmail[4959]: reading message <Email-Adresse>:9 of 10 (2794 octets) not flushed
Jul 1 22:08:41 ubuntu32 fetchmail[4959]: reading message <Email-Adresse>:10 of 10 (12288 octets) not flushed

Ich hab einige andere Optionen ausprobiert und fetchmail neu gestartet aber keinen Erfolg. Habt Ihr noch irgenwelche Ideen?

[DrunkenFreak]

Was geht denn da jetzt nicht? Er holt sie doch scheinbar richtig ab. Starte fetchmail im Vordergrund und mache ihn gesprächiger. Irgendwas sollte er da schon rausspucken, was interessant ist.

[derfele]

Hi,

der Parameter "keep" in deinem Fetchmail Befehl sagt Fetchmail, dass er die Mails auf dem Server belassen soll.

Auch das die Uhrzeit im Zarafa der Abrufzeit entspricht ist völlig normal, da dir der Zarafa WebAccess die Uhrzeit der Zustellung auf dem Zarafa System anzeigt.

[mkahle]

Versuche doch mal die Option "uidl" ...

[ets]

Was geht denn da jetzt nicht? Er holt sie doch scheinbar richtig ab.
Nicht wenn er die gleichen mails immer wieder und wieder abholt und den Posteingang füllt.


der Parameter "keep" in deinem Fetchmail Befehl sagt Fetchmail, dass er die Mails auf dem Server belassen soll.
Der Befehl keep sollte alle Nachrichten auf dem Server belassen, das ist richtig. Aber er sollte nicht dazu führen, dass immer wieder die gleichen Nachrichten pro Abholungsintervall abgeholt werden.


Auch das die Uhrzeit im Zarafa der Abrufzeit entspricht ist völlig normal, da dir der Zarafa WebAccess die Uhrzeit der Zustellung auf dem Zarafa System anzeigt.
Das verhält in Outlook anders, was ich gerade benutze. Dort entspricht die Zeit NICHT dem Zeitpunkt der Abholung, sondern es ist dieselbe wie beim Provider. Meinst Du ich muss am zarafa Server herumkonfigurieren?


Versuche doch mal die Option "uidl" ...
Das hatte ich gestern auch versucht, ohne Erfolg. Mit und ohne die option, es ist dasselbe...

[ets]

hier ne ausgabe env LC_ALL=C fetchmail -vvv --nodetach --nosyslog

fetchmail: POP3> LIST 10
fetchmail: POP3< +OK 10 1656
fetchmail: POP3> RETR 10
fetchmail: POP3< +OK 1656 octets
reading message <email adresse>:10 of 10 (1656 octets) About to rewrite Return-path: <wlikdwzejvb@hotmail.com>...
...rewritten version is Return-path: <wlikdwzejvb@hotmail.com>.
About to rewrite From: "Felix Keller" <wlikdwzejvb@hotmail.com>...
...rewritten version is From: "Felix Keller" <wlikdwzejvb@hotmail.com>.
About to rewrite Reply-To: "Felix Keller" <wlikdwzejvb@hotmail.com>...
...rewritten version is Reply-To: "Felix Keller" <wlikdwzejvb@hotmail.com>.
About to rewrite To: mhochreiter@freenet.de...
...rewritten version is To: mhochreiter@freenet.de.
fetchmail: about to deliver with: /usr/bin/zarafa-dagent <user zarafa>
#************************fetchmail: message <email adresse>:10 was not the expected length (1658 actual != 1656 expected)
not flushed
fetchmail: POP3> QUIT
fetchmail: POP3< +OK
fetchmail: 6.3.21 querying <provider server> (protocol POP3) at Mon Jul 2 14:58:11 2012: poll completed
New UID list from <provider server>: <empty>
fetchmail: not swapping UID lists, no UIDs seen this query
fetchmail: sleeping at Mon Jul 2 14:58:11 2012 for 60 seconds
fetchmail: awakened at Mon Jul 2 14:59:11 2012
fetchmail: interval not reached, not querying <provider server>
fetchmail: sleeping at Mon Jul 2 14:59:11 2012 for 60 seconds
fetchmail: awakened at Mon Jul 2 15:00:11 2012
fetchmail: interval not reached, not querying <provider server>
fetchmail: sleeping at Mon Jul 2 15:00:11 2012 for 60 seconds

ist nur ne spam mail

[DrunkenFreak]

Nicht wenn er die gleichen mails immer wieder und wieder abholt und den Posteingang füllt.

Dann sage ihm halt, dass er die Mails nicht alle abholen soll, sondern nur die neuen.



Das verhält in Outlook anders, was ich gerade benutze. Dort entspricht die Zeit NICHT dem Zeitpunkt der Abholung, sondern es ist dieselbe wie beim Provider. Meinst Du ich muss am zarafa Server herumkonfigurieren?

Das liegt daran, dass fetchmail an den lokalen MTA zustellt. Ich glaub nicht, dass man das irgendjmd abgewöhnen kann.

[derfele]

Das liegt daran, dass fetchmail an den lokalen MTA zustellt. Ich glaub nicht, dass man das irgendjmd abgewöhnen kann.
In der Tat liegt dies tatsächlich eher am Client. Mange Clients zeigen die "Gesendet" Zeit andere die "Empfangen" Zeit. Der Zarafa WebAccess, alle Androiden die ich kenne (und übrigens auch Outlook) zeigen per Default die Uhrzeit, wann eine E-Mail empfangen wurde, Thunderbird (und auch Outlook in den Nachrichtendetails) zeigt aber die Uhrzeit, wann eine E-Mail gesendet wurde.

[ets]

@derfele
Ja. scheint richtig zu sein, was du schreibst. Liegt eher am client :(

Inzwischen hab ich nen server eines anderen hosters ausprobiert. Dort gibt kein Problem mit mehrfacher Mailabholung. Was an den ersten server dran ist - keine Ahnung.