[exch2k] relaying & dropped connections

[Verwijderd]

Goeiemiddag iedereen,

[samenvatting]
mail relaying vanaf interne server via exchange 2000 server naar internet veroorzaakt "the connection was dropped by the remote host" foutmeldingen. De connectie wordt zonder reden afgebroken midden in het verzenden van de mailbody.

[situatieschets]
Het boekhoudpakket (axi finance op win2k)(server A) verzend op periodieke basis mails naar externe personen. Deze mails worden via de mailserver (exch 2k op win2k) verstuurd naar internet (rechtstreeks, niet via smart host).

[probleem]
Sommige van deze verzonden emails geraken zonder problemen buiten, andere emails (naar 2 bepaalde domeinen) blijven in de exchange queue staan tot ze een time-out geven.
Emails verzonden vanaf outlook client via exchange server geraken zonder problemen buiten.
De reden waarom ze in de queue blijven staan is de melding "the connection was dropped by the remote host".

Het tcp-ip verkeer is gemonitored voor deze verbinding, en daaruit blijkt dat de connectie goed gelegd wordt, dat er begonnen wordt met de data te verzenden, en dat er midden in de message body gestopt wordt. De laatst verzonden pakketten zijn:
serverB-> extern: body
serverB-> extern: body
serverB-> extern: body
extern->serverB: ...... (6 bytes, allemaal puntjes)
serverB-> extern: body
extern->serverB: ...... (6 bytes, allemaal puntjes)
daarna stopt de verbinding.

[vragen]
- iemand enig idee waar ik verder kan zoeken om dit probleem op te lossen
- is het antwoord van de externe server (die 6 puntjes) een normaal smtp gedrag of niet?

[extra informatie]
- er hangt tussen netwerk en internet nog een firewall, maar deze is zo geconfigureerd dat smtp verkeer vrije doorgang heeft.
- spamfilter op mailserver is uitgeschakeld voor mails afkomstig van server A

Met dank,

thebuzz

[Brahiewahiewa]

Verwijderd schreef op donderdag 03 maart 2005 @ 15:04:
extern->serverB: ...... (6 bytes, allemaal puntjes)

Is dat niet één puntje, een A en vier puntjes? Gewoon een Ack pakketje dus.
Da's niet zozeer normaal voor SMTP alswel voor TCP

[Verwijderd]

neen, de data is wel degelijk 6 puntjes. zie onderstaand screenshot. Dit is het laatste (ontvangen) packet.

http://users.pandora.Be/claerhout/temp/tweakers/packets.jpg

thebuzz

[mutsje]

en wat zegt je eventviewer etc.. heb je al op www.microsoft.com/technet gezocht...etc.

[Grolsch]

lijkt verdacht veel op mijn probleem:

[rml][ exchange] probleem met smtp connector naar één server[/rml]

is nooit een oplossing voor gekomen

[Rolfie]

Je hebt er een firewall tussen zitten zeg je. Is dat toevallig een Cisco PIX? Daar zijn namelijk wel eens problemen mee.

Wat gebeurt er als je je zelf ook als email adres er tussen zet. En daarmee bedoel ik een extern mail adres.

De applicatie verzend die zijn email via smtp naar je server, of gebruikt die een MAPI client om zijn mail te verzenden?

De belangrijkste test:
Wat gebeurt er als je zelf een telnet anderemailserver.domain.nl 25 doet. Krijg je dan verbinding? en kan je dan mail verzenden met de commando's.

Hiermee test je eigenlijk of je wel goed kan connecten naar die server

[ Voor 46% gewijzigd door Rolfie op 03-03-2005 20:15 ]

[Brahiewahiewa]

Verwijderd schreef op donderdag 03 maart 2005 @ 16:10:
neen, de data is wel degelijk 6 puntjes. zie onderstaand screenshot. Dit is het laatste (ontvangen) packet.

http://users.pandora.Be/claerhout/temp/tweakers/packets.jpg

thebuzz

Kijk nou eens goed naar dat frame. Bij de Flags zie je dat, behalve het Ack bitje, ook het Rst bitje aanstaat. De remote server (mxrelay.irc.be) doet moedwillig een reset van de tcp sessie.
Waarom-ie dat doet moet je navragen bij de beheerder van die server.

edit:

Je kunt eens gaan uitzoeken of dat frame in kwestie wel een antwoord is op het voorgaande frame.
Dat moet je kunnen aflezen aan de Ack waarde in de TCP header. Die waarde is dezelfde als het sequence number van het frame waar dit frame een antwoord op is.
Er bestaat een goeie kans dat de frames 97, 98, 99, 100 en 102 nooit bij mxrelay.irc.be aankomen omdat ze te groot zijn: 1514 bytes is groter dan de MTU voor ethernet (die's 1500)

[ Voor 29% gewijzigd door Brahiewahiewa op 03-03-2005 21:30 ]

[Kabouterplop01]

srry ik zat niet goed te lezen, ik heb alles weer weggehaald


"TCP includes a special connection reset feature to allow devices to deal with problem situations, such as half-open connections or the receipt of unexpected message types. To use the feature, the device detecting the problem sends a TCP segment with the RST (reset) flag set to 1. The receiving device either returns to the LISTEN state, if it was in the process of connection establishment, or closes the connection and returns to the CLOSED state pending a new session negotiation"

[ Voor 170% gewijzigd door Kabouterplop01 op 03-03-2005 22:05 ]

[Verwijderd]

@mutsje:
de smtp log file zegt niet al te veel, daarom dat ik hem ook niet vermeld heb:
2005-03-03 12:18:08 194.119.253.46 OutboundConnectionResponse SMTPSVC1 serverB - 25 - 0 0 24 0 250 SMTP - - - -
2005-03-03 12:18:08 194.119.253.46 OutboundConnectionCommand SMTPSVC1 serverB - 25 HELO 0 0 4 0 250 SMTP - - - -
2005-03-03 12:18:08 194.119.253.46 OutboundConnectionResponse SMTPSVC1 serverB - 25 - 0 0 18 0 672 SMTP - - - -
2005-03-03 12:18:08 194.119.253.46 OutboundConnectionCommand SMTPSVC1 serverB - 25 MAIL 0 0 4 0 672 SMTP - - - -
2005-03-03 12:18:08 194.119.253.46 OutboundConnectionResponse SMTPSVC1 serverB - 25 - 0 0 6 0 875 SMTP - - - -
2005-03-03 12:18:08 194.119.253.46 OutboundConnectionCommand SMTPSVC1 serverB - 25 RCPT 0 0 4 0 875 SMTP - - - -
2005-03-03 12:18:08 194.119.253.46 OutboundConnectionResponse SMTPSVC1 serverB - 25 - 0 0 6 0 938 SMTP - - - -
2005-03-03 12:18:08 194.119.253.46 OutboundConnectionCommand SMTPSVC1 serverB - 25 DATA 0 0 4 0 938 SMTP - - - -
2005-03-03 12:18:08 194.119.253.46 OutboundConnectionResponse SMTPSVC1 serverB - 25 - 0 0 12 0 1000 SMTP - - - -

@rolfie:
- de firewall die er tussen zit is een watchguard firebox 1000. die staat zo geconfigureerd dat er voor de server B geen filtering gebeurt.
- de mail die van server A naar server B gaat is via smtp (relaying )
- connecteren naar de doelserver vanaf server B is geen enkel probleem. Wanneer er vanaf een outlook client een mail gestuurd wordt via server B naar dat domein geraakt deze zonder probleem verzonden.

@brahiewahiewa
die rst bit had ik idd nog niet gezien. ik heb even alle syn en ack waarde's er bij genomen, en ofwel sla ik hier totaal de bal mis, ofwel is m'n redenering niet juist. Een ack waarde is een bevestiging van een syn packet. In de packets zijn er echter ack codes vooraleer de syn codes gestuurd worden.

zie bijvoorbeeld onderaan de textfiles: de ack van de packets met als size 1514 is het getal van de syn die pas later verstuurd wordt? kan toch niet?

ik heb de details van de headers (data niet, want deze is jammergenoeg vertrouwelijk) op volgende url gezet: http://users.pandora.be/claerhout/temp/tweakers/tcp.txt

bedankt,
thebuzz

[Brahiewahiewa]

Nou, 'k heb 't FF voor je uitgepuzzled. Het zit zo dat in het "Seq" veld, hetzelfde getalletje staat als in het "Ack" veld van het frame waarop je antwoordt. Dat gaat goed t/m frame 97. Frame 98, 99, 100 en 102 worden door jouw server verstuurd met opvolgende Seq nummers en hetzelfde Ack nummer, zodat mxrelay.irc.be ze allemaal tegelijk in één frame kan Ack-en. Frame 101 is het eerstvolgende antwoord van mxrelay.irc.be en da's de Reset die we op 3 maart al gezien hebben.

Voordat frame 101 binnenkwam, had jouw server echter frame 102 al verstuurd, vandaar de mxrelay.irc.be in frame 103 een retransmit doet van frame 101 (zelfde seq en ack nummers) zo van "hé, we hadden de sessie toch gereset?".

Vooralsnog hou ik het er op dat mxrelay.irc.be struikelt over de packet length van 1514. Zoals gezegd: de maximale packet grootte op ethernet is 1500. Dus ik zou eens gaan experimenteren met de MTU; zet 'm eens op 1000 en kijk of het dan wel werkt.

offtopic:

Grolsch zal het er wel niet mee eens zijn, want die zit nog steeds te prutsen met introweb

[Coen Rosdorff]

Brahiewahiewa schreef op zondag 06 maart 2005 @ 23:26:
Vooralsnog hou ik het er op dat mxrelay.irc.be struikelt over de packet length van 1514. Zoals gezegd: de maximale packet grootte op ethernet is 1500. Dus ik zou eens gaan experimenteren met de MTU; zet 'm eens op 1000 en kijk of het dan wel werkt.

In dat geval moet er ergens onderweg een router beginnen te piepen dat het packet opgesplitst moet worden. Als het goed is wordt er dan een icmp message met die mededeling naar de bron van het packet verstuurd.
Blokkeerd de TS soms al het icmp verkeer op zijn router?