Grabbing Server lädt keine E-Mails mehr herunter

    Moin,


    seit mehreren Tagen bekommen wir keine neuen E-Mails mehr (Verbindung: pop3 - ssl/tls).


    Ausgangssituation:

    David läuft mit der Version 11.00a - 2378 auf dem Microsoft Server 2008.

    Aktuell werden von David die E-Mails nicht mehr von Strato heruntergeladen.

    Es hat wie durch ein Wunder mal kurz wieder funktioniert, danach aber auch nicht mehr.


    Was wir bisher getestet haben:

    Speicherplatz geprüft.

    Virenschutz überprüft.

    Den Grabber manuell in der Firewall zugelassen.

    E-Mail Empfang mit Thunderbird getestet: E-Mails sind angekommen.

    Server neugestartet.

    Router neugestartet.

    Grabbing Dienst manuell gestoppt und wieder gestartet.

    Benutzer entfernt und wieder hinzugefügt.

    DVGRAB.INI wie folge verändert:


    In Monitoring vom Grabbing Server kommt folgender Log (Vollständig):

    Exakt das gleiche Problem, seit dem 13.11. ca. 16:20 keine Mail über den pop3 Grabbingserver via Strato erhalten. Ähnliche Maßnahmen wie "tom" ergriffen, ohne Erfolg, Empfang über thunderbird funktioniert.

    Senderichtung verursacht keine Probleme!

    OS: Win server 2008R2

    David fx 12

    vereinzelnt gibt es Probleme, wenn man die MAils beim Provider auf dem Server belässt und nach x Tagen dort entfernt. Einfach mal testen, es temporär zu deaktivieren, dann wenn es geht wieder einschalten. Allerdings holt der dabei alles ab, wass noch im Postfach liegt. Das kann man denn aber ja gleich wieder löschen im jeweiligen Posteingang. Wenn einer wie ich immer noch mit einem Catchall Postfach arbeitet, betrifft es denn ja gleich alle User. Deshalb ist es wohl besser für jeden User ein Konto. Die Frage ist ob hier ein oder mehrere Konten betroffen sind.

    Gruß

    ComputerManni

    Hallo und vielen Dank für die Tipps, es handelt sich in der Tat um ein Catchall-Postfach. Werde es heute mit EInzelpostfächern ausprobieren. Habe die EDV-Abteilung inkl. David fx erst kürzlich übernommen, ich ging davon aus, dass Catchall der gängige Weg ist.

    LG

    Wenn ich das richtig im Kopf habe, werden die bereits abgerufenen Einträge in der DVGRAB.DAT unter \\...\david\apps\dvgrab\code\ gespeichert. Evtl. ist die defekt?

    Benenne mal die Datei um und starte den Grabbing Server neu.

    Vorher würde ich die bereits abgerufenen Mails vom POP3-Postfach löschen, weil die sonst nochmal neu abgerufen werden...

    Quote from QWERTZ

    Wenn ich das richtig im Kopf habe, werden die bereits abgerufenen Einträge in der DVGRAB.DAT unter \\...\david\apps\dvgrab\code\ gespeichert. Evtl. ist die defekt?

    Benenne mal die Datei um und starte den Grabbing Server neu.

    Vorher würde ich die bereits abgerufenen Mails vom POP3-Postfach löschen, weil die sonst nochmal neu abgerufen werden...

    Das hast du nicht richtig im Kopf ;) Die Info über bereits abgeholte Mails wurde früher in den *.lst Dateien gespeichert und seit etwa Jahresmitte in *.mldb Dateien.


    Also nicht die DVGRAB.DAT löschen !!!

    Quote from eddy V.

    Hallo und vielen Dank für die Tipps, es handelt sich in der Tat um ein Catchall-Postfach. Werde es heute mit EInzelpostfächern ausprobieren. Habe die EDV-Abteilung inkl. David fx erst kürzlich übernommen, ich ging davon aus, dass Catchall der gängige Weg ist.

    LG

    Catchall ist der gängige Weg und auch der welcher im Normalfall am wenigsten Zusatzarbeit bedeutet.
    Wenn man nur sehr wenige einzelne Postfächer hat mag es noch akzeptabel sein das mit Einzelpostfächern zu verwalten, allerdings multiplizieren sich die möglichen Probleme beim POP3 Abruf dann auch mit der Zahl dieser Postfächer.

    Das Verhalten das alle bereits abgeholte Post noch einmal vom Provider abgeholt hat tritt zum einen nur dann auf wenn man die mldb datei zum Postfach löscht und lässt sich zum anderen elegant verhindern wenn man im Eingangslogbuch guckt welches die letzte ordentlich empfangene mail war und dann vor dem löschen der mldb datei alle älteren inklusive der doppelten dateien im catchall Postfach beim provider löscht.
    Im Falle von Strato kann man dazu bequem den webmail client nehmen.

    Ddie Option bereits abgeholte mails beim Provider im Postfach liegen und erst nach ein par Tagen löschen zu lassen sollte man allerdings generell vorsichtig anwenden und dort vor allem nicht mehr Tage liegen lassen als nötig sind um im Zweifel ein Problem auf seinem david server erkennen zu können.
    Je weniger Tage man die Mails beim Provider liegen lässt, je weniger liegt dort auch und je weniger Probleme hat man entsprechend damit (nicht nur im Fall dessen das man eine beschädigte mldb datei löschen muss).

    Hallo, muss mich erstmal für eine Fehlinformation entschuldigen, es handelt sich um die Version 11 und nicht, wie geschrieben, um die 12, mein Vorgänger hatte das leider verwechselt.

    Der Inhalt des Verzeichnises:

    Name Grösse Bytes


    S:\David\Apps\Dvgrab\Code\

    DVGRAB.DAT 1024

    dvgrab.exe 428032

    DVGRAB.INI 362

    dvgrab.res 4998

    dvgrab.rss 24576

    rss.htm 1139

    rssurls.dat 20480

    tld.chk 33

    twitter.htm 2853

    Hallo,

    selbes Verhalten hier.

    Tobit David 11 auf Server 2008 und Postfächer bei Strato.

    Wir haben einzelne Postfächer, das Problem tritt bei allen auf. Ich denke also nicht, dass es an der mldb liegt.


    Das Problem ist meiner Meinung nach der TLS/1.0 Handshake, zumindest sieht das im Wireshark so aus.

    "TLS 1.0, Alert Level: Fatal, Handshake Failure".


    Habt ihr dafür eine Lösung gefunden?

    Ich kann das nur noch mal schreiben, wir holen ebenfalls Mails bei Strato ab und haben keinerlei Probleme damit. Es gibt folglich kein generelles Problem mit der Kombination Strato + Tobit David

    Im Ursprungspost fällt mir allerdings auf das dort im Log einige entscheidende Zeilen nicht auftauchen.

    So sollte das eigentlich aussehen:

    Auf die Schnelle fehlt mir also der komplette SSL Handshake.
    Kann es sein das Ihr den falschen Port für den POP3 Abruf im POP3 Postfach eingetragen habt?

    Da muss Port 995 eingetragen sein.
    Dann sollte auch der SSL Handshake stattfinden

    @riwawie:

    Welches Betriebssystem nutzt du, und welche David Version?

    Da dürfte der Unterschied liegen warum es bei dir funktioniert und bei anderen nicht.


    Server 2008, wie bei uns, unterstützt standardmässig kein TLS/1.0. Da warte auch auf die Freigabe des Wartungsfensters.

    Daher vermutlich auch kein SSL-Handshake.

    Andreas c

    evtl. hilft dieser Artikel https://support.microsoft.com/…lt-secure-protocols-in-wi , falls das Problem mit TLS 1 zu tun hat.

    Bin bei meinen Postfächern noch keinen Schritt weiter gekommen. Es könnte sein, dass Strato im Moment auf manchen Servern tatsächlich Probleme hat.

    Ich betreue viele Strato Web-Accounts, zwei davon sind z. B. im Moment von einigen nicht geblockten IPs nur dann erreichbar, wenn die .htaccess (die diverse IP-bereiche aus China Rumänien etc abblockt, von denen in der Vergangenheit Angriffe ausgingen} komplett abgeschaltet ist.

    Ich warte nun erstmal bis Sonntagabend ab, bevor ich noch weitere Nächte im Trüben rumstochere, ob sich von dieser Seite was tut. Unsere Mails werden im Moment vom Sekretariat über das Webmailinterface angenommen und händisch auf die Ordner der Clients verteilt
    - ist zwar nicht Sinn der Sache aber ein Großteil der Belegschaft möchte keine anderen Clients.

    Aktuell Windows Server 2016, aber das lief vorher auch bereits auf Windows Server 2008 R2 mit SSL über POP3 Abruf auf Port 995 bei Strato.

    edit:
    Der David ist derzeit ein R 12.00a - 3112 aber auch der hat halt schon einige Inkarnationen gesehen seit wir SSL / TLS für POP3 und SMTP bei Strato aktiviert haben.
    edit:


    Wir haben SSL da ja schon eine ganze Weile aktiv.

    Eigentlich ist SSL / TLS allerdings Aufgabe vom Tobit David und nicht vom Windows Server.
    Wir reden schließlich davon das der Grabbing Server als Client einen POP3 Abruf bei Strato macht und nicht etwa der Windows Server 2008 selbst da irgendwas tun würde.

    PS: Strato verlangt TLSv1.3 nicht 1.0 ;-)

    eddy V. Deine beiden Links werden ihm nicht wirklich weiter helfen da sie genau wie die Annahme das der Windows Server 2008 das Problem sei in die Irre leiten.
    In Deinem ersten Link geht es darum das die Windows Update Komponente des Windows Server 2008 als Client der Microsoft Update Server TLS 1.1 und TLS 1.2 lernt.
    In Deinem zweiten Link geht es darum das der IIS auf dem Windows Server 2008 R2 standardmäßig TLS 1.1 und TLS 1.2 nicht aktiviert hat.

    Ein David Server ist allerdings weder von dem einen noch dem anderen abhängig, weder läuft die Webbox über den IIS noch nutzt der David Server SSL bzw. TLS ibliotheken vom Windows Server.

    Zu Deiner Vermutung:

    Quote from eddy V.

    Bin bei meinen Postfächern noch keinen Schritt weiter gekommen. Es könnte sein, dass Strato im Moment auf manchen Servern tatsächlich Probleme hat.

    habe ich extra darauf geachtet das die Strato POP3 Server IP identisch zu jener ist mit welcher der Server aus dem Protokoll im Eingangspost ist.

    Das Problem von tom scheint mir wirklich eher zu sein das er entweder den POP3 Abruf kürzlich von Port 995 wieder auf Port 110 zurückgestellt hat, oder das noch gar nicht auf Port 995 umgestellt war und Strato dies aus irgendeinem Grund bis vor kurzem noch akzeptiert hat, was sie nun nicht mehr tun.

    Der Punkt ist das Strato seit geraumer Zeit den Kontakt zu seinen Mailservern (SMTP / POP3 /IMAP) via SSL / TLS verlangt.
    Die Verbindung zum Strato POP3 Server endet aber jedesmal mit einem Quit bevor das SSL Handshake auch nur beginnen müsste.

    Das passt auch nicht zur Theorie das der David oder der Windows Server 2008 auf dem der David läuft die TLS Version nicht unterstützen könnte, denn dann müsste man zumindest mal den Beginn eines Handshake sehen.

    Wesentlich wahrscheinlicher ist das tom zwar wie eingangs geschrieben

    POP3PORT = 995

    in seine dvgrab.ini eingetragen hat, jedoch bei den einzelnen POP3 Accounts unter

    David > eMail > Grabbing Server - POP3 Dienst > POP3 Postfächer

    Im Feld Account > Port

    nicht 995 eingetragen hat.
    Der Grabbing Server nutzt aber den Port welcher im einzelnen Account steht.
    Der Eintrag in der dvgrad.ini gibt nur vor was beim neuanlegen eines POP3 Postfachs als Standard Port in das Feld Account > Port vorausgefüllt wird ;-)

    Ich kann dabei übrigens nur Vermutungen zum Fall von tom anbieten, denn er hat ein LOG beigefügt.

    Was bei Euch eddy V. schief läuft kann hier nicht mal Teil von Spekulationen sein, weil Du bislang in diesem Thread hier gar keine Log Auszüge gebracht hast :o

    riawie
    vielen Dank für die schnelle Reaktion und die Infos,
    in den Accounts ist natürlich der Port 995 eingetragen, hat ja auch bis letzte Woche gut damit funktioniert. Wenn ich das beigefügte log mit dem von tom vergleiche, kommt unsere Anfrage nichtmal bis zum Userarchiv durch, evtl gibt es dabei auch noch zusätzlich ein Verteilerproblem.
    Die Postfächer wurden mehrfach geleert, bzw neu angelegt, Server und Dienste neu gestartet...- vielleicht kann jemand aus dem log etwas rauslesen!
    david-forum.de/attachment/865/

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login