"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

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

-> 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....

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,

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!
Ich habe es mit 0, 2 und 30 Sekunden versucht - stets das gleiche Ergebnis!

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!

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

DANKE, hast mich auf den richtigen Weg gebracht!