Afdrukvoorbeeld
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 .Citaat:
Oorspronkelijk geplaatst door patrickwww
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.
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.
Bedankt voor je bericht.Citaat:
Oorspronkelijk geplaatst door visser
Maar dat heeft er toch niks mee te maken dat ik geen trace kan doen?
Dat de trace niet lukt staat daar los van.Citaat:
Oorspronkelijk geplaatst door patrickwww
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 schreef je :
De 'namelijk' en conclusie kloppen dus niet, omdat ze mail via spamexperts sturen, en dat is wat ik in mijn posting uitlegde.Citaat:
pingen vanaf hun server naar mijn server toe lukt wel.
Ik kan namelijk ook email van hun ontvangen.
Ok,Citaat:
Oorspronkelijk geplaatst door visser
tcptraceroute wordt niet herkend door CentOS6
yum kan tcptraceroute ook niet vinden... Google zegt dat dit wel het geval zou moeten zijn.
Suggesties?
Bah.Citaat:
Oorspronkelijk geplaatst door patrickwww
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.
[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.
Je hebt tcp traceroute al (gebruikt).Citaat:
Oorspronkelijk geplaatst door patrickwww
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.
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.Citaat:
Oorspronkelijk geplaatst door patrickwww
Laat je mailer even opnieuw proberen en kijk wat je nu in de logs ziet gebeuren.
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.
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.
Ter volledigheid, uitgaande email via SpamExperts loopt altijd via poort 587 en niet via 25.Citaat:
Oorspronkelijk geplaatst door visser