Bekijk Volledige Versie : Email komt niet meer aan bij ontvanger
patrickwww
03/01/14, 22:34
Hallo,
Ik zit met een raadsel...
Tot gisteren werkte alles nog prima.
Een klant van mij heeft een inpandige exchange server draaien.
Geen problemen met email ontvangen.
Echter wanneer ik hun een mailtje probeer te sturen vanaf mijn mailserver (DirectAdmin) komt de mail bij hun niet aan.
Ik kan verder gewoon naar alles en iedereen mailen zonder problemen.
Ik krijg ook het mailtje retour met deze melding. Er staat helaas geen foutcode in:
This message was created automatically by mail delivery software.
A message that you sent has not yet been delivered to one or more of its
recipients after more than 24 hours on the queue on server01.mijndomeinnaam.nl.
The message identifier is: 1Vyoq1-00081H-OI
The subject of the message is: Serverkast
The date of the message is: Thu, 2 Jan 2014 21:25:57 +0100
The address to which the message has not yet been delivered is:
emailadres@emailadres.nl
No action is required on your part. Delivery attempts will continue for
some time, and this warning may be repeated at intervals if the message
remains undelivered. Eventually the mail delivery software will give up,
and when that happens, the message will be returned to you.
HELP?????
dennis0162
03/01/14, 22:45
Kijk even wat er in je Exim logs staat.
patrickwww
03/01/14, 22:49
Als ik verzend naar het emialadres staat er dit in de Exim mainlog:
2014-01-03 21:42:28 1VzCVg-0000Rt-2Y <= info@mijndomein.nl H=232-104-045-062.dynamic.caiway.nl (PatrickPC) [62.45.104.232] P=esmtpa A=login:info@mijndomein.nl S=64286 id=002401cf08cc$b5583080$20089180$@nl T="test" from <info@mijndomien.nl> for patrick@ontvangerdomein.nl
In de log wordt het niet gevolgd door een "completed" regel.
patrickwww
03/01/14, 22:52
Ik zie nu dat ik alle mail die ik naar hun domein toe probeer te versturen op verschillende aliassen allemaal in de "Mail queue" blijven staan.
Ook verschijnt zojuist deze regel in de mainlog
2014-01-03 21:55:15 1Vyoq1-00081H-OI mail.ontvangerdomein.nl [11.11.11.111] Connection timed out
2014-01-03 21:55:15 1Vyoq1-00081H-OI == user@ontvangerdomein.nl R=lookuphost T=remote_smtp defer (110): Connection timed out
Het lijkt erop dat ontvangende mail server niet bereikbaar is...
Is ontvanger op andere server dan je DA installatie?
Sent from my GT-N7000 using webhostingtalk mobile app
Ik zie nu dat ik alle mail die ik naar hun domein toe probeer te versturen op verschillende aliassen allemaal in de "Mail queue" blijven staan.
Ook verschijnt zojuist deze regel in de mainlog
2014-01-03 21:55:15 1Vyoq1-00081H-OI mail.ontvangerdomein.nl [11.11.11.111] Connection timed out
2014-01-03 21:55:15 1Vyoq1-00081H-OI == user@ontvangerdomein.nl R=lookuphost T=remote_smtp defer (110): Connection timed out
Wel, dan is toch duidelijk wat je verder moet onderzoeken ?
1: Is dat 11.11.11.11 IP inderdaad het IP waarop hun inpandige server bereikbaar hoort te zijn ?
2: zo ja, dan moet je uitzoeken waarom die connectie niet meer lukt.
Ik neem aan dat als je telnet 11.11.11.11 25 probeert het inderdaad ook niet lukt ?
De router/firewall op hun locatie is natuurlijk hoofdverdachte, met de server zelf als tweede.
patrickwww
03/01/14, 23:02
De ontvangende mailserver is dus wel bereikbaar want als ik een mailtje via gmail daarnaartoe stuur komt deze gewoon binnen. Net zoals alle andere honderden emails die per uur naar hun toe gestuurd worden.
De ontvanger is op een andere server een inpandige exchange server.
patrickwww
03/01/14, 23:09
Deze is bereikbaar via telnet vanaf mijn thuis computer.
Vanaf de webserver waar ik mijn domein op host en dus de mail vadnaan verzend is deze NIET bereikbaar.
Er is geen firewall aanpassing gedaan bij de ontvangende partij.
Deze is bereikbaar via telnet vanaf mijn thuis computer.
Vanaf de webserver waar ik mijn domein op host en dus de mail vadnaan verzend is deze NIET bereikbaar.
Er is geen firewall aanpassing gedaan bij de ontvangende partij.
Dan moet je zoeken aan jouw kant ...
Tenminste, als dat waar is.
"er is niks veranderd hier" is bijna minst geloofwaardige uitspraak van 'de andere kant' als je zit te troubleshooten.
Wel bereikbaar met ping ?
Hoe ver komt een traceroute ?
Kijk met tcpdump of je echt de tcp syn ziet uitgaan vanaf jouw server als je de telnet probeert .
Kijk of ping vanaf hun server naar jouw server (wel) werkt ?
Kijk hoe ver een traceroute vanaf hun server naar de jouwe komt ?
patrickwww
03/01/14, 23:28
een tracert vanaf de webserver levert het volgende op:
[root@srv01 ~]# traceroute mail.ontvangendepartij.nl
traceroute to mail.ontvangendepartij.nl (11.11.1.111), 30 hops max, 60 byte packets
1 v315.router1.dcg.transip.net (149.210.133.220) 0.665 ms 0.647 ms 0.628 ms
2 ibgp.rt2.dcg.transip.net (80.69.91.250) 0.612 ms 0.591 ms 8.139 ms
3 transip.customer.openpeering.nl (82.150.154.57) 5.531 ms 5.525 ms 5.438 ms
4 openpeering-10g.upc.nl (82.150.153.114) 1.145 ms 1.165 ms 1.150 ms
5 84.116.132.217 (84.116.132.217) 1.135 ms 1.587 ms 84.116.134.90 (84.116.134.90) 1.536 ms
6 84.116.244.42 (84.116.244.42) 1.554 ms 1.810 ms 1.669 ms
7 212.142.1.9 (212.142.1.9) 1.986 ms 2.078 ms 1.943 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
Pingen lukt ook niet.
Mijn server staat bij transip en en ontvangende server staat op een UPC zakelijk verbinding.
Pingen vanaf hun server naar mijn server toe lukt wel.
Ik kan namelijk ook email van hun ontvangen.
een tracert vanaf de webserver levert het volgende op:
[root@srv01 ~]# traceroute mail.ontvangendepartij.nl
traceroute to mail.ontvangendepartij.nl (11.11.1.111), 30 hops max, 60 byte packets
1 v315.router1.dcg.transip.net (149.210.133.220) 0.665 ms 0.647 ms 0.628 ms
2 ibgp.rt2.dcg.transip.net (80.69.91.250) 0.612 ms 0.591 ms 8.139 ms
3 transip.customer.openpeering.nl (82.150.154.57) 5.531 ms 5.525 ms 5.438 ms
4 openpeering-10g.upc.nl (82.150.153.114) 1.145 ms 1.165 ms 1.150 ms
5 84.116.132.217 (84.116.132.217) 1.135 ms 1.587 ms 84.116.134.90 (84.116.134.90) 1.536 ms
6 84.116.244.42 (84.116.244.42) 1.554 ms 1.810 ms 1.669 ms
7 212.142.1.9 (212.142.1.9) 1.986 ms 2.078 ms 1.943 ms
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
Pingen lukt ook niet.
Mijn server staat bij transip en en ontvangende server staat op een UPC zakelijk verbinding.
Hoe ver komt de traceroute als je die vanaf je huisaansluiting doet (vanaf waar mail wel werkte ) ?
En kun je vanaf daar wel pingen ?
patrickwww
03/01/14, 23:40
Hoe ver komt de traceroute als je die vanaf je huisaansluiting doet (vanaf waar mail wel werkte ) ?
En kun je vanaf daar wel pingen ?
Mail werkt dus niet meer vanaf huisaansluiting. Vanaf huis mail ik dus via mijn webserver.
Ping en tracert werkt gewoon naar hun server toe vanaf thuis.
- - - Updated - - -
Kan het zijn dat UPC het ip van Transip heeft geblokkeerd?
Mail werkt dus niet meer vanaf huisaansluiting. Vanaf huis mail ik dus via mijn webserver.
Ping en tracert werkt gewoon naar hun server toe vanaf thuis.
- - - Updated - - -
Kan het zijn dat UPC het ip van Transip heeft geblokkeerd?
Van alles kan.
Niet volledig in elk geval, als uitgaande mail naar jou wel werkt.
Overigens, weet je of die mailserver zelf mail verstuurd, en is jouw server de MX die de mail ontvangen heeft ?
Als die mailserver een smarthost gebruikt (bijvoorbeeld van upc) heb je nog niks bewezen over het pad terug.
Maar hallo, heb je nou geen benul wat ik je laat uitproberen, of doe je het vanaf hier zelf ?
Ik vraag om een traceroute vanaf de transip server naar de klantserver .
Die komt tot een bepaalde hop. Niks te zien of dat vlakbij is of ergens midden in een core .
Dan vraag ik om een traceroute vanaf je huis, omdat het vanaf daar wel zou werken.
En jij zegt alleen maar "de trace werkt" . Dat boeit maar een beetje.
Wat ik natuurlijk wil zien is hoe die trace loopt, en of die onderweg op hetzelfde pad komt als je trace vanaf transip , en dan wel verder komt , en hoe de resterende hops eruit zien.
Dan kun je met enige zekerheid zeggen dat de plek waar het stopt de plek is waar iets tegen gehouden wordt.
(het hoeft niet het ip van trans ip te zijn, als je de antwoorden vanaf daar tegenhoudt heb je hetzelfde effect ).
patrickwww
04/01/14, 00:03
Van alles kan.
Niet volledig in elk geval, als uitgaande mail naar jou wel werkt.
Overigens, weet je of die mailserver zelf mail verstuurd, en is jouw server de MX die de mail ontvangen heeft ?
Als die mailserver een smarthost gebruikt (bijvoorbeeld van upc) heb je nog niks bewezen over het pad terug.
Maar hallo, heb je nou geen benul wat ik je laat uitproberen, of doe je het vanaf hier zelf ?
Ik vraag om een traceroute vanaf de transip server naar de klantserver .
Die komt tot een bepaalde hop. Niks te zien of dat vlakbij is of ergens midden in een core .
Dan vraag ik om een traceroute vanaf je huis, omdat het vanaf daar wel zou werken.
En jij zegt alleen maar "de trace werkt" . Dat boeit maar een beetje.
Wat ik natuurlijk wil zien is hoe die trace loopt, en of die onderweg op hetzelfde pad komt als je trace vanaf transip , en dan wel verder komt , en hoe de resterende hops eruit zien.
Dan kun je met enige zekerheid zeggen dat de plek waar het stopt de plek is waar iets tegen gehouden wordt.
(het hoeft niet het ip van trans ip te zijn, als je de antwoorden vanaf daar tegenhoudt heb je hetzelfde effect ).
Uiteraard snap ik wat je bedoeld en je hulp wordt ook erg gewaardeerd.
Hierbij de afbeelding van de trace vanaf thuis.
Ik heb zojuist op de exchange server van hun de firewall even helemaal uitgezet. Ook dan is een trace vanaf mijn webserver naar hun toe niet mogelijk...
11353
patrickwww
04/01/14, 00:08
De mailserver van hun verstuurt mail via spamexperts.com. Die relayen de uitgaande mail voor hun via een FQDN connector in Exchange.
De inkomende mail wordt niet door hun gefilterd. Alleen uitgaand dus om zo de ip-reputatie van hun hoog te houden.
Naar mijn webserver wordt direct 1-op-1 op de MX verzonden.
De mailserver van hun verstuurt mail via spamexperts.com. Die relayen de uitgaande mail voor hun via een FQDN connector in Exchange.
De inkomende mail wordt niet door hun gefilterd. Alleen uitgaand dus om zo de ip-reputatie van hun hoog te houden.
Naar mijn webserver wordt direct 1-op-1 op de MX verzonden.
Wel, als ze via spamexperts verzenden heb je geen bewijs dat er een werkend tcp/25 pad is tussen hun server en de jouwe is .
Alleen voor een pad van hen naar spamexperts, en van spamexperts naar jou.
Het is er niet in in hun richting want dat is nu het probleem, en door via een derde server te sturen is er geen informatie over het pad vanaf hen naar jou.
patrickwww
04/01/14, 00:53
Ik heb het even tijdelijk opgelost door in exim.conf de routers configuration aan te passen en alle uitgaande mail te relayen via spamexperts.com
Op deze manier wordt de verzonden mail via hun ip-adres aan de ontvanger aangeboden.
Dit werkt direct en zonder problemen.
Vooralsnog ben ik er nog niet achter gekomen wat het probleem is.
patrickwww
04/01/14, 00:54
Wel, als ze via spamexperts verzenden heb je geen bewijs dat er een werkend tcp/25 pad is tussen hun server en de jouwe is .
Alleen voor een pad van hen naar spamexperts, en van spamexperts naar jou.
Het is er niet in in hun richting want dat is nu het probleem, en door via een derde server te sturen is er geen informatie over het pad vanaf hen naar jou.
Bedankt voor je bericht.
Maar dat heeft er toch niks mee te maken dat ik geen trace kan doen?
Bedankt voor je bericht.
Maar dat heeft er toch niks mee te maken dat ik geen trace kan doen?
Dat de trace niet lukt staat daar los van.
De trace is een debug methode omdat het een idee geeft waar een mislukkende tcp connectie mislukt.
Niet altijd, omdat tcp/25 tegengehouden kan worden terwijl de traceroute doorgelaten wordt bijvoorbeeld.
Vandaar dat je nu ook met tcptraceroute moet testen.
Maar in #10 (http://www.webhostingtalk.nl/usertag.php?do=list&action=hash&hash=10) schreef je :
pingen vanaf hun server naar mijn server toe lukt wel.
Ik kan namelijk ook email van hun ontvangen.
De 'namelijk' en conclusie kloppen dus niet, omdat ze mail via spamexperts sturen, en dat is wat ik in mijn posting uitlegde.
patrickwww
04/01/14, 01:09
Dat de trace niet lukt staat daar los van.
De trace is een debug methode omdat het een idee geeft waar een mislukkende tcp connectie mislukt.
Niet altijd, omdat tcp/25 tegengehouden kan worden terwijl de traceroute doorgelaten wordt bijvoorbeeld.
Vandaar dat je nu ook met tcptraceroute moet testen.
Maar in #10 (http://www.webhostingtalk.nl/usertag.php?do=list&action=hash&hash=10) schreef je :
De 'namelijk' en conclusie kloppen dus niet, omdat ze mail via spamexperts sturen, en dat is wat ik in mijn posting uitlegde.
Ok,
tcptraceroute wordt niet herkend door CentOS6
yum kan tcptraceroute ook niet vinden... Google zegt dat dit wel het geval zou moeten zijn.
Suggesties?
Ok,
tcptraceroute wordt niet herkend door CentOS6
yum kan tcptraceroute ook niet vinden... Google zegt dat dit wel het geval zou moeten zijn.
Suggesties?
Bah.
Ik had in reactie op je traceroute vanaf huis een hele post geschreven die ik nu niet terug zie.
Misschien had ik alleen de preview gezien en vergeten te versturen.
Daarin stond (min of meer)
dat traceroute waarschijnlijk ook vanaf je server werkt, omdat de hop tot waar je komt , kijkend naar je huis-trace de laatste is.
traceroute op unix gebruikt klassiek UDP naar hoge poorten, waar windows traceroute icmp gebruikt.
Als je de traceroute van je server doet met
traceroute -I <bestemming> gebruik je ook icmp, kijk eens hoe dat eruit ziet.
Firewalls blokkeren eerder de udp gebaseerde traceroute dan de icmp gebaseerde.
En kijk dan hoever je komt met
traceroute -T -p 25 <bestemming>
Dat is tcp traceroute.
Kijk (traceroute -h , man traceroute) of je die optie hebt .
Indien niet, dan zul je nog een package moeten installeren.
patrickwww
04/01/14, 01:28
[root@srv01 ~]# traceroute -I mail.ontvanger.nl
traceroute to mail.ontvanger.nl (11.11.1.111), 30 hops max, 60 byte packets
1 v315.router1.dcg.transip.net (149.210.133.220) 4.105 ms 4.090 ms 4.079 ms
2 ibgp.rt2.dcg.transip.net (80.69.91.250) 57.808 ms 57.853 ms 57.857 ms
3 transip.customer.openpeering.nl (82.150.154.57) 4.671 ms 5.037 ms 5.114 ms
4 openpeering-10g.upc.nl (82.150.153.114) 0.496 ms 0.517 ms 0.460 ms
5 84.116.132.217 (84.116.132.217) 0.895 ms 0.908 ms 0.999 ms
6 84.116.244.42 (84.116.244.42) 1.500 ms 1.484 ms 1.561 ms
7 212.142.1.9 (212.142.1.9) 1.001 ms 1.014 ms 0.998 ms
8 * * *
9 mail.ontvanger.nl (11.11.1.111) 10.663 ms 10.670 ms 10.666 ms
-----
[root@srv01 ~]# traceroute -T -p 25 mail.ontvanger.nl
traceroute to mail.ontvanger.nl (11.11.1.111), 30 hops max, 60 byte packets
1 v315.router1.dcg.transip.net (149.210.133.220) 0.270 ms 0.239 ms 0.221 ms
2 ibgp.rt2.dcg.transip.net (80.69.91.250) 0.248 ms 0.252 ms 0.232 ms
3 transip.customer.openpeering.nl (82.150.154.57) 5.998 ms 6.090 ms 6.387 ms
4 openpeering-10g.upc.nl (82.150.153.114) 0.478 ms 0.478 ms 0.469 ms
5 84.116.135.201 (84.116.135.201) 0.904 ms 84.116.132.217 (84.116.132.217) 1.088 ms 84.116.135.181 (84.116.135.181) 1.086 ms
6 84.116.244.42 (84.116.244.42) 1.368 ms 1.399 ms 1.401 ms
7 212.142.1.9 (212.142.1.9) 0.974 ms 1.067 ms 1.106 ms
8 * * *
9 mail.ontvanger.nl (11.11.1.111) 11.294 ms 14.973 ms 133.008 ms
10 mail.ontvanger.nl (11.11.1.111) 7.047 ms 10.934 ms 10.787 ms
Deze twee traces werken.
[root@srv01 ~]# traceroute -I mail.ontvanger.nl
traceroute to mail.ontvanger.nl (11.11.1.111), 30 hops max, 60 byte packets
1 v315.router1.dcg.transip.net (149.210.133.220) 4.105 ms 4.090 ms 4.079 ms
2 ibgp.rt2.dcg.transip.net (80.69.91.250) 57.808 ms 57.853 ms 57.857 ms
3 transip.customer.openpeering.nl (82.150.154.57) 4.671 ms 5.037 ms 5.114 ms
4 openpeering-10g.upc.nl (82.150.153.114) 0.496 ms 0.517 ms 0.460 ms
5 84.116.132.217 (84.116.132.217) 0.895 ms 0.908 ms 0.999 ms
6 84.116.244.42 (84.116.244.42) 1.500 ms 1.484 ms 1.561 ms
7 212.142.1.9 (212.142.1.9) 1.001 ms 1.014 ms 0.998 ms
8 * * *
9 mail.ontvanger.nl (11.11.1.111) 10.663 ms 10.670 ms 10.666 ms
-----
[root@srv01 ~]# traceroute -T -p 25 mail.ontvanger.nl
traceroute to mail.ontvanger.nl (11.11.1.111), 30 hops max, 60 byte packets
1 v315.router1.dcg.transip.net (149.210.133.220) 0.270 ms 0.239 ms 0.221 ms
2 ibgp.rt2.dcg.transip.net (80.69.91.250) 0.248 ms 0.252 ms 0.232 ms
3 transip.customer.openpeering.nl (82.150.154.57) 5.998 ms 6.090 ms 6.387 ms
4 openpeering-10g.upc.nl (82.150.153.114) 0.478 ms 0.478 ms 0.469 ms
5 84.116.135.201 (84.116.135.201) 0.904 ms 84.116.132.217 (84.116.132.217) 1.088 ms 84.116.135.181 (84.116.135.181) 1.086 ms
6 84.116.244.42 (84.116.244.42) 1.368 ms 1.399 ms 1.401 ms
7 212.142.1.9 (212.142.1.9) 0.974 ms 1.067 ms 1.106 ms
8 * * *
9 mail.ontvanger.nl (11.11.1.111) 11.294 ms 14.973 ms 133.008 ms
10 mail.ontvanger.nl (11.11.1.111) 7.047 ms 10.934 ms 10.787 ms
Deze twee traces werken.
"Dat is tcp traceroute. Kijk (traceroute -h , man traceroute) of je die optie hebt ."
Deze werken niet. Ik moet inderdaad even de package zoeken.
Je hebt tcp traceroute al (gebruikt).
traceroute -h had je (dacht ik) de korte help info gegeven, om te kijken welke argumenten er zijn.
Als je evt een andere versie had heeft die misschien ook wel de tcp optie, maar met een ander argument.
Het zal traceroute --help dan zijn bij jou; Nu ik test is het dat ook bij mij :-)
Maar dat de tweede traceroute werkt is heel positief.
Waarom de connectie dan niet werkt is raar.
probeer nog eens vanaf je server
telnet <bestemming> 25
en tik bv
HELO localhost <enter>
en kijk wat je te zien krijgt.
patrickwww
04/01/14, 01:43
Ja klopt. Ik heb de help nu voor me en ben de functies aandachtig aan het lezen.
Om het geheel nog vreemder te maken:
[root@srv01 ~]# telnet mail.ontvanger.nl 25
Trying 11.11.1.111...
500 Syntax error, command unrecognized
Connected to mail.ontvanger.nl.
Escape character is '^]'.
220 mail.ontvanger.nl Microsoft ESMTP MAIL Service ready at Sat, 4 Jan 2014 01:38:26 +0100
HELO localhost
250 mail.ontvanger.nl Hello [222.222.222.222]
De vorige keer lukte het telnet niet omdat de CSF firewall aanstond op de webserver. Kwam hier later pas achter... :drunk:
Ja klopt. Ik heb de help nu voor me en ben de functies aandachtig aan het lezen.
Om het geheel nog vreemder te maken:
[root@srv01 ~]# telnet mail.ontvanger.nl 25
Trying 11.11.1.111...
500 Syntax error, command unrecognized
Connected to mail.ontvanger.nl.
Escape character is '^]'.
220 mail.ontvanger.nl Microsoft ESMTP MAIL Service ready at Sat, 4 Jan 2014 01:38:26 +0100
HELO localhost
250 mail.ontvanger.nl Hello [222.222.222.222]
De vorige keer lukte het telnet niet omdat de CSF firewall aanstond op de webserver. Kwam hier later pas achter... :drunk:
Nu je deze banners kunt zien zou het volgens mij gewoon moeten werken.
Laat je mailer even opnieuw proberen en kijk wat je nu in de logs ziet gebeuren.
patrickekkel
04/01/14, 07:20
Draait hun domein op dezelfde server als die van jou ?
als dit zo is zet dan de local mx server uit op het hosting account van jou klant.
patrickwww
04/01/14, 11:31
OPGELOST
Ik heb het euvel gevonden.
Na de csf firewall op mijn server nogmaals bekeken te hebben kwam ik deze regel tegen:
11.11.1.111 # lfd: (PERMBLOCK) 11.11.1.111 (NL/Netherlands/mail.ontvanger.nl) has had more than 4 temp blocks in the last 86400 secs - Wed Jan 1 16:11:20 2014
Ik heb hun ip-adres op mijn "ignore list" gezet, cfs gerestart en het werkte.
Het zat dus gewoon in mijn eigen server. Ben hier echt stom toevallig tegen aan gelopen, anders had ik het echt niet gevonden.
Misschien tijd dat in de bounce-mail die ik hierop ontving deze foutcode kan komen te staan?? :)
Kan lfd/cfs geen mail sturen zodra hij een IP gaat blokkeren? Dan was dat mogelijk eerder duidelijk geweest. Ook met iptables-save[ | grep <externe ip>] kun je het soms wel vinden als je eigen firewall het "probleem is", het externe ip is dan het ip dat je probeert te bereiken.
Wel, als ze via spamexperts verzenden heb je geen bewijs dat er een werkend tcp/25 pad is tussen hun server en de jouwe is .
Alleen voor een pad van hen naar spamexperts, en van spamexperts naar jou.
Ter volledigheid, uitgaande email via SpamExperts loopt altijd via poort 587 en niet via 25.