Laut Strato arbeiten sie daran. Sie wissen auch das das nur bei ihnen passiert.
Was ich noch festgestellt habe ist, wird die Mail von Googlemail verschickt, erscheint dieser Zusatz nicht.
In jedenfall manipulieren die bei Strato den Header, wissen aber scheinbar selbst nicht mehr was sie tun.
Übers Wochenende wird da nicht mehr viel passieren.
Um den Druck zu erhöhen, bei Strato beschweren, je mehr desto besser.
Willkommen!
Wenn du im Nexave-Forum mitmachen möchtest, schreib an community@nexave.de. Wir haben die Registrierungsfunktion in unserem Diskussionsforum nämlich deaktiviert, weil sich praktisch nur noch Spammer und Werbebots registriert haben. Per E-Mail sind wir dir gern behilflich, einen Account anzulegen.
-
-
echt ein kleiner witz. war schon fast soweit, das konto beim pre auf pop umzustellen. aber das kann doch nicht der weisheit letzter schluß sein. wenn das am montag immer noch ist, dann kriegen sie die dritte mail von mir. es nervt mich mittlerweile sehr.
-
mach das.
-
Oja, bitte tu es.
-
Ich hab' denen gerade nochmal eine Mail dazu geschrieben. Dieses Mal mit etwas schärferer Wortwahl
-
Ich habe dem Strato-Support jetzt auch mal ne Mail mit einem Verweis auf diesen Thread geschickt. Bin mal gespannt, wie und vor allem wann eine Lösung gefunden wird...
/Seppi
-
Hab auch nochmal geschrieben. Immerhin bekam ich schon mal postwendend Antwort mit der Bitte um Geduld. Der Fall sei bekannt, man würde sich um die Sache kümmern.
Ich hoffe, sie tun es auch und präsentieren einem nicht in einer Woche ne Antwort, in der es dann heißt, der Fehler liege beim Smartphone...
Mittlerweile ist mein Posteingang ein einziges Chaos. Über 30 Mails mit "01.01.70, 0100" sind bereits aufgelaufen. Sich darin zu orientieren wird immer schwieriger und nerviger. Zwar nutze ich jetzt verstärkt den Strato-Webmailer, aber immer hat man den ja auch nicht verfügbar.
VG
-Nils.
-
In meiner (Strato) Mailbox habe ich viele Mails, bei denen manche einen Date-Header ohne Zeitzone und manche mit Zeitzone haben. Viele verschiedene Zeitzonen aus aller Herren Länder. Strato setzt die also nicht ein, die sind einfach schon so vom Absender angekommen.
Habe mal im RFC2822 nachgesehen, wie ein Date-Header aufgebaut sein muss:
3.3. Date and Time Specification
date-time = [ day-of-week "," ] date FWS time [CFWS] (man beachte das CFWS, siehe weiter unten!)3.2.3. Folding white space and comments
White space characters, including white space used in folding
(described in section 2.2.3), may appear between many elements in
header field bodies. Also, strings of characters that are treated as
comments may be included in structured field bodies as characters
enclosed in parentheses. The following defines the folding white
space (FWS) and comment constructs.
Strings of characters enclosed in parentheses are considered comments
so long as they do not appear within a "quoted-string", as defined in
section 3.2.5. Comments may nest.Die Behauptung, daß der Zeitzonen-Kommentar in "" eingeschlossen sein
muß, ist also definitiv falsch!There are several places in this standard where comments and FWS may
be freely inserted. To accommodate that syntax, an additional token
for "CFWS" is defined for places where comments and/or FWS can occur.
...
comment = "(" *([FWS] ccontent) [FWS] ")"
CFWS = *([FWS] comment) (([FWS] comment) / FWS)Hier steht also: CFWS darf Kommentare enthalten. Kommentare sind optional und in runden Klammern eingeschlossen und nicht in "".
Fazit:
Die Date-Header mit den Zeitzonen sind absolut okay, und werden auch nicht von Strato "verändert".
Das Problem liegt wohl in der Palm Software. -
Das Problem das die nicht geschützt werden ergibt sich aus dem DB Eintrag im WebOS, "nicht" in der Headerzeile.
Wobei ich mir da auch nicht mehr so sicher bin da Mails vom Googlemail diesen Eintrag nicht haben, trotzdem
stimmt das Datum nicht.
Wegen der Änderung, ja es ist erlaubt die Date: Zeile so auszugeben, was ich bemängele ist das Strato diese
"nachträglich" Ändert! Wenn ich eine Mail von einem neutralen Mailer schicke, z.b. web.de, und strato in cc
stelle, steht in der Date: Zeile dann eben bei Strato der Zusatz und das nur bei IMAP.
Probier es selbst mal aus. Natürlich kann jedes Postamt an den Header Zeilen zufügen, aber nicht vorhandene
korigieren.
Das es daran , zumindest nicht allein, liegt bin ich mir wie gesagt auch nicht mehr sicher, konnte aber die
letzten zwei Tage da nicht mehr nachforschen da ich selbst gerade sehr eingespannt bin.
Das da aber von Strato eine Änderung vorgenohmen wurde, haben andere schon bestätigt die Mails von
davor (1.6) überprüft haben und dort eben diese Änderungen noch nicht vorgenohmen wurden.Ärgerlich finde ich in diesem Zusammenhang das da von Strato an dem System Änderungen erfolgt sind und
nun man die Sache einfach aussitzen will (warum stellt man nicht zurück), ja man dem Kunden sogar sagt,
wir haben da nichts geändert.Das der Timezone Zusatz in Klammern der Grund für den Fehler ist, dachte ich aufgrund dessen weil ich
diesen eben in der PalmDB nur in der Stratomail gesehen hatte und Palm die Einträge dort sonst auch mit
() trennt. Und ich wiederhole, wenn ich die Mail über Strato SMTP schicken würde und dieser dann dort
auftauchen würde hätte ich da keine Einwände, wenn ich diese aber über einen beliebigen Sendmail
schicke und er wird dann nachträglich zugefügt finde ich das nicht in Ordnung.Sollte diese Mail von einem Strato Mitarbeiter sein währe es nett er würde mal kundtun was und warum
da geändert wurde, ich zitiere "Das dieser Fehler nur bei uns vorkommt ist uns auch bekannt"Anstelle das RFC zu zitieren währe es also freundlicher die Kunden nicht im Nebel stehen zu lassen.
edit:
- Fazit:
- Die Date-Header mit den Zeitzonen sind absolut okay, und werden auch nicht von Strato "verändert".
- Das Problem liegt wohl in der Palm Software.
Das ist, wenn diese Aussage von Strato kommt, eine Frechheit! -
Hallo
opaaladin(Das ist, wenn diese Aussage von Strato kommt, eine Frechheit!)
Sollte ich damit jemandem auf den Schlips getreten haben bitte ich hiermit in aller Form um Vergebung, das war nicht meine Absicht (wollte nur etwas sachlichen Hintergrund beitragen).
Bin hier übrigens als Privatperson unterwegs.
Um Deine Aussage zu überprüfen habe ich habe mal per Telnet eine Mail über den Strato Mailer in meine Strato Mailbox gesendet. Als Datum habe ich "Tue, 06 Apr 2010 15:27:16 +0300" eingegeben, also ohne Zeitzone. Wenn Deine Aussage stimmt müsste ja bei der Abfrage per IMAP eine Zeitzone auftauchen:
telnet mailin.rzone.de 25
Trying 81.169.145.102...
Connected to mailin.rzone.de.
Escape character is '^]'.
220 mailin.webmailer.de [hamish mi61] ESMTP RZmta 23.2 ready; Mon, 7 Jun 2010 21:35:22 +0200 (MEST)
ehlo bla
250-mailin.webmailer.de [hamish mi61] greets ***************
250-ENHANCEDSTATUSCODES
250-8BITMIME
250-PIPELINING
250-DELIVERBY
250-SIZE 104857600
250 HELP
mail from: <bla@blubb.de>
250 2.1.0 <bla@blubb.de> Sender ok
rcpt to: <****************>
250 2.1.5 <****************> Recipient ok
data
354 Enter data for mail with id Z067c2m57JMfAM
Subject: Mail Date Test
Date: Tue, 06 Apr 2010 15:27:16 +0300
Message-ID: <0253C02FB22224448664F12B901D394D09870BD8@blubb.de>
From: bla@blubb.de
To: ****************Test test.
.
250 2.1.5 OK mail delivered with id Z067c2m57JMfAM
quit
221 2.0.0 mi-ob.rzone.de closing connection
Connection to mailin.rzone.de closed by foreign host.
Und dann die Mail per POP3 abgeholt:telnet pop3.strato.de 110
Trying 81.169.145.131...
Connected to pop3.strato.de.
Escape character is '^]'.
+OK POP3 server ready <4144553.3534.1275939681@post.webmailer.de>
user **********
+OK Waiting for password
pass **********
+OK User logged in, proceed.
retr 1
+OK Message follows
X-Envelope-From: <bla@blubb.de>
X-Envelope-To: <*********>
X-Delivery-Time: 1275939469
X-UID: 55
Return-Path: <bla@blubb.de>
X-RZG-CLASS-ID: mi
Received: from bla (*************************)
by mailin.webmailer.de (hamish mi61) (RZmta 23.2)
with ESMTP id Z067c2m57JMfAM for <*********>;
Mon, 7 Jun 2010 21:35:42 +0200 (MEST)
Subject: Mail Date Test
Date: Tue, 06 Apr 2010 15:27:16 +0300
Message-ID: <0253C02FB22224448664F12B901D394D09870BD8@blubb.de>
From: bla@blubb.de
To: ********Test test.
.
quit
+OK Closing connection
Connection to pop3.strato.de closed by foreign host.
Und das ganze noch per IMAP:telnet imap.strato.de 143
Trying 81.169.145.103...
Connected to imap.strato.de.
Escape character is '^]'.
* OK IMAP server ready [57]
a login ******** *********
a OK LOGIN completed [373]
b select inbox
* 1 EXISTS
* OK [UNSEEN 1]
* 0 RECENT
* FLAGS (Junk NonJunk $Forwarded $MDNSent \Answered \Flagged \Deleted \Seen \Draft \Forwarded)
* OK [PERMANENTFLAGS (Junk NonJunk $Forwarded $MDNSent \* \Answered \Flagged \Deleted \Seen \Draft \Forwarded)] Permanent flags
* OK [UIDVALIDITY 1235748364] UIDVALIDITY value
* OK [UIDNEXT 2437] may be the next UID value
b OK [READ-WRITE] SELECT completed
c fetch 1 rfc822.header
* 1 FETCH (RFC822.HEADER {531}
X-Envelope-From: <bla@blubb.de>
X-Envelope-To: <****************>
X-Delivery-Time: 1275939469
X-UID: 55
Return-Path: <bla@blubb.de>
X-RZG-CLASS-ID: mi
Received: from bla (***********************)
by mailin.webmailer.de (hamish mi61) (RZmta 23.2)
with ESMTP id Z067c2m57JMfAM for <****************>;
Mon, 7 Jun 2010 21:35:42 +0200 (MEST)
Subject: Mail Date Test
Date: Tue, 06 Apr 2010 15:27:16 +0300
Message-ID: <0253C02FB22224448664F12B901D394D09870BD8@blubb.de>
From: bla@blubb.de
To: ***************)
c OK Fetch complete
q logout
* BYE
q OK LOGOUT completed
Connection to imap.strato.de closed by foreign host.
Fazit: Weder beim Abholen mit IMAP, noch mit POP3, wird der Date-Header irgendwie verändert. Das ist es, was ich meine.Es gibt aber eine Chance, daß es trotzdem zu dem von Dir geschilderten Szenario kommt. Allerdings werden dabei keine Date-Header verändert, sondert eingefügt:
Wenn das absendende Mailprogramm keinen Date-Header in die Mail schreibt, sondern es den SMTP Servern überlässt, diesen einzufügen, dann kann es passieren, daß der Strato-Mailserver einen Date-Header mit Zeitzone einfügt, der andere Mailserver (von Deiner anderen Testmailbox) aber einen Date-Header ohne Zeitzone. Das ist dann aber auch okay und kein Fehler; keine der originalen Headerzeilen wurden dabei verändert, lediglich der fehlende Header ergänzt.Du kannst es ja mal auf die oben beschriebene Weise (per Telnet!) ausprobieren, ob das so ist. Du brauchst aber eine fixe IP damit der Strato SMTP-Server Dir die Mail abnimmt. Mit einer (dynamischen) DSL-IP geht das nicht.
-
Womit aber immer noch nicht geklärt wäre, was Strato in der Nacht vom 31.05.2010 auf den 01.06.2010 an den IMAP-Servern geändert hat...
-
Genau diese Test habe ich ja gemacht, +0200 == (MEST), also in der Form " +0200 (MEST)" doppelt gemoppelt.
Das ist aber nicht das Problem. Mir ist nur aufgefallen das ich eben Mails von zuhause über Arcor SMTP versand
mit cc an Strato diesen Zusatz (MEST) plötzlich in der Date Zeile hatten, während die an z.b. web.de oder unseren
Firmenserver versendeten diese nicht hatten. Also wurde das (MEST) eingefügt.
Irtümlich hatte ich angenohmen das der Pre sich an dem () verschluckt da bei sichtung der DB ich festgestellt hatte
das der Pre den Header ausliest und dann in seiner DB abspeichert, dabei trennt er Datum, Subject, Absender durch
(). Das das nicht stimmt, also der Fehler nicht an dem zwei Klammern liegt, hatte ich inzwischen auch bemerkt, da ich
Mails vom Googleaccount mit diesem zusatz im Pre sauber angezeigt werden.
Klar kann man da jetzt Palm ins boot holen, da es auch scheinbar nur WebOS Geräte sind die dieses Problem haben?
Wissen tun wir als Kunde das aber nicht, da wir ja nicht wissen wer mit welchen Mailprog sich wegen einem Fehler
seit dem 1.6 bei Ihnen meldet.
Aber die Aussage "wir haben da nichts geändert" stimmt jedenfalls nicht.Was mir am Pre dabei noch aufgefallen ist, seit dem 1.6 hat er in der gleichen DB als Timestamp eine 0 bei Stratomails,
was bestimmt der wahre grund ist warum er dieses falsche Datum anzeigt (0 = 1.1.1970 start der unix time).
Wie schon gesagt, bin ich gerade etwas eng mit der Zeit sonst hätte ich bei Palm schon längst mal angefragt woher die
das Datum nehmen, meine Annahme die ziehen das aus dem Date: string ist ja scheinbar falsch.
Allerdings ist der Palm support in dieser hinsicht auch nicht immer einfach und da schiebt dann jeder wieder den Ball
zurück. Ganz unrecht haben die dann dabei aber nicht, den solange Strato sagt wir haben "nichts" geändert stellt
sich schon die Frage warum das "jetzt" Plötzlich passiert. Ein Datum umstellen bringt auch nichts (am Pre z.b.),
das passiert eindeutig nach dem 1.6 für alle neu abgefragten Mails vom Strato IMAP egal welche Zeit der Pre hat.
Also kann man wohl einen Programmierfehler (Überlauf) von WebOS ausschliessen.
Ob der Fehler allerdings im Sytem liegt, da im WebOS alles über html läuft können da durchaus Unverträglichkeiten
bestehen, kann man nicht sagen solange Strato sagt "alles wie immer", da es bis zu diesem Datum ja lief.Anders währe die situation wenn Strato z.b. sich outen würde und sagen, ja wir haben von Courier auf Dovecot
umgestellt, dann könnte man Palm eine Bugmeldung mit Hand und Fuß schicken, am besten vielleicht noch wenn
man rausfinden könnte wo es gerade hackt. So ist die Situation ziemlich bescheiden für Strato Kunden die ein
WebOS Gerät verwenden (oder gibt es noch andere Kunden mit möglicherweise anderen Problemen aber auch
seit dem 1.6?) -
Mir ist bei weiteren Tests mit dem Strato IMAP-Server folgendes aufgefallen:
Mail aus diesem Monat:
c fetch 85 INTERNALDATE
* 85 FETCH (INTERNALDATE " 5-jun-2010 18:00:52 +0200") Mail aus vorigem Monat:
c fetch 77 INTERNALDATE
* 77 FETCH (INTERNALDATE "28-May-2010 15:06:05 +0200")Man achte auf den Monatsnamen: im Juni klein geschrieben, im Mai mit grossem Anfangsbuchstaben.
Das INTERNALDATE ist der Zeitpunkt, zu welchem das Mailsystem die Mail wirklich erhalten hat (unabhängig davon, was im Date Header steht). Dieser Header wird vom IMAP Server selbst erzeugt.Der RFC 3501 (IMAP) sagt dazu:
date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"Da sind alle mit grossen Anfangsbuchstaben. Aber in den Beispielen gibt es dort auch andere Schreibweisen, z.B "13-APR-2000". Es ist unklar, ob Gross-/Kleinschreibung an dieser Stelle Pflicht und/oder relevant ist.
Ich habe dazu foldende Theorie:
Palm nutzt nicht den Date-Header aus den Mail, sondern den vom IMAP Server erzeugten INTERNALDATE Header. Beim Konvertieren des Date-Time Strings in das interne UNIX Format vergleicht er den Monatsnamen mit "Jun", was aber nicht zu "jun" passt. Er findet keinen (aus seiner Sicht) gültigen Monatsnamen, und in seiner Not setzt er den UNIX Timestamp auf 0, was genau dem 01.07.1970 entspricht.Das erklärt, warum, obwohl Strato und Palm behaupten, die Software nicht getauscht zu haben, der Fehler genau am 01.06. auftrat. Er war einfach schon immer drin. Daß andere Mailprogramme damit klarkommen spricht eher dafür, daß Gross-/Kleinschreibung bei dem Monatsnamen egal ist, daß Palm an der Stelle zu pingelig ist. (wie gesagt nur eine Theorie, ich will wirklich niemandem auf die Füße treten...)
Bein Durchlesen der Mail RFCs bin ich auf einen schönen Spruch gestoßen, der ungefähr so ging:
"Mailprogramme sollen beim Erzeugen von Nachrichten so konservativ wie möglich, beim Auswerten von Nachrichten so tolerant wie möglich sein". Damit soll verhindert werden, daß genau so ein Fehler wie dieser passiert. Strato hätte dann gegen das Konservativitäts-Gebot verstoßen, Palm gegen das Toleranz-Gebot. Im Prinzip, wenn meine Theorie stimmt. müsste es reichen, wenn einer von beiden seine Software ändert. Dann wäre das Problem mit einem Schlag weg, selbst bereits empfangene Mails hätten dann plötzlich wieder ein richtiges Datum. Ansonsten wird sich das Problem wohl am 01.07 von allein lösen, zumindest für neue Mails.Ich versuche das mal bei Strato einzutüten. In der Zwischenzeit mag ja jemand Anders mal versuchen Palm zu überzeugen. Mal sehen wer gewinnt.
-
@Brakel: Wenn Du weiter hier im Forum schreiben möchtest, melde Dich bitte an. Der Gastzugang ist nur für's ein-, zweimalige Posten gedacht oder falls jemand seine Accountdaten gerade mal nicht verfügbar hat. Weitere Beiträge können wir ansonsten leider nicht mehr freischalten. Du bist herzlich willkommen - Danke für Dein Verständnis.
-
Wollte meine Unterstützung nur kurz in Form von: Ein weiterer Fall anbieten.
Werde auch den Support anmailen.
Vielen Dank an die die sich mit Hiuntergrundwissen engagieren! -
Wo liegen nochmal die Built-in Apps des Pre? Vielleicht lässt sich das Problem auch durch Studium der Mail-Applikation eingrenzen/patchen?
-
den it-göttern sei's gedankt: gerade eben erreicht mich eine strato-imap-e-mail mit korrektem datum!
danke, danke, danke!
-
Strike, sie haben's offenbar gefixt
-
Jepp funktioniert wieder - was auch immer nun die Ursache war, beim Pre lag sie wohl nicht ...
-
Und mir hat der Support gestern erst geschrieben es würde an Pre legen ...
