Exchange 2013 - SMTP Test per Telnet wird nicht abgesendet

[tesso 384]

Protokoll Protokollierung mal aktiviert?

Netzwerk Trace mal gemacht?

An irgendeiner stelle müssen die Pakete verschwinden.

[NorbertFe 2.281]

Ansonsten nimm halt doch mal testweise nicht Telnet sondern putty oder sowas hier: https://software.skittel.de/software/smtpdiagpro/download/

 

Bye

Norbert

[jensw_2000 10]

Juhu! Die "Bauchgefühl-Richtung" stimmt.

Mit einem weichen Zeilenumbruch (ASCII 10) wird die Nachricht versendet. Also mit <ALT+RETURN>.<ALT+RETURN> ...

Das Gleiche mit Putty. 

 

Ich habe gerade mal den Wireshark Portable mitlaufen lassen.

HEX: 0D 0A 2C 0D 0A (dez. 13 10 46 13 10 >> CR LF . CR LF) versendet die Nachricht nicht.

HEX: 0A 2C 0A (dez. 10 46 10 >> LF . LF) versendet die Nachricht.

Der Exchange erwartet also ein falsches CRLF ...

 

Offenbar bleiben die ausgehenden Mails von den Kopierern und vom Backup Monitoring genau deshalb hängen. Das trace ich morgen nochmal mit, wenn der Kunde vor Ort ist.

Jetzt bin ich aber noch ratloser. Wie kann man Das korrigieren? Nach 'sowas' googeln ist nahezu aussichtslos  :schreck:

 

Ist leider doch der falsche Ansatz.... Mit dem Zeilenumbruch hängt das Kernproblem nicht zusammen.

SMTPDiagPro von Stefan Kittel versendet die Mail auch mit ". 0D0A" also CR LF. 

 

Ich mache wohl besser einen Vorort Termin und trace den SMTP Traffic von allen Kopierern per Wireshark.

Die Backup Statusmail geht nicht raus, weil die Software fehlerhaft ist. Die sendet das SMTP Command "DDATA"  anstatt "DATA" und wartet stur auf ein OK vom Exchange. Das OK kommt natürlich nicht. Der Exchange antwortet auf den falschen Befehl jedoch richtiger Weise mit "500 5.3.3 unrecognized command" ...

bearbeitet 18. Mai 2016 von jensw_2000

[massaraksch 41]

Hi,

 

wirklich komische Sache. Kannst dir ja mal die Konfig des entsprechenden Receive Connectors anschauen:

Get-ReceiveConnector "ConnectorName" | fl

und dort z.b. nach MaxAcknowledgementDelay schauen. Dies evtl. mal abschalten:

Set-ReceiveConnector "ConnectorName" -MaxAcknowledgementDelay 0

Hier beschrieben:

https://technet.microsoft.com/en-us/library/hh529935%28v=exchg.141%29.aspx

 

Zwar für 2010, aber da es den identischen Parameter auch bei 2016 gibt, sollte das für 2013 nicht anders sein. Kann gerade nicht direkt irgendwo nachschauen.

 

Versuch ist's wert... Merk dir einfach den aktuellen Wert.

bearbeitet 18. Mai 2016 von massaraksch