"Fehler b. Kommunikation" bei Mails über 10MB - Versand aber trotzdem?!

    Hallo,

    ich habe das Problem, dass bei EMail größe ca. 10MB die Statusmeldung "Fehler b. Kommunikation" kommt. Die Emails werden jedoch trotzdem versendet.
    Das Problem ist einfach, dass man keinen Ausdruck als Versandnachweis erstellen kann, da der Status ja nicht "OK" ist und ich somit auch gar nicht sicher sien kann, dass die Mail auch raus ist.

    Unser Provider ist Greatnet.de. Früher habe ich in den PostMan Anmeldedaten die Confixx-Zugangsdaten für den Webserver allgemein eingegeben. Laut Provider wurde das von deren Seite umgestellt, sodass es über diese Zugangsdaten nicht mehr möglich ist. Somit bleibt lediglich die Möglichkeit des Versandes über einen POP3-Account. Diesen habe ich auch angelegt und die Zugangsdaten eingegeben. Es funktioniert auch tadellos, sofern die Mails unter 10MB liegen. Bei allem was darüber ist, kommt o.g. Meldung!? Es ist auch egal welche Empfängeradresse. Ich habe auch schon verschiedene POP-Accounts getestet.

    PostMan-Methode ist SMTP (AUTH=LOGIN)

    Nachfrage beim Provider war ziemlich ergebnislos. Von deren Seite wäre alles in Ordnung und müsste laufen.

    Hat jemand auch solche Probleme oder wo kann man noch ein Hebelchen stellen, was mir den reibungslosen Versand verhindert?

    Ich habe leider keine Ahnung, woran das noch liegen könnte.

    Wer hat hier Tips für mich?


    Nachfolgend das PostMan-Protokoll:

    (1) Send Mail from xxx@xxxxxxx.de to xxx@xxxxxx.de
    (00000916) New Socket
    RESOLVE MX mail.xxxxxxxxx.de
    QUERY/QUERY/RD/No Error
    Query Entries : 1
    mail.xxxxxxxxx.de
    Answer Entries : 0
    Name Server Entries: 0
    Resource Entries : 0
    RESPONSE/QUERY/RD/RA/No Error
    Query Entries : 1
    mail.xxxxxxxxxx.de
    Answer Entries : 0
    Name Server Entries: 1
    xxxxxxxxxx.de
    Resource Entries : 0
    QUERY/QUERY/RD/No Error
    Query Entries : 1
    mail.xxxxxxxxxx.de
    Answer Entries : 0
    Name Server Entries: 0
    Resource Entries : 0
    RESPONSE/QUERY/RD/RA/No Error
    Query Entries : 1
    mail.xxxxxxxxxx.de
    Answer Entries : 1
    mail.xxxxxxxxxx.de
    IP Adr. 178.xxx.xx.xx
    Name Server Entries: 0
    Resource Entries : 0
    (1) Connecting to server 178.xxx.xx.xx on port 25
    (00001056) New Socket
    (00001056) ReUseAddr : 1
    (00001056) OutOfBandDataInline: 1
    (00001056) KeepAlive : 5 minutes
    (00001056) Socket Bound to Port 0
    (00001056) Socket Connected to 178.xxx.xx.xx
    (1) Connection established (1056)
    (1) 220 serverxxx.greatnet.de ESMTP
    (1) EHLO [192.168.100.10]
    (1) 250-serverxxx.greatnet.de
    (1) 250-PIPELINING
    (1) 250-SIZE 104857600
    (1) 250-VRFY
    (1) 250-ETRN
    (1) 250-STARTTLS
    (1) 250-AUTH PLAIN LOGIN
    (1) 250-AUTH=PLAIN LOGIN
    (1) 250-ENHANCEDSTATUSCODES
    (1) 250-8BITMIME
    (1) 250 DSN
    (1) AUTH LOGIN
    (1) 334 xxxxxxx
    (1) xxxxxxx
    (1) 334 xxxxxx
    (1) xxxxxxx=
    (1) 235 2.7.0 Authentication successful
    (1) Authentication successful
    (1) MAIL FROM:<xxx@xxxxxx.de>
    (1) 250 2.1.0 Ok
    (1) RCPT TO:<xxxx@xxxxxx.de>
    (1) 250 2.1.5 Ok
    (1) DATA
    (1) 354 Start mail input; end with <CRLF>.<CRLF>
    (1) Send Mime Message
    (1) SMTP Server: Data Ok Error!
    (1) Mail Transmission aborted

    Einmal editiert, zuletzt von kagi (16. Oktober 2014 um 09:59)

    Es kann an der Einstellung für postlagernde Sendungen liegen.
    Denn 10 MB ist genau der Default-Wert, ab dem Anhänge von David nicht mit gesendet werden.
    Statt dessen erhält der Empfänger nur einen Link zum David-Server, über den er sich den großen Datei-Anhang als Download holen kann.
    Und die eMail mit diesem Link wird korrekt verschickt. -

    Der Wert für Postlagernd lässt sich im David Administrator erhöhen.
    Dort unter System / Übertragung kann die empfohlene Dateigröße erhöht werden, zum Beispiel postlagernd senden ab 30 MB.

    Vielen Dank für den Lösungsansatz!

    Leider ist das wohl nicht das Problem. Ich habe den Wert zum Einen hochgestellt und zum Anderen das Häkchen deaktiviert. Bei beiden Versuchen das alte Ergebnis :S

    -> Fehlermeldung, aber Mail verschickt

    ...es lief ja auch alles einwandfrei.

    Der Provider hat diese Anmeldegeschichte wohl auf POP-Konten begränzt und seit dem besteht das Problem über Nacht....

    Wie sieht es denn aus, wenn Sie unterhalb von Postman / Datenbanken unter Sendemethode einen Eintrag für die die eMail-Adresse machen, über die gesendet wird?

    Deaktivieren Sie zum Test vorübergehend das Senden mit den Einstellungen des Grabbingservers. Und wählen Sie bitte keinen Platzhalter, sondern tragen Sie die vollständige eMail-Adresse ein. Denken Sie bitte auch daran, bei gültige Domainnamen einen passenden Eintrag zu machen. Und deaktivieren Sie eMail-Konten, die direkt beim User angelegt sind (Erweitert / dieses Konto nicht verwenden).

    Sieht nun das Protokoll genauso aus oder gibt es keine oder andere Fehlermeldungen?

    Also, ich habe nun folgendes ausprobiert:

    - Ich habe beim PostMan SMTP-Dienst das Senden über Provider rausgenommen.
    - Ich habe das POP-Konto unter dem Benutzer angelegt.
    - Andere Version habe ich unter Sende-Methode (wie von Arno beschrieben) ausprobiert
    - Ich habe den MTU-Wert am Router geprüft (steht auf 1492)
    - Ich habe in der POSTMAN.INI den Wert "WatchdogDelay" von 55 auf verschiedene Werte geändert und getestet sowie das Semikolin am Anfang entfernt, damit es überhaupt greift

    All diese Aktionen haben am Ergebnis NICHTS geändert!!!

    Das Ergebnis ist immer das Gleich:
    - Im DAVID-Status steht: "Fehler b. Kommunikation"
    - Die Email wird trotzdem versendet
    - PostMan-Protokoll immer am Ende
    (1) SMTP Server: Data Ok Error!

    (1) Mail Transmission aborted

    Ich weiß nun echt nicht mehr, wo ich noch suchen soll. Hat nicht jamand noch eine Idee oder das gleiche Problem? Es tritt wirklich nur bei Mails größer ca. 10 MB auf.

    Hallo!

    Zitat


    Nachfrage beim Provider war ziemlich ergebnislos. Von deren Seite wäre alles in Ordnung und müsste laufen.

    Das sagen Provider nach Umstellungen immer ^^. Vorher hat es doch funktioniert, oder?

    Mach doch mal folgendes:
    1. Installiere Thunderbird/emClient oder was auch immer ein vernünftiges Sendeprotokoll hat
    2. Erstelle einen Account mit den selben Daten, wie der Postman versendet
    3. Sende die selbe Mail mit Anhang und guck was passiert.


    Danach solltest Du entscheiden, wo du weiter suchst. IMO

    Einmal editiert, zuletzt von stsm (13. Oktober 2014 um 16:46)

    Hallo,

    wir haben das gleiche Problem auch seit einiger Zeit, allerdings mit Mailkonten bei 1und1. Unangenehm wird es für den Empfänger, wenn man auch noch die automatische Wiederholung bei gescheiterten Sendeversuchen eingestellt hat. Dann kommt die Mail nämlich sogar mehrfach an.

    Leider habe ich auch noch keine wirkliche Lösung gefunden. Nach der bisherigen Recherche kommt es wohl zu einem Timeout beim Provider, wenn der Sendevorgang zu lange dauert. Da wir nur eine 1Mbit Leitung haben, ist das bei größeren Anhängen natürlich sehr problematisch.
    Wie schnell ist bei Euch die Internetanbindung?
    Würde mich auf jeden Fall auch interessieren, wie man das Problem lösen kann, ohne den postlagernden Versand zu aktivieren.

    Zitat von stsm

    Mach doch mal folgendes:
    1. Installiere Thunderbird/emClient oder was auch immer ein vernünftiges Sendeprotokoll hat
    2. Erstelle einen Account mit den selben Daten, wie der Postman versendet
    3. Sende die selbe Mail mit Anhang und guck was passiert.


    So, das habe ich nun gemacht, aber schlauer bin ich dadurch leider nicht geworden ;(
    Die Mail ging ohne Probleme durch. Einen Fehler kann ich nun nicht entdecken. Welche Rückschlüsse sollte ich nun daraus ziehen, wo ich nun weiter suchen muss? ?(

    Das ist das Protokoll von emClient:

    11:31:56.141|016| SMTP S: 220 xxx.greatnet.de ESMTP
    11:31:56.141|016| SMTP C: EHLO [192.xxx.xxx.xx]
    11:31:56.156|016| SMTP S: 250-xxx.greatnet.de
    11:31:56.156|016| SMTP S: 250-PIPELINING
    11:31:56.156|016| SMTP S: 250-SIZE 104857600
    11:31:56.156|016| SMTP S: 250-VRFY
    11:31:56.156|016| SMTP S: 250-ETRN
    11:31:56.156|016| SMTP S: 250-STARTTLS
    11:31:56.156|016| SMTP S: 250-AUTH PLAIN LOGIN
    11:31:56.156|016| SMTP S: 250-AUTH=PLAIN LOGIN
    11:31:56.156|016| SMTP S: 250-ENHANCEDSTATUSCODES
    11:31:56.156|016| SMTP S: 250-8BITMIME
    11:31:56.156|016| SMTP S: 250 DSN
    11:31:56.156|016| SMTP C: STARTTLS
    11:31:56.156|016| SMTP S: 220 2.0.0 Ready to start TLS
    11:31:56.172|016| SMTP C: EHLO [192.xxx.xxx.xx]
    11:31:56.219|016| SMTP S: 250-xxx.greatnet.de
    11:31:56.219|016| SMTP S: 250-PIPELINING
    11:31:56.219|016| SMTP S: 250-SIZE 104857600
    11:31:56.219|016| SMTP S: 250-VRFY
    11:31:56.219|016| SMTP S: 250-ETRN
    11:31:56.219|016| SMTP S: 250-AUTH PLAIN LOGIN
    11:31:56.219|016| SMTP S: 250-AUTH=PLAIN LOGIN
    11:31:56.219|016| SMTP S: 250-ENHANCEDSTATUSCODES
    11:31:56.219|016| SMTP S: 250-8BITMIME
    11:31:56.219|016| SMTP S: 250 DSN
    11:31:56.219|016| SMTP C: AUTH PLAIN
    11:31:56.234|016| SMTP S: 235 2.7.0 Authentication successful
    11:31:56.234|016| SMTP C: MAIL FROM:<xxx@xxx.de> SIZE=31744839
    11:31:56.234|016| SMTP S: 250 2.1.0 Ok
    11:31:56.234|016| SMTP C: RCPT TO:<xxx@xxx.de>
    11:31:56.250|016| SMTP S: 250 2.1.5 Ok
    11:31:56.250|016| SMTP C: DATA
    11:31:56.250|016| SMTP S: 354 End data with <CR><LF>.<CR><LF>
    11:36:47.635|016| SMTP C:
    11:36:47.635|016| SMTP C: .
    11:36:47.705|016| SMTP S: 250 2.0.0 Ok: queued as 2E9136CC16C
    11:36:47.705|016| SMTP C: QUIT
    11:36:47.713|016| SMTP S: 221 2.0.0 Bye

    Zitat von Arno

    Ändert sich die Situation, wenn das Timeout der Verbindung von 0 auf 2 Sekunden erhöht wird?
    (Postman, Registerkarte erweitert, Verbindung)

    ...das ändert leider nichts an der Situation! 8|
    Ich habe es mit 0, 2 und 30 Sekunden versucht - stets das gleiche Ergebnis!

    postman.ini
    ";" vor watchdogdelay entfernen
    dealy auf 250 setzen
    postman neu starten und nochmal testen

    hast du in irgend einer form einen scanner laufen der in die smtp kommunikation eingreift? evtl. als software auf dem david server oder router/appliance seitig vor dem david?

    So, das mit dem "WatchDogdelay" hatte ich ja schon mal ausprobiert. Nichts desto trotz jetzt nochmal getestet mit Wert 250. -> Kein Erfog!
    Problem weiterhin!

    Von irgendwelchen Scannern ist mir nichts bekannt. Der einzige Scanner ist TrendMicro Worry Free Business -> Antiviren-Software

    Aber auch das lasse ich nicht unversucht: Habe die Software vorübergehend deaktiviert und Ergebnis: -> ERFOLG!!!!

    Jetzt gings mit "versendet" durch! Gleich nochmal versucht: Funktioniert!

    TrendMicro wieder an: Geht nicht! :thumbdown:

    Somit haben wir das Problem eingegrenzt! Nun heist es dort weiter zu suchen, denn auslassen wollt ichs nicht :cursing:

    DANKE, hast mich auf den richtigen Weg gebracht!

    schau mal nach ob das teil irgendwelche einstellungen für die firewall hat die auf port 25 greifen oder evtl. doch irgendwo eine versteckte option für das scannen von email verkehr ist.

    der "DATA OK ERROR" ist eigentlich ein klassiker in david sobald die smtp kommunikation von einem anderen programm beeinflusst wird. kenne das lustiger weise nur bei david, sonst bei keinem mail server in der form.
    noch ein tip: wir setzen aktuell auf david servern idr. avira ein, das läuft problemlos in kombination ohne dass man etwas am scanner konfigurieren muss, mit trend micro hatten wir auf david maschinen schon häufiger (recht seltsame) probleme.

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!

Benutzerkonto erstellen Anmelden