Bekijk Volledige Versie : Externe mail komt niet altijd aan
Er zijn een aantal mensen waarvan externe mail niet aankomt op de server. Deze krijgen onderstaande melding terug. In de log van de mail kan ik niks terugvinden dat er iets binnen gekomen is. Stuur ik zelf vanaf bijv. Gmail die komt wel binnen. Wie heeft suggesties voor een mogelijke oorzaak/oplossing?
The message could not be delivered after 73 attempts. At the most recent attempt the mail server at*<hostname>*[<ip>] said:
<<< 420 Socket error
Sent from my HTC One mini 2 using webhostingtalk mobile app
420 betekent:
"Timeout connection problem": there have been issues during the message transfer.
Either your email has been blocked by the recipient's firewall, or there's a hardware problem. Check with your provider.
Kan ook betekenen dat er verbindingsproblemen zijn onderweg van de verzendende server naar de ontvangende server.
Kijk even in de iptables of er soms blokkades zijn (of je firewall) voor bepaalde smtp servers.
Groet,
Tsjêbbe
CSF is actief. Daar zie ik geen denies voor NL op smtp, wel US en China. Het gaat hier om xs4all.nl
Sent from my HTC One mini 2 using webhostingtalk mobile app
Er zijn een aantal mensen waarvan externe mail niet aankomt op de server. Deze krijgen onderstaande melding terug. In de log van de mail kan ik niks terugvinden dat er iets binnen gekomen is. Stuur ik zelf vanaf bijv. Gmail die komt wel binnen. Wie heeft suggesties voor een mogelijke oorzaak/oplossing?
The message could not be delivered after 73 attempts. At the most recent attempt the mail server at*<hostname>*[<ip>] said:
<<< 420 Socket error
Sent from my HTC One mini 2 using webhostingtalk mobile app
Erbij vertellen welke mailserver software je gebruikt ?
Staat er echt niets meer in de bounce die de verzender kreeg - welk source ip was de verzende server, naar welk destination ip/host werd de verbinding gemaakt/geprobeerd te maken ?
420 is een fout die verzende server van de afzender kreeg/genereerde omdat een connectie met de ontvangende server niet, of niet voldoende tot stand kwam.
Hier moet je zoeken naar connectiviteits problemen tussen die server en de jouwe , in elk geval rond de tijdstippen dat het niet werkte.
(traceroute , ping)
En eventueel de mogelijkheid dat je maildaemon rond die tijdstippen geen connecties wilde aannemen - en op andere momenten (toen je testte) wel .
Je zoekt dus niet naar meldingen in de log van de falende mail , maar naar de afwezigheid van allerlei binnenkomende mail rond die tijden, en eventueel algemene storingen . (limieten van het een of ander vol, zodat geen nieuwe connectie geaccepteerd kon worden)
Andere slagen in de lucht (zonder betere informatie is het niet meer dan slagen in de lucht) - wel IPv6 records maar geen IPv6 connectiviteit, wel TLS onderhandelen maar geen goed certificaat leveren .
Dovecot 2.2.21
Exim 4.85
Er is wel onlangs een TXT SPF record aangepast, zodat deze naast IPv4 ook IPv6 bevat.
Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25])
by mxdrop303.xs4all.net (8.14.9/8.14.9/Debian-xs4all~5) with ESMTP id u0IMh09b027129
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK)
for <<user>@xs4all.nl>; Mon, 18 Jan 2016 23:43:39 +0100
Message-Id: <201601182243.u0IMh09b027129@mxdrop303.xs4all.net>
Date: Mon, 18 Jan 2016 23:43:39 +0100
From: "Mail Delivery System" <MAILER-DAEMON@xs4all.nl>
To: (user)@xs4all.nl
Subject: Timeout trying to deliver message
MIME-Version: 1.0
Auto-Submitted: auto-generated (failure)
Content-Type: multipart/report; boundary="------------I305M09060309060P_798514531570190"
X-CNFS-Analysis: v=2.1 cv=bpmxfxui c=1 sm=0 tr=0
a=/zf/YJhaauBg/KYV17tUBA==:117 a=_lmKfE_oAAAA:8 a=L9H7d07YOLsA:10
a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=r77TgQKjGQsHNAKrUKIA:9
a=T-LhowAUAAAA:8 a=cHSz6MgeAAAA:8 a=hlMDyfGfUd5tlD9sX2cA:9 a=QEXdDO2ut3YA:10
a=VaEvMbF3TtoA:10 a=0VVz45dhFkdi_f7fmt8A:9 a=zCanmzb8u2jp2QxBdEQA:9
a=wPNLvfGTeEIA:10 a=HwEpGGHULru4WwyLUuEA:9 a=_W_S_7VecoQA:10
a=LeomvrFribUA:10
X-Virus-Scanned: by XS4ALL Virus Scanner
X-XS4ALL-Spam-Score: -1.0 () ALL_TRUSTED
X-XS4ALL-Spam: NO
Envelope-To: (user)@xs4all.nl
This is a multi-part message in MIME format.
--------------I305M09060309060P_798514531570190
Content-Type: text/plain; charset=UTF-8;
Content-Transfer-Encoding: 8bit
Your message, received on Wednesday January 13, 2016 23:17:19 +0100 (CET) from
bl5-201-69.dsl.telepac.pt "(name)" [(ipadres)] could not be delivered to one or more recipients.
The following recipients did not received the message:
(adres)@willkellermann.com
The message could not be delivered after 73 attempts. At the most recent attempt the mail server at vps-9633-8014.cloud.tilaa.com [84.22.99.63] said:
<<< 420 Socket error
--------------I305M09060309060P_798514531570190
Content-Type: message/rfc822; Content-Transfer-Encoding: 8bit
Content-Disposition: attachment
(..)
[knip bounce mail]
(..)
Ok, dit zegt wat meer.
Het gaat in elk geval om IPv4 , en de 420 zegt dat het op een heel basaal niveau al mis gaat .
Wat ik niet direct snap is hoe de mail flow hier verlopen is .
De bovenste set headers zijn alleen de onvangst van de foutmelding van xs4all's uitgaande cluster naar de gebruiker .
Het is de mail daaronder , waar de regel staat
"Your message, received on Wednesday January 13, 2016 23:17:19 +0100 (CET) from
bl5-201-69.dsl.telepac.pt "(name)" [(ipadres)] could not be delivered to one or more recipients.
The following recipients did not received the message:"
Ik snap een afzender IP uit Portugal niet meteen bij een xs4all klant.
Het kan natuurlijk dat de xs4all gebruiker inderdaad in portugal zit , maar het is opvallend.
Wat je eigenlijk zou willen weten is welke xs4all server deze 73 pogingen gedaan heeft, en kijken of die naar poort 25 van je server op 84.22.x.y kan connecten.
Ik zou nu drie dingen proberen :
Vraag de xs4all gebruiker om via xs4all webmail een testmailtje te sturen naar het probleem domein.
(via webmail, zodat de bron van de mail puur binnen xs4all ligt, geen forward, geen client in externe ip space).
Vraag de xs4all gebruiker om jou, via hetzelfde xs4all account mail te sturen.
(naar het probleem domein zal niet werken, maar naar je eigen mailadres, of je gmail oi.d wel ). Kijk in de headers van die mail wat het IP van de laatste xs4all mail server is.
Test dan, vanaf de mailserver van het probleem domein (84.22.x.y dus) met traceroute en ping connectiviteit naar die xs4all mailserver .
Het zal vast niet dezelfde server zijn, maar je hebt wel een redelijke kans dat de uitgaande servers van xs4all een IP blok delen. Routing problemen betreffen vrijwel altijd hele ip prefixen, en zelden een enkel individueel adres.
Werkt de connectiviteit wel, dan weet je niet zo veel, maar werkt het _niet_ heb je een goed handvat om verder te onderzoeken .
En drie : adviseer de xs4all gebruiker het probleem (met bounce mail bijgesloten) bij xs4all neer te leggen.
Dat is _niet_ afschuiven - als bron van de mail is xs4all beter in staat om in de logs van hun mailfarm te kijken welke uitgaande servers op welk moment geen verbinding konden maken met jouw server. Als je op jouw server echt niks mis ziet,geen fw drops, geen gestopte processen heb je weinig mogelijkheden om te onderzoeken waarom een server "ergens bij xs4all" niet bij jou uit kon komen.
Afhankelijk van wat er waar misging kunnen ze het wellicht niet oplossen , maar voor onderzoek van het probleem zitten zij op de beste plek.
Testen met mail _naar_ xs4all zal weinig zeggen - op de schaal van xs4all is er heel veel te zeggen voor een opzet waarbij inkomende mail (de servers in een MX record) en uitgaande mail door totaal gescheiden serverfarms te laten afhandelen .
De servers waar gebruikens hun mail op aanbieden (mail smarthost 'smtp.xs4all.nl' ) is nog een derde set/server die helemaal gescheiden kan zijn.
Vandaar de moeite om enkele uitgaande server te achterhalen , want die lees je itt tot een MX niet uit DNS , of uit helpdesk pagina's.
Dank je. Ik ga er mee aan de slag.
Gebruiker heeft via de webmail mails verstuurd. Deze komen niet aan, en heeft tot nu toe nog geen bounce mail teruggekregen.
Sent from my HTC One mini 2 using webhostingtalk mobile app
Gebruiker heeft via de webmail mails verstuurd. Deze komen niet aan, en heeft tot nu toe nog geen bounce mail teruggekregen.
Sent from my HTC One mini 2 using webhostingtalk mobile app
Dat kan wel even duren - Als mailserver beheerder wil je de gebruiker niet overladen met "moeilijke technische mails" voordat het heel duidelijk is dat het niks gaat worden .
Een standaard instelling was om na 4 uur te melden dat het nog niet gelukt is, maar dat de mailserver het nog <x> dagen blijft proberen.
En bij het definitief opgeven (na 2 of 5 dagen) een definitieve bounce.
Of de xs4all gebruiker zo'n tussentijdse "ben ermee bezig" mail gekregen heeft is niet te zien, maar in de bounce zie je dat een mailpoging van oorspronkelijk 13 januari op 18 januari tot een definitieve "is niet gelukt" bounce geleid heeft.
Een bounce is dus blijkbaar vijf dagen na begin van verzend pogingen te verwachten, bij xs4all .
Overigens hoef je mijn debug opties niet in serieel uit te voeren - als de gebruiker, via webmail jou een bericht stuurt kun je ook al een trace/ping gaan doen naar de afzendende xs4all mailserver .
En als de testmail vanuit xs4all webmail na een paar uur nog niet aangekomen is, kan (gezien de voorgaande bounce) de gebruiker dat prima neerleggen bij de xs4all helpdesk .
Hier moet wel gezocht worden naar iets tussen uitgaand mailcluster en je server - ik testte even vanaf de xs4all shellserver, en je server is vanaf daar wel bereikbaar. (ping , smtp submit) .
In de mail die de gebruiker via webmail naar mij gestuurd heeft staat:
Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net. [194.109.24.31])
Deze geeft vanaf de server response op ping en traceroute.
In de mail die de gebruiker via webmail naar mij gestuurd heeft staat:
Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net. [194.109.24.31])
Deze geeft vanaf de server response op ping en traceroute.
En dat was inderdaad de laatste xs4all server in de set headers voordat de mail werd aangepakt door jouw server (of gmail, of waar het naar toe ging ?)
Dan moet je nog één keertje heel erg goed in je firewall config/logs kijken of daar iets staat voor 194.109.24 (of evt 194.109.*) - het is waarschijnlijk geen routing probleem of totaal gebrek aan connectiviteit .
En de xs4all gebruiker moet het geheel aan de helpdesk melden - zowel de eerdere bounce, als (m.n.) de webmail test die op dit moment nog in de retry queue zal staan .
Even goed melden, met de bounce erbij, tijd van webmail test (zie Sent folder) , xs4all gebruikersnaam, melding dat de beheerder van <probleemdomein> gekeken heeft en geen geweigerde connecties heeft kunnen vinden etc.
grep 194.109 /var/log/exim/mainlog
2016-01-29 10:36:00 TLS error on connection from lb3-smtp-cloud2.xs4all.net [194.109.24.29] (SSL_accept): error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
2016-01-29 10:36:00 TLS error on connection from lb3-smtp-cloud2.xs4all.net [194.109.24.29] (SSL_accept): error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
2016-01-29 10:36:00 TLS error on connection from lb3-smtp-cloud2.xs4all.net [194.109.24.29] (SSL_accept): error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
2016-01-29 10:36:00 TLS error on connection from lb3-smtp-cloud2.xs4all.net [194.109.24.29] (SSL_accept): error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
2016-01-29 10:36:00 TLS error on connection from lb3-smtp-cloud2.xs4all.net [194.109.24.29] (SSL_accept): error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
In /etc/exim.conf stond bij tls_require_ciphers weer -SSLv3 (blijkbaar na update van Exim er weer in gekomen)
Deze aangepast, en gebruiker nogmaals gevraagd om te testen.
Tevens alle andere conf files nagelopen zoals aangegeven in http://help.directadmin.com/item.php?id=571
Goed nieuws. Na deze aanpassing in exim.conf komt de mail wel weer aan.
Reactie van XS4ALL:
---
Overigens, de reden dat de mail server van willkellermann.com geen berichten van XS4ALL kan ontvangen is omdat die mail server wel TLS-encrypted verbindingen accepteert, maar alleen TLS versie 1.2, en niet TLS versie 1.1 of versie 1.0. Onze mail servers moeten nog een upgrade krijgen, en gebruiken op dit moment TLS versie 1.0 om encrypted verbindingen te maken.
---
/etc/exim.conf heeft nu:
openssl_options = +no_sslv2 +no_sslv3
tls_require_ciphers = ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:-LOW:-SSLv2:-EXP
Ongeveer 2 weken geleden is er een patch van exim ingespeeld. Deze heeft blijkbaar de configuratie overschreven.
grep 194.109 /var/log/exim/mainlog
[..]
2016-01-29 10:36:00 TLS error on connection from lb3-smtp-cloud2.xs4all.net [194.109.24.29] (SSL_accept): error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher
In /etc/exim.conf stond bij tls_require_ciphers weer -SSLv3 (blijkbaar na update van Exim er weer in gekomen)
Deze aangepast, en gebruiker nogmaals gevraagd om te testen.
Tevens alle andere conf files nagelopen zoals aangegeven in http://help.directadmin.com/item.php?id=571
Mooi dat het gevonden is - en dat is één logfile/logregel die je niet meer over het hoofd zult zien als je mailproblemen aan het troubleshooten bent.....