[Exim/SMTP] Timeout omdat exchange geen greeting stuurt

[B-Man]

Ik zit met het volgende: volgens de SMTP rfcs moet een mailserver volgens mij eerst een code 220 sturen, alvorens de verzendende partij een HELO/EHLO mag sturen.

Nu draai ik een exim mailserver, die het protocol netjes respecteert. Hij krijgt echter geen mail bezorgd bij een Exchange server, die zich daar niet aan houdt. Exchange stuurt namelijk pas de 220 (en de 250 als reactie op de EHLO) nadat ik een EHLO stuur.

Kortom: met de hand kan ik hier omheen werken, maar het is nogal vreemd vind ik. De beheerder van de Exchange machine geeft aan dat het een standaardinstallatie is, en dat ze hier nooit problemen mee hebben. De mailserver die ik draai verwerkt ook een behoorlijk volume, en geeft ook nooit problemen.
De eerste hit op de MS knowledgebase geeft aan dat de Exchange smtp server standaard ook eerst een 220 greeting stuurt, al vind ik in nieuwsgroepen her en der ook berichten dat Exchange 2003 standaard pas de greeting stuurt na een CR.

Ik ben aan het zoeken in de docs van exim of ik hier omheen kan werken. Kan iemand bevestigen of dit iets is wat in te stellen is in Exchange, en mogelijk hoe ik er in Exim omheen kan werken?

[CyBeR]

Daar valt niet omheen te werken in exim zonder de code te haxx0ren. Die exchange server houdt zich niet aan 't protocol in dit geval, en ik kan me niet voorstellen dat die doos veel mail verwerkt want als 't goed is struikelt elke compliant MTA hierover.

Welke server is 't? Zit 'ie mischien achter een firewall? Cisco PIXen met MailGuard zijn notoir goed in 't verneuken van je e-mailcommunicatie.

[ Voor 18% gewijzigd door CyBeR op 04-06-2007 18:34 ]

[B-Man]

CyBeR schreef op maandag 04 juni 2007 @ 18:34:
Daar valt niet omheen te werken in exim zonder de code te haxx0ren. Die exchange server houdt zich niet aan 't protocol in dit geval, en ik kan me niet voorstellen dat die doos veel mail verwerkt want als 't goed is struikelt elke compliant MTA hierover.

Welke server is 't? Zit 'ie mischien achter een firewall? Cisco PIXen met MailGuard zijn notoir goed in 't verneuken van je e-mailcommunicatie.

Ok, dat dacht ik dus ook. De beheerder geeft zoals ik al schreef echter aan dat het een standaard install is, en dat ze verder geen enkel probleem hebben.

Ik las op internet inderdaad ook over dit soort gezever als de SMTP server achter een PIX zit, maar of dat hier zo is weet ik niet. Vraag ik morgen even na.

Server is een exchange doos, exacte versie weet ik niet, kan ik morgen vragen. Versienummer in greeting is 6.0.3790.1830;

Ik heb inmiddels ontdekt dat exim dit inderdaad niet kan, aangezien de instellingen m.b.t. uitgaande SMTP verbindingen erg beperkt zijn. De beheerder van de Exchange doos gaf aan al gezocht te hebben naar een instelling die hiermee te maken heeft, maar niets kon vinden.

-- edit:
Inmiddels ben ik erachter dat er iets aparts aan de hand is. Als ik namelijk vanaf een windows machine telnet naar de SMTP server, krijg ik direct de greeting, maar vanaf sommige linux machines niet. Of dit nu met linux (socket?) instellingen te maken heeft is niet geheel duidelijk, aangezien het gedrag ook anders is op twee identieke machines (qua software). Dat laatste zou aangeven dat het toch aan de Exchange kant zit, dat die niet consequent zijn buffer flushed of zo?

[ Voor 16% gewijzigd door B-Man op 05-06-2007 11:09 ]

[B-Man]

Ik ben even aan het packet-filteren geslagen op mijn machine, en zie nu het volgende als ik verbind en eenmaal enter geef (dat is de 'SMTP message body'):

code:

Capturing on eth0
  0.000000 ip_bron -> ip_doel TCP 59341 > smtp [SYN] Seq=0 Ack=0 Win=5840 Len=0 MSS=1460 TSV=3572314049 TSER=0 WS=7
  0.029708 ip_doel -> ip_bron TCP smtp > 59341 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1398 WS=0 TSV=0 TSER=0
  0.029831 ip_bron -> ip_doel TCP 59341 > smtp [ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=3572314079 TSER=0
  3.774024 ip_bron -> ip_doel SMTP Message Body
  3.919651 ip_doel -> ip_bron TCP [TCP Previous segment lost] smtp > 59341 [ACK] Seq=123 Ack=3 Win=65533 Len=0 TSV=480309 TSER=3572317824
  8.965360 ip_doel -> ip_bron SMTP [TCP Retransmission] Response: 220 xyz Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830 ready at  Tue, 5 Jun 2007 12:09:46 +0200
  8.965391 ip_bron -> ip_doel TCP 59341 > smtp [ACK] Seq=3 Ack=123 Win=5888 Len=0 TSV=3572323017 TSER=480359
 11.965585 ip_bron -> ip_doel SMTP Command: QUIT
 11.989521 ip_doel -> ip_bron SMTP Response: 221 xyz Service closing transmission channel
 11.989560 ip_bron -> ip_doel TCP 59341 > smtp [ACK] Seq=9 Ack=193 Win=5888 Len=0 TSV=3572326041 TSER=480389
 11.989731 ip_doel -> ip_bron TCP smtp > 59341 [FIN, ACK] Seq=193 Ack=9 Win=65527 Len=0 TSV=480389 TSER=3572326017
 11.989922 ip_bron -> ip_doel TCP 59341 > smtp [FIN, ACK] Seq=9 Ack=194 Win=5888 Len=0 TSV=3572326042 TSER=480389
 12.013733 ip_doel -> ip_bron TCP smtp > 59341 [ACK] Seq=194 Ack=10 Win=65527 Len=0 TSV=480390 TSER=3572326042

Kortom: er komt een pakketje niet aan (getuige de TCP retransmission & lost segment). De vraag is nu echter, wat doe ik eraan?

-- edit:
Voorlopig is het probleem opgelost. Ik vond een thread op een ander forum, waar iemand aangaf een vergelijkbaar probleem opgelost te hebben door tcp_window_scaling uit te zetten.
Dat lost hier het probleem ook op.

[ Voor 8% gewijzigd door B-Man op 05-06-2007 12:55 ]

[deadinspace]

Hmm, dan kan stuk netwerkapparatuur tussen jou en de exchange server niet tegen TCP window scaling (zie bv dit artikel), wat een bug in dat apparaat is. Misschien zijn er firmware upgrades oid voor beschikbaar die dat probleem oplossen, anders kun je idd niet anders dan TCP window scaling uit te zetten.

[Verwijderd]

Versie 6.0.3790.1830 is Exchange 2003 SP2
Exchange volgt gewoon de standaard bij het opzetten van een SMTP connectie
Als je een SMTP connectie op zet, zul je van een Exchange server als response een 220 kijgen

220 servername Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830
helo testdomain.com
250 server name Hello

Geen rocket science dus, en niet afwijkend van de standaard voor SMTP connections

Mogelijk dat een firewall de response vertroebeld.

[CyBeR]

Verwijderd schreef op dinsdag 19 juni 2007 @ 13:45:
Versie 6.0.3790.1830 is Exchange 2003 SP2
Exchange volgt gewoon de standaard bij het opzetten van een SMTP connectie
Als je een SMTP connectie op zet, zul je van een Exchange server als response een 220 kijgen

220 servername Microsoft ESMTP MAIL Service, Version: 6.0.3790.1830
helo testdomain.com
250 server name Hello

Geen rocket science dus, en niet afwijkend van de standaard voor SMTP connections

Mogelijk dat een firewall de response vertroebeld.

De vraag is waarom je twee weken na dato nog met een respons komt op een probleem dat opgelost is.

[deadinspace]

Anders lees je even het hele topic

edit:
Curse you, CyBeR!

[ Voor 33% gewijzigd door deadinspace op 19-06-2007 13:55 ]