PDA

Bekijk Volledige Versie : Exim traag via IPv6



Mattie
20/11/16, 19:40
Goed, ik heb het volgende probleem:

Het verzenden van email over IPv6 is "traag". Zie het volgende:



root@raspberrypi:/home/pi# date && telnet xxxx:xxxx::xx 587
Fri 18 Nov 15:36:45 CET 2016
Trying xxxx:xxxx::xx...
Connected to xxxx:xxxx::xx.
Escape character is '^]'.
220 vps.host.nl ESMTP Exim 4.87 Fri, 18 Nov 2016 15:37:05 +0100
quit
221 vps.host.nl closing connection
Connection closed by foreign host.


Zoals je ziet duurt het 40 sec tussen mijn connectie en de greeting van Exim. Doe ik hetzelfde over IPv4 dan zie ik het volgende:



root@raspberrypi:/home/pi# date && telnet xx.xx.xx.xx 587
Fri 18 Nov 15:37:29 CET 2016
Trying xx.xx.xx.xx...
Connected to xx.xx.xx.xx.
Escape character is '^]'.
220 vps.host.nl ESMTP Exim 4.87 Fri, 18 Nov 2016 15:37:30 +0100
quit
221 vps.host.nl closing connection
Connection closed by foreign host.


Dus je zou zeggen: een IPv6 probleem, echter wanneer ik hetzelfde doe vanaf mijn werk dan is het wél snel.



matthijs@MATTHIJS_PC:~$ date && telnet xxxx:xxxx::xx 587
Fri Nov 18 15:37:11 STD 2016
Trying xxxx:xxxx::xx...
Connected to xxxx:xxxx::xx.
Escape character is '^]'.
220 vps.host.nl ESMTP Exim 4.87 Fri, 18 Nov 2016 15:37:11 +0100
quit
221 vps.host.nl closing connection
Connection closed by foreign host.


Connect ik vanaf thuis over IPv6 naar de Gmail SMTP server is het ook snel....

Vreemd of niet?
Ping over IPv6 vanaf thuis is netjes 7ms. Ik moet wel zeggen dat mijn IPv6 connectie over een TunnelBroker (HE) tunnel loopt.

Dus:
thuis - ipv6 - traag
thuis - ipv4 - snel
werk - ipv6 - snel
werk - ipv4 - snel
thuis - ipv6 gmail - snel
thuis - ipv4 gmail - snel

Iemand enig idee waar dit aan kan liggen? Server configuratie? Of toch iets met de IPv6 tunnel?

visser
20/11/16, 21:22
Goed, ik heb het volgende probleem:

Het verzenden van email over IPv6 is "traag". Zie het volgende:



root@raspberrypi:/home/pi# date && telnet xxxx:xxxx::xx 587
Fri 18 Nov 15:36:45 CET 2016
Trying xxxx:xxxx::xx...
Connected to xxxx:xxxx::xx.
Escape character is '^]'.
220 vps.host.nl ESMTP Exim 4.87 Fri, 18 Nov 2016 15:37:05 +0100
quit
221 vps.host.nl closing connection
Connection closed by foreign host.


Zoals je ziet duurt het 40 sec tussen mijn connectie en de greeting van Exim. Doe ik hetzelfde over IPv4 dan zie ik het volgende:



root@raspberrypi:/home/pi# date && telnet xx.xx.xx.xx 587
Fri 18 Nov 15:37:29 CET 2016
Trying xx.xx.xx.xx...
Connected to xx.xx.xx.xx.
Escape character is '^]'.
220 vps.host.nl ESMTP Exim 4.87 Fri, 18 Nov 2016 15:37:30 +0100
quit
221 vps.host.nl closing connection
Connection closed by foreign host.


Dus je zou zeggen: een IPv6 probleem, echter wanneer ik hetzelfde doe vanaf mijn werk dan is het wél snel.



matthijs@MATTHIJS_PC:~$ date && telnet xxxx:xxxx::xx 587
Fri Nov 18 15:37:11 STD 2016
Trying xxxx:xxxx::xx...
Connected to xxxx:xxxx::xx.
Escape character is '^]'.
220 vps.host.nl ESMTP Exim 4.87 Fri, 18 Nov 2016 15:37:11 +0100
quit
221 vps.host.nl closing connection
Connection closed by foreign host.


Connect ik vanaf thuis over IPv6 naar de Gmail SMTP server is het ook snel....

Vreemd of niet?
Ping over IPv6 vanaf thuis is netjes 7ms. Ik moet wel zeggen dat mijn IPv6 connectie over een TunnelBroker (HE) tunnel loopt.

Dus:
thuis - ipv6 - traag
thuis - ipv4 - snel
werk - ipv6 - snel
werk - ipv4 - snel
thuis - ipv6 gmail - snel
thuis - ipv4 gmail - snel

Iemand enig idee waar dit aan kan liggen? Server configuratie? Of toch iets met de IPv6 tunnel?

Je hebt geen idee wat het is , maar laat wel informatie weg - de ip adressen .

Dan heb ik weinig zin om verder na te denken.

basis tip : draai tcpdump (op alle verkeer) en kijk wat er gebeurt bij een binnenkomende connectie .

knippin
21/11/16, 08:26
tcpdump. en misschien handig te melden welke provider thuis en werk is. niet alle adsl providers hebben ipv6 op orde.



Sent from my SM-G930F using webhostingtalk mobile app

PimEffting
21/11/16, 08:50
Heb je wel je reverse DNS op je IPv6 adressen gezet?

Mattie
21/11/16, 11:11
Ok, de IP adressen kan ik net zo goed delen, was puur ter voorkoming van attacks (dat gebeurt me al vaak genoeg :p)

IPv6: 2a05:e1c0::38
IPv4: 91.218.127.50

Connectie thuis loopt over HurricaneElectric tunnel en werk is Ziggo.

Reverse DNS is aanwezig.

Hierbij even een tcpdump puur op poort 587



root@vps:~# tcpdump -i eth0 port 587
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:04:21.043192 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [S], seq 1485902214, win 28800, options [mss 1440,sackOK,TS val 101144306 ecr 0,nop,wscale 6], length 0
11:04:21.043249 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [S.], seq 1431914502, ack 1485902215, win 28560, options [mss 1440,sackOK,TS val 254417873 ecr 101144306,nop,wscale 6], length 0
11:04:21.091339 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 1, win 450, options [nop,nop,TS val 101144310 ecr 254417873], length 0
11:04:41.180057 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [P.], seq 1:76, ack 1, win 447, options [nop,nop,TS val 254422907 ecr 101144310], length 75
11:04:41.450661 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [P.], seq 1:76, ack 1, win 447, options [nop,nop,TS val 254422975 ecr 101144310], length 75
11:04:41.602771 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 76, win 450, options [nop,nop,TS val 101146362 ecr 254422907], length 0
11:04:41.610829 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 76, win 450, options [nop,nop,TS val 101146362 ecr 254422975,nop,nop,sack 1 {1:76}], length 0
11:04:47.531749 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [P.], seq 1:7, ack 76, win 450, options [nop,nop,TS val 101146955 ecr 254422975], length 6
11:04:47.531790 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [.], ack 7, win 447, options [nop,nop,TS val 254424495 ecr 101146955], length 0
11:04:47.531871 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [P.], seq 76:122, ack 7, win 447, options [nop,nop,TS val 254424495 ecr 101146955], length 46
11:04:47.532062 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [F.], seq 122, ack 7, win 447, options [nop,nop,TS val 254424495 ecr 101146955], length 0
11:04:47.539900 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 122, win 450, options [nop,nop,TS val 101146955 ecr 254424495], length 0
11:04:47.542045 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [F.], seq 7, ack 123, win 450, options [nop,nop,TS val 101146956 ecr 254424495], length 0
11:04:47.542060 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [.], ack 8, win 447, options [nop,nop,TS val 254424497 ecr 101146956], length 0
^C
14 packets captured
16 packets received by filter
0 packets dropped by kernel


En vanaf de client zie ik dit:



root@raspberrypi:/home/pi# tcpdump -i wlan0 port 587
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:04:21.022981 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [S], seq 1485902214, win 28800, options [mss 1440,sackOK,TS val 101144306 ecr 0,nop,wscale 6], length 0
11:04:21.070549 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [S.], seq 1431914502, ack 1485902215, win 28560, options [mss 1220,sackOK,TS val 254417873 ecr 101144306,nop,wscale 6], length 0
11:04:21.070793 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 1, win 450, options [nop,nop,TS val 101144310 ecr 254417873], length 0
11:04:41.582219 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [P.], seq 1:76, ack 1, win 447, options [nop,nop,TS val 254422907 ecr 101144310], length 75
11:04:41.582412 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 76, win 450, options [nop,nop,TS val 101146362 ecr 254422907], length 0
11:04:41.584272 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [P.], seq 1:76, ack 1, win 447, options [nop,nop,TS val 254422975 ecr 101144310], length 75
11:04:41.584453 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 76, win 450, options [nop,nop,TS val 101146362 ecr 254422975,nop,nop,sack 1 {1:76}], length 0
11:04:47.511910 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [P.], seq 1:7, ack 76, win 450, options [nop,nop,TS val 101146955 ecr 254422975], length 6
11:04:47.519023 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [.], ack 7, win 447, options [nop,nop,TS val 254424495 ecr 101146955], length 0
11:04:47.519680 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [P.], seq 76:122, ack 7, win 447, options [nop,nop,TS val 254424495 ecr 101146955], length 46
11:04:47.519816 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 122, win 450, options [nop,nop,TS val 101146955 ecr 254424495], length 0
11:04:47.521642 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [F.], seq 122, ack 7, win 447, options [nop,nop,TS val 254424495 ecr 101146955], length 0
11:04:47.522239 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [F.], seq 7, ack 123, win 450, options [nop,nop,TS val 101146956 ecr 254424495], length 0
11:04:47.530946 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [.], ack 8, win 447, options [nop,nop,TS val 254424497 ecr 101146956], length 0
^C
14 packets captured
14 packets received by filter
0 packets dropped by kernel


Ik moet toegeven dat ik hier niet zo erg bedreven in ben, als er meer info nodig is hoor ik het graag.

Heb alleen even voor google de hostname van mijn server onleesbaar gemaakt.

Mattie
21/11/16, 19:04
Even een toevoeging:

SERVER:


(exim uit)
root@vps:~# nc -6 -l -p 587
test


CLIENT:


root@raspberrypi:/home/pi# time nc -6 2a05:e1c0::38 587
test
^C

real 0m1.978s
user 0m0.000s
sys 0m0.030s


Nu met exim aan



root@raspberrypi:/home/pi# time nc -6 2a05:e1c0::38 587
220 vps.hostname.nl ESMTP Exim 4.87 Mon, 21 Nov 2016 19:02:17 +0100
^C

real 0m22.434s
user 0m0.010s
sys 0m0.010s


Eh wie snapt het nog? Het is in elk geval niet mijn connectie thuis.

T. Verhaeg
21/11/16, 21:39
Doet je exim geen (reverse) DNS lookups op binnenkomende connecties?

visser
21/11/16, 22:40
Ok, de IP adressen kan ik net zo goed delen, was puur ter voorkoming van attacks (dat gebeurt me al vaak genoeg :p)

IPv6: 2a05:e1c0::38
IPv4: 91.218.127.50

Connectie thuis loopt over HurricaneElectric tunnel en werk is Ziggo.

Reverse DNS is aanwezig.

Hierbij even een tcpdump puur op poort 587



root@vps:~# tcpdump -i eth0 port 587
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:04:21.043192 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [S], seq 1485902214, win 28800, options [mss 1440,sackOK,TS val 101144306 ecr 0,nop,wscale 6], length 0
11:04:21.043249 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [S.], seq 1431914502, ack 1485902215, win 28560, options [mss 1440,sackOK,TS val 254417873 ecr 101144306,nop,wscale 6], length 0
11:04:21.091339 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 1, win 450, options [nop,nop,TS val 101144310 ecr 254417873], length 0
11:04:41.180057 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [P.], seq 1:76, ack 1, win 447, options [nop,nop,TS val 254422907 ecr 101144310], length 75
11:04:41.450661 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [P.], seq 1:76, ack 1, win 447, options [nop,nop,TS val 254422975 ecr 101144310], length 75
11:04:41.602771 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 76, win 450, options [nop,nop,TS val 101146362 ecr 254422907], length 0
11:04:41.610829 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 76, win 450, options [nop,nop,TS val 101146362 ecr 254422975,nop,nop,sack 1 {1:76}], length 0
11:04:47.531749 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [P.], seq 1:7, ack 76, win 450, options [nop,nop,TS val 101146955 ecr 254422975], length 6
11:04:47.531790 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [.], ack 7, win 447, options [nop,nop,TS val 254424495 ecr 101146955], length 0
11:04:47.531871 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [P.], seq 76:122, ack 7, win 447, options [nop,nop,TS val 254424495 ecr 101146955], length 46
11:04:47.532062 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [F.], seq 122, ack 7, win 447, options [nop,nop,TS val 254424495 ecr 101146955], length 0
11:04:47.539900 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 122, win 450, options [nop,nop,TS val 101146955 ecr 254424495], length 0
11:04:47.542045 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [F.], seq 7, ack 123, win 450, options [nop,nop,TS val 101146956 ecr 254424495], length 0
11:04:47.542060 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [.], ack 8, win 447, options [nop,nop,TS val 254424497 ecr 101146956], length 0
^C
14 packets captured
16 packets received by filter
0 packets dropped by kernel


En vanaf de client zie ik dit:



root@raspberrypi:/home/pi# tcpdump -i wlan0 port 587
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:04:21.022981 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [S], seq 1485902214, win 28800, options [mss 1440,sackOK,TS val 101144306 ecr 0,nop,wscale 6], length 0
11:04:21.070549 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [S.], seq 1431914502, ack 1485902215, win 28560, options [mss 1220,sackOK,TS val 254417873 ecr 101144306,nop,wscale 6], length 0
11:04:21.070793 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 1, win 450, options [nop,nop,TS val 101144310 ecr 254417873], length 0
11:04:41.582219 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [P.], seq 1:76, ack 1, win 447, options [nop,nop,TS val 254422907 ecr 101144310], length 75
11:04:41.582412 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 76, win 450, options [nop,nop,TS val 101146362 ecr 254422907], length 0
11:04:41.584272 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [P.], seq 1:76, ack 1, win 447, options [nop,nop,TS val 254422975 ecr 101144310], length 75
11:04:41.584453 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 76, win 450, options [nop,nop,TS val 101146362 ecr 254422975,nop,nop,sack 1 {1:76}], length 0
11:04:47.511910 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [P.], seq 1:7, ack 76, win 450, options [nop,nop,TS val 101146955 ecr 254422975], length 6
11:04:47.519023 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [.], ack 7, win 447, options [nop,nop,TS val 254424495 ecr 101146955], length 0
11:04:47.519680 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [P.], seq 76:122, ack 7, win 447, options [nop,nop,TS val 254424495 ecr 101146955], length 46
11:04:47.519816 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [.], ack 122, win 450, options [nop,nop,TS val 101146955 ecr 254424495], length 0
11:04:47.521642 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [F.], seq 122, ack 7, win 447, options [nop,nop,TS val 254424495 ecr 101146955], length 0
11:04:47.522239 IP6 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052 > vps.hostname.nl.submission: Flags [F.], seq 7, ack 123, win 450, options [nop,nop,TS val 101146956 ecr 254424495], length 0
11:04:47.530946 IP6 vps.hostname.nl.submission > 2001:470:1f15:787:35f:76a4:ecfd:d12f.48052: Flags [.], ack 8, win 447, options [nop,nop,TS val 254424497 ecr 101146956], length 0
^C
14 packets captured
14 packets received by filter
0 packets dropped by kernel


Ik moet toegeven dat ik hier niet zo erg bedreven in ben, als er meer info nodig is hoor ik het graag.

Heb alleen even voor google de hostname van mijn server onleesbaar gemaakt.

Doe dan tcpdump -n .
Uiteindelijk kan nu niemand op jouw server testen.

Maar vooruit mijn tip was : tcpdump op *AL* je verkeer. Dus niet alleen op poort 587 .
Dat had een reden :

Mijn gok is dat je vps een reverse DNS lookup doet op het IP van de binnenkomende connectie.
Met een tcpdump op al je verkeer zou je de poging tot lookup zien .

(en eventueel icmp/icmpv6 verkeer mis je ook als je alleen naar een tcp/udp poort kijkt )

Mattie
22/11/16, 10:33
Yes, dat is het! Ik heb continue gekeken naar de rDNS van mijn SERVER en niet van mijn client. Ik heb van HE netjes een /64 block gekregen en deze staat qua rDNS gedelegeerd naar mijn eigen nameservers. Blijkbaar is *.123.123.123.123.ip6.arpa" niet mogelijk in bind waardoor er dus voor de client geen rDNS entry is. Voeg ik die even handmatig toe werkt het als een trein!

Goed, dan ga ik nu uitzoeken of ik een "catch all" entry kan maken of anders of ik allicht de rDNS lookup uit zet. Bedankt in elk geval!

visser
22/11/16, 10:55
Yes, dat is het! Ik heb continue gekeken naar de rDNS van mijn SERVER en niet van mijn client. Ik heb van HE netjes een /64 block gekregen en deze staat qua rDNS gedelegeerd naar mijn eigen nameservers. Blijkbaar is *.123.123.123.123.ip6.arpa" niet mogelijk in bind waardoor er dus voor de client geen rDNS entry is. Voeg ik die even handmatig toe werkt het als een trein!

Goed, dan ga ik nu uitzoeken of ik een "catch all" entry kan maken of anders of ik allicht de rDNS lookup uit zet. Bedankt in elk geval!

Ik zou die lookup uitzetten.
Je kunt het voor je eigen thuistunneltje dan wel fixen (dat is ook wel netjes om te doen), maar als je werkelijk mail wilt ontvangen ben je dus bezig om een deel van alle afzendende servers 30 seconden te laten wachten - er zullen altijd wel servers connecten zonder rDNS.
(wat dus tijdens de lookup ook een proces actief houdt op je server ) . Op kleine schaal maakt het uiteindelijk weinig uit, maar ik zou het uitzetten.

Mattie
22/11/16, 11:14
Allright, daar had ik nog niet aan gedacht nee, verwacht dat de meeste wel een rDNS entry hebben (zie dat met powerdns netjes * mogelijk is) maar inderdaad allicht kan het beter uit. Zal me even inlezen in waar het precies voor gebruikt wordt. Maar in elk geval bedankt!

Serveo
13/12/16, 17:12
rDNS lookup timeout instellen is ook een optie:

# RFC1413 lookups can cause timeouts. (ident)
rfc1413_hosts = *
rfc1413_query_timeout = 5s

visser
14/12/16, 00:35
rDNS lookup timeout instellen is ook een optie:

# RFC1413 lookups can cause timeouts. (ident)
rfc1413_hosts = *
rfc1413_query_timeout = 5s

Er staat RFC1413, er staat ident , waarom heb je het dan over rDNS lookups ?

Er zijn dus meer "lookups" dan alleen rDNS .....

ident lookups moet je zeker uitzetten - de kans is heel groot dat je lookup verzandt in een firewall met 'drop' (ipv reject) en dus lang blijft hangen.
De meerwaarde is nihil.

Voor degenen die ident niet kennen - het is een protocol waarover je aan de plek waar een connectie vandaan komt vraagt "welk proces van welke user zet deze connectie naar mij op ".
Dat kun je dan in je logfiles zetten .
Het is net zo betrouwbaar als de server waar de connectie vandaan komt .

Het had z'n nut in de tijd van shared unixen op universiteiten, of in machines met een gemeenschappelijke beheerder.
In heel specifieke situaties kan het nog steeds wel ergens handig voor zijn.
Op een publieke mailserver - zet de lookup maar uit.

Mattie
15/12/16, 16:24
Bedankt voor de tip:



# the timeout that is used. If you set the timeout to zero, all RFC 1413 calls
# are disabled. RFC 1413 calls are cheap and can provide useful information
[..]
rfc1413_hosts = *
rfc1413_query_timeout = 0s


Alleen bij mij stond dat al uit, heb inmiddels ook keurig de rDNS werkend dus ik heb er geen last meer van.

Serveo
03/01/17, 13:15
visser je hebt gelijk. Daar doelde ik op naast het fixen van de rDNS, aangezien ident, zoals je zelf ook aangeeft, een vertraging verzorgen.