SMTP Server krijgt de ene keer EHLO dan Wel HELO

[Dysan]

Raar probleem, sinds enkele dagen komt mail afgeleverd door de hosting provider op SMTP niet, te laat of driedubbel binnen.
De hosting provider heeft de MX records en stuurt deze door naar onze exchange server.
Na veel gezoek ben ik erachte gekomen dat deze server de ene keer HELO zegt en de andere keer EHLO.
Indien deze HELO gebeurt er het volgende:

code:

220 ****.*******.nl Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at  Thu, 24 Jul 2008 15:10:38 +0200 
HELO ****.*******.nl
250 ****.*******.nl Hello [IP mailserver provider]
MAIL FROM:<>
250 2.1.0 <>....Sender OK
RCPT TO:<[e-mail]>
250 2.1.5 [e-mail]
QUIT

en lijkt de mail niet aan te komen, de MAIL FROM : <> is ook daardwerkelijk leeg.

indien er EHLO gezegd wordt gebeurt er dit:

code:

220 ***.***.nl Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at  Thu, 24 Jul 2008 15:00:31 +0200 
EHLO ***.***..nl
250-***.***..nl Hello [IP mailserver provider]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-X-EXPS GSSAPI NTLM LOGIN
250-X-EXPS=LOGIN
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250-X-LINK2STATE
250-XEXCH50
250 OK
MAIL From:<[e-mail]> SIZE=941
250 2.1.0 [e-mail]....Sender OK
RCPT To:<[e-mail]>
DATA
250 2.1.5 [e-mail] 
354 Start mail input; end with <CRLF>.<CRLF>
   *daadwerkelijke e-mail data
QUIT

Provider zegt dat het niet aan hun ligt maar aan onze brakke mail server. Echter is dit probleem van de een op de andere dag onstaan en is de server schoon van foute meldingen in de eventlogs.

[Mishmash]

Ik neem aan dat het een windows bak is. Welk OS? Wat staat er in je MX Records?

[Dysan]

Het is een Windows 2003 Small business server (Windows & Exchange SP2)
Beide MX records van het domein naam verwijzen naar de provider, deze relayd het weer door naar de exchange server

[Foamy]

Hm, als de MX records inderdaad allemaal naar je eigen server (of de mailrelay) wijzen dan word het wat lastiger om het balletje bij hun neer te leggen. Dit omdat eigenlijk het enige wat zij doen is het doorverwijzen naar.. jouw server..

Zit er iets van consequentie in de mails die wel/niet binnen komen? Dus komt dit steevast voor bij mensen die gebruik maken van dezelfde mailserver? Als dat het geval is zou je eens kunnen kijken of het niet stiekem door de verzendende mailserver word veroorzaakt.
Zijn er ook geen updates geweest voor dit probleem is ontstaan? Speelt dit niet al langer zonder dat je het zelf door hebt gehad?

[xtra]

Een "MAIL FROM:<>" is meestal een non delivery report oid waarvan het niet de bedoeling is dat een reply komt. Het kan zijn dat die een ouderwetse HELO gebruikt om het zo eenvoudig mogelijk te houden.

Zie je niets in je logbestanden. Als het bij jou aankomt zou je denken dat de MX-instellingen etc. goed zijn. Dan zou het dus ergens anders in een zwart gat moeten verdwijnen.

/edit: Zie nu dat de HELO geen DATA heeft. Dat zou je nog wel eens bij je provider kunnen vragen.

[ Voor 11% gewijzigd door xtra op 24-07-2008 20:30 ]

[Brahiewahiewa]

Dysan schreef op donderdag 24 juli 2008 @ 16:03:
...

code:

220 ****.*******.nl Microsoft ESMTP MAIL Service, Version: 6.0.3790.3959 ready at  Thu, 24 Jul 2008 15:10:38 +0200 
HELO ****.*******.nl
250 ****.*******.nl Hello [IP mailserver provider]
MAIL FROM:<>
250 2.1.0 <>....Sender OK
RCPT TO:<[e-mail]>
250 2.1.5 [e-mail]
QUIT

Het zou praktischer zijn als je ook de time stamps van de commando's had gelogd.
Zo ziet het er uit alsof de verzendende server meteen QUIT zegt, als jouw server z'n 2.1.5 antwoord geeft. Maar het zou ook heel goed kunnen zijn dat de verzendende server op de 354 message zit te wachten. En als die na x minuten niet gekomen is, de verbinding maar verbreekt.

Verder: hoeveel mail servers heeft je provider? (Dat ze vanaf hetzelfde IP-adres komen, hoeft niet persé te betekenen dat het dezelfde server is; het kunnen er meerdere zijn achter NAT of LB).

Hoeveel mogelijke verbindingen zijn er tussen je provider en je server? Zit er in één van die verbindingen misschien een PiX of een andere ranzige firewall, die alleen het 26 jaar oude RFC821 protocol doorlaat en dus geen EHLO ondersteunt?

[Dysan]

even voor de duidelijkheid de MX records verwijzen niet naar mijn server maar naar de servers van een hosting provider.
De verbinding naar mij toe op het internet verloopt via een Zyxel router die op poort 25 de 2 opgegeven smtp server2 van de provider door laat.
Time stamps zal ik nog naar gaan kijken.

[MikeN]

De eerste sessie lijkt mij een callout die gebeurd om het afzenderadres of het destination adres te controleren. Kan best zijn dat je provider dit doet voordat ze mail doorsturen, om zo geen mail te accepteren voor niet bestaande adressen. Dit hoeft in principe geen probleem te zijn. Exim doet dit bijvoorbeeld in veel standaardconfigs.

Ik denk dat je het probleem dus nog even verder moet zoeken.

[Brahiewahiewa]

MikeN schreef op vrijdag 25 juli 2008 @ 09:15:
De eerste sessie lijkt mij een callout die gebeurd om het afzenderadres of het destination adres te controleren. Kan best zijn dat je provider dit doet voordat ze mail doorsturen, om zo geen mail te accepteren voor niet bestaande adressen. Dit hoeft in principe geen probleem te zijn. Exim doet dit bijvoorbeeld in veel standaardconfigs.

Ik denk dat je het probleem dus nog even verder moet zoeken.

Hmmz, standaard accepteert Exchange alle local parts (om daarna op z'n gemak uit te zoeken of er een mailbox voor bestaat) dus zou jouw server meteen in de callout cache van Exim terecht moeten komen.

Anyway is het natuurlijk eenvoudig te testen; via de (beide) mailserver(s) van je provider een testmailtje sturen naar een adres op je eigen domain en dan kijken of je zo'n HELO sessie terugziet in je logs. Die zou dan later gevolgd moeten worden door een EHLO sessie waarin het mailtje daadwerkelijk wordt bezorgd. En - ook via de mailserver van je provider - een test mailtje sturen naar een extern adres, met als afzender een adres op jouw domain. Dan zou je ook zo'n HELO sessie moeten zien.

offtopic:
Een provider die niet mee wil denken en zondermeer je server als brak bestempelt, zou bij mij wel hoog op het todo-lijstje voor vervanging komen te staan

[Dysan]

Vreemd, ondanks dat de hosting provider niets verander heeft lijkt het weer te werken........
mag dus dicht van mij