[SMTP] Deferred: Connection reset

[codemann]

Een klant van ons rapporteerde dat er mails van een bepaald bedrijf niet tot bij hun geraakten. Na wat meer concrete info te vragen en wat dingen na te kijken bleek dat er een 4.x.x error gebeurde, dat de mails opnieuw verstuurd werden om het half uur, maar dat het uiteindelijk helemaal failde en dat de verzender uiteindelijk de volgende melding kreeg :

code:

Het bericht kan niet worden bezorgd binnen de opgegeven tijdslimiet. Probeer het opnieuw of neem contact op met de systeembeheerder.
< **MAILSERVER1** #4.4.7 SMTP; 451 4.4.1 reply: read error from **MAILSERVER2**.>

Ik ben dan verder in de log files van onze mail server gaan kijken waar ik het volgende vond :

code:

**IP_MAILSERVER1** [0618] 00:19:17 Connected
**IP_MAILSERVER1** [0618] 00:19:17 >>> 220 **MAILSERVER2** ESMTP Merak 8.5.0-5; Tue, 19 Sep 2006 00:19:17 +0200
**IP_MAILSERVER1** [0618] 00:19:17 <<< EHLO **MAILSERVER1**
**IP_MAILSERVER1** [0618] 00:19:17 >>> 250-**MAILSERVER2** Hello **MAILSERVER1** [**IP_MAILSERVER1**], pleased to meet you.
**IP_MAILSERVER1** [0618] 00:19:17 <<< MAIL From:<**MAILADDRESS1**> SIZE=27105
**IP_MAILSERVER1** [0618] 00:19:17 >>> 250 2.1.0 <**MAILADDRESS1**>... Sender ok
**IP_MAILSERVER1** [0618] 00:19:17 <<< RCPT To:<**MAILADDRESS2**>
**IP_MAILSERVER1** [0618] 00:19:17 >>> 250 2.1.5 <**MAILADDRESS2**>... Recipient ok
**IP_MAILSERVER1** [0618] 00:19:17 <<< DATA
**IP_MAILSERVER1** [0618] 00:19:17 >>> 354 Enter mail, end with "." on a line by itself
SYSTEM             [0618] 00:19:59 Disconnected

Hier zag ik dus dat er geen data connectie gemaakt werd. Met de voorlaatste regel wordt het begin van de data connectie aangekondigd, maar de effectieve data connectie vond niet plaats. Dit herkende ik van mails die door onze externe spam filter geblokt werden, dus ik ging in deze spam filter verder zoeken. Maar noch het IP van de e-mail server 1, noch de e-mail adressen kon ik er terugvinden.
Aangezien er ook geen concrete foutmelding stond (zoals quota bereikt ofzo) besloot ik de admins van de andere mail server te contacteren om te zien of zij een foutmelding kregen.

Zij bezorgden mij deze logs :

code:

Sep 14 13:14:34 **MAILSERVER1** sendmail[21036]: [ID 801593 mail.info] k8EBEYjs021036: from=<**MAILADDRESS1**>, size=26890, class=0, nrcpts=1, msgid=<1C0B7A54A5D3894ABCB3EBBFB0F6941ED4FF88@EVS1>, proto=SMTP, daemon=MTA-v4, relay=**RELAYSERVER** [**IP_RELAYSERVER**] (may be forged)
Sep 14 13:15:19 **MAILSERVER1** sendmail[21051]: [ID 801593 mail.info] k8EBEYjs021036: to=<**MAILADDRESS2**>, delay=00:00:45, xdelay=00:00:45, mailer=esmtp, pri=146890, relay=**MAILSERVER2**. [**IP_MAILSERVER2**], dsn=4.0.0, stat=Deferred
Sep 14 13:31:03 **MAILSERVER1** sendmail[3531]: [ID 801593 mail.info] k8EBEYjs021036: to=<**MAILADDRESS2**>, delay=00:16:29, xdelay=00:00:00, mailer=esmtp, pri=236890, relay=**MAILSERVER2**., dsn=4.0.0, stat=Deferred: Connection reset by **MAILSERVER2**.

Hier zag ik wel de melding "Deferred: Connection reset by **MAILSERVER2**" maar een echte duidelijke reden vond ik hier ook niet.

Ik heb zitten zoeken via Google en de search hier, maar echt verder kom ik niet. Iemand enig idee wat dit zou kunnen zijn?

Ondertussen is dit zelf opgelost geraakt, sinds vandaag komen e-mails van deze mail server perfect terug aan op onze server. Maar ik had toch graag geweten waar dat aan gelegen zou hebben.

[mookie]

rare vraag maar wie levert jouw internet verbinding?
kpn?

[codemann]

Nee, onze servers staan in België met een aansluiting via Scarlet. Waarom?

[mookie]

ik had laatst ook zoiets vaags.
Ik kon naar een bepaald bedrijf geen email meer sturen.
Als ik handmatig telnet opstartte leek het net of hij verbinding maakte.
Dat was ook zo maar na een paar karakters typen viel die weg.
Vanaf mijn thuis computer kon ik er zo op.
Met bedrijf contact gehad en die zweerde dat ik niet blacklisted was oid...
3 dagen later werkte het ook weer zonder dat iemand iets verandert heeft...

[localhost]

Jaaaren geleden zoiets gehad (nog in het 28k8 huurlijn tijdperk). Wij konden geen mails naar (bepaalde) afdelingen van de ING sturen. Ik ben er uiteindelijk nooit achter gekomen, waarschijnlijk had het iets met de Sequencing van IP packets te maken waardoor er iets helemaal fout liep. Het leek erop alsof tussen RCPT TO: en DATA het uitgaande poortnummer wijzigde (reden zoals ik zei onbekend), bij geen enkele andere verbinding hadden we hier last van.

Onze OS/2 router is destijds vervangen door Linux en alle problemen waren verdwenen.

[codemann]

Ja, daar vreesde ik al voor. Het zal een beetje een mysterie blijven, wat we maar zullen wijten aan "het internet".

[bommel]

Black hole router, MTU size aanpassen?
Zie ook How to Troubleshoot Black Hole Router Issues

[codemann]

Ik heb dit probleem weer voor... De "Black hole router" fixes aangehaald heb ik geprobeerd, dit helpt niks.

Verder heb ik nog geprobeerd een telnet connectie te maken met de bepaalde mail server en ik krijg :

452 try later

Connection to host lost.

Als ik het op een andere server binnen het werk probeer dan lukt het wel, dus het kan geen firewall probleem zijn.

Die 452 zegt me het volgende :

Requested action not taken: insufficient system storage

Wat ook nergens op slaat volgens mij want vanaf een andere machine werkt het, alleen via die niet.

Blacklisted is mijn mail server ook niet, heb ik ook getest.

Ik ga nu de admins van die mail server mailen, iemand nog andere suggesties ?

[Verwijderd]

Als een van mijn klanten bepaalde mailservers niet kan benaderen kies ik altijd voor de makkelijke weg, ik laat die klanten dan maar voortaan via de smtp server van hun isp mail versturen. (smart-host). De smtp servers van je smtp staan meestal zeker niet ergens op een blacklist, en zowieso zijn de smtp servers van je isp er vaak beter in om mail af te leveren dan je eigen servertje met beperkte internet verbinding. Echter heb jij het dit keer niet voor het zeggen omdat het netwerk waar de mail vandaan komt niet in jou beheer is. Je zou bij wijze van test eens moeten vragen of de beheerder van het andere netwerk de mail eens zou willen versturen via een smart host. Tevens moet je inderdaad ook goed na gaan of jou of zijn ip ergens blacklisted is.

[ Voor 17% gewijzigd door Verwijderd op 07-10-2006 09:23 ]

[Verwijderd]

codemann schreef op vrijdag 06 oktober 2006 @ 19:19:
Ik heb dit probleem weer voor... De "Black hole router" fixes aangehaald heb ik geprobeerd, dit helpt niks.

Verder heb ik nog geprobeerd een telnet connectie te maken met de bepaalde mail server en ik krijg :


[...]


Als ik het op een andere server binnen het werk probeer dan lukt het wel, dus het kan geen firewall probleem zijn.

Die 452 zegt me het volgende :


[...]


Wat ook nergens op slaat volgens mij want vanaf een andere machine werkt het, alleen via die niet.

Blacklisted is mijn mail server ook niet, heb ik ook getest.

Ik ga nu de admins van die mail server mailen, iemand nog andere suggesties ?

Een 452 error betekend toch dat de mailserver die de error verstuurd een probleem heeft en dat je het later nog een keer moet proberen? (alle 45x codes volgens mij).
Op een later tijdstip vanaf een andere machine binnen jullie netwerk werkt het wel. Ik neem even aan dat je via NAT het internet op gaat en niet alle machines een publiek ip adres hebben?
In dat geval zou de desbetreffende server voorzien kunnen zijn van greylisting. Hij geeft dan de 1e keer dat je connect een 45x error wat zoveel betekend als "ik heb een probleem, probeer het later nog eens". De meeste spambots proberen het niet nog een keer dus die spam is mooi gekilled. Andere mailservers die wel aan de regles van RFC nog wat voldoen zullen het binnen een bepaalde tijd nog een keer proberen. De ontvangende mailserver ziet dat hij een x tijd ervoor ook al een connectie heeft gehad van dat betreffende ip adres en denkt "zal wel een echte mailserver zijn" en laat hem door.
Als het goed is zou je dus gewoon moeten kunnen mailen maar kost het een retry ofzo. Ik kan er ook naast zitten want ik ken niet alle error codes zo uit mijn hoofd. Maar het verhaal van greylisting gebruik ik ook op diverse mailserver. En dat is wel een tip. Scheelt een hele hoop spam.