felix1520
Goto Top

Network conmunication error mit Trendmicro IMSS 7.0 Windows

Hallo,

Ich habe ein Problem beim Versenden von Mails mit .ZIP Anhängen an verschiedene Empfänger, z.B. an die Domain "gmx.at"
KORREKTUR: Es handelt sich um PDF Dateien, nicht um Zip Dateien!
Verwendet wird ein Exchange 2003 und ein Trendmicro IMSS 7.0 Build 6298.

Die Fehlermeldung, die ich zurückbekomme, lautet:

Can not deliver the message you sent. Will not retry.

Sender: <*@*.>

The following addresses had delivery problems
<
*@*.> Network conmunication error.

Man beachte bitte die komische schreibweise des Wortes "conmunication"

Dieses Mail geht in dem Fall an einige bestimmte Absender nicht durch, deren Mailserver aber per Telnet am Port 25 erreichbar sind.
An Gmail ging das Mail sofort durch...

Laut den "Action details" im Log File bricht er nach dem 10. Zustellversuch mit folgendem Fehler ab:
could not be relayed and was deleted, with failure notification email sent.

Nachdem ich alle Updates und Patches installiert habe, die Logfiles gecheckt und in diverse Foren gepostet habe ohne das Problem zu lösen, wende ich mich nun an euch.

grüsse
felix

Content-Key: 108743

Url: https://administrator.de/contentid/108743

Ausgedruckt am: 29.03.2024 um 01:03 Uhr

Mitglied: toheil
toheil 22.03.2009 um 21:01:25 Uhr
Goto Top
hallo Felix, wir haben das gleiche problem, leider ...
hast du inzwischen eine lösung gefunden ?

das völlig bescheuerte ist, das das ganze nur bei einer einzigen domäne auftritt, an die wir senden.
komisch gell ?
manchmal klappt es auch beim 3. 4. oder 5. sendeversuch ....

na ja, meld dich mal ...
Mitglied: mistermarple
mistermarple 20.04.2009 um 16:03:49 Uhr
Goto Top
hallo felix,

ändere in der tsmtpd.ini Datei den Parameter „IdleWaitingSeconds“.

  1. 9.2
  2. SMTP client session timeout (seconds).
  3. If server does not respond for timeout period, then close session.
  4. Recommended maximum = 60 (to avoid wasting time on dead mails)
#
#IdleWaitingSecond=30 (alter Wert)


IdleWaitingSecond=180 (neuer wert ohne #)

trendmicrodienste neu starten

mfg rainer
Mitglied: felix1520
felix1520 30.04.2009 um 18:47:33 Uhr
Goto Top
Hallo!

Korrektur:
Es handelt sich nicht um Mails mit .zip-Anhängen sonder mit .pdf-Anhängen.

@toheil
Bei uns tritt es auch nur bei manchen Domänen auf, eine davon ist "gmx.at"

@mistermarple
Danke für den Tip, leider hat es nichts gebracht, hast du noch einen Vorschlag?

lg
felix
Mitglied: mistermarple
mistermarple 03.05.2009 um 17:17:13 Uhr
Goto Top
Hallo felix,

wenn die Änderung des parameters IdleWaitingSeconds=180 nichts bringt,
kannst versuchen den wert weiter zu erhöhen (300)

damit soll erreicht werden, dass die SMTP Verbindungen bei bestimmten providern
nicht zu früh wieder terminiert werden
.
tsmtpd.ini
dienst beenden
eintrag ändern
IdleWaitingSecond=300
dienst starten

in der zeile
IdleWaitingSecond=300
Route # entfernen

gibt es zu den providern ohne dateianhänge probleme?
Mitglied: felix1520
felix1520 04.05.2009 um 15:47:30 Uhr
Goto Top
Hallo!

Ich habe den Wert "IdleWaitingSecond" jetzt auf 300 gesetzt und werde das Problem weiter beobachten.

Ohne PDF Anhang gehen die Mails zu diesen Empfängerdomains ohne Probleme durch.

MfG
Mitglied: Haui77
Haui77 26.08.2009 um 17:29:59 Uhr
Goto Top
Tag auch,

wir haben auch o.g. Problem, allerdings auch ohne Anhänge und betrifft auch nur ein paar Empfänger Domains.

Habe oben genannten Lösungsvorschlag auch ausprobiert, leider ohne Erfolg.

Gibt es da mittlerweile neue Erkenntnisse?

mfg
Mitglied: mistermarple
mistermarple 27.08.2009 um 10:29:57 Uhr
Goto Top
für anti spam habe ich no spam proxy im einsatz (Trendmicro war hier nicht überzeugend)
mit der version 7.0 von no spam proxy ist die funtionalität von no spam proxy erweitert worden
mit dem ergebnis, dass ich trendmicro interscan messaging security suite
generell abgeschalten habe, also auch nicht mehr als smtp mail gateway nutze
Mitglied: felix1520
felix1520 07.01.2010 um 16:57:11 Uhr
Goto Top
Hallo!
Vor fast einem Jahr habe ich diesen Thread gestartet.

der aktuelle Status:
  • Hotfix 63240 wurde eingspielt.
Dadurch ist der Rechschreibfehler im NDR weg - steht auch im changelog vom Hotfix:

There is a typographical error in the following NDR message for a network communication error: "Network conmunicattion error."

Kurz gesagt: Das Problem besteht noch immer aber der Rechtschreibfehler ist weg!!!

Kann mir jemand helfen?

PS: IdleWaitingSecond hat den Wert 300

lg
felix