Re: rDNS none in stats with IPv6
Hi Steve, At 06:28 28-05-2008, Steve Bertrand wrote: This may not be the appropriate list, but I'm hoping someone can help me. It is the appropriate list. I have an email server based on Matt Simerson's mail toaster (http://www.tnpi.biz/internet/mail/toaster/) that I've managed to get IPv6 compliant. However, I'm having a very hard time determining exactly where the DNS checks are performed, and how to correct an issue. In my SA stats, the majority (+90%) of email inbound is classified as rdns_none. I have a suspicion that this is due to the IPv6-IPv4 mapped address being written into the headers when I am speaking to a non-native IPv6 MTA: Received: from unknown (HELO mail.apache.org) (:::140.211.11.2) by pearl.ibctech.ca with SMTP; 28 May 2008 09:13:00 - Can someone inform me if this is an SA thing, and if so, where to begin looking/testing with the source to correct this issue? According to your header, there is no reverse DNS for that mail server. If it is within a part of SpamAssassin, I will gladly submit any patches that identify/rectify my problem. The Received headers are parsed in Received.pm. Regards, -sm
Re: rDNS none in stats with IPv6
In my SA stats, the majority (+90%) of email inbound is classified as rdns_none. I have a suspicion that this is due to the IPv6-IPv4 mapped address being written into the headers when I am speaking to a non-native IPv6 MTA: Received: from unknown (HELO mail.apache.org) (:::140.211.11.2) by pearl.ibctech.ca with SMTP; 28 May 2008 09:13:00 - (I presume you are trying to make this server IPv6 only instead of dual stack. When my machine had a globally routable v6 address I got some mail over v6 and some over v4, but didn't used mapped addresses.) It seems that your SMTP listener is not correctly doing reverse dns lookups of mapped addresses, and I'm not sure what the right fix is. Either the SMTP code should notice the mapped address, pull out the v4 address, and look it up, or the resolver should do this automatically. On my NetBSD 4 system (generally pretty hard core about this sort of thing), "dig -x :::140.211.11.2" returns NXDOMAIN on a query of ;2.0.b.0.3.d.c.8.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. IN PTR so I'd guess that it's not a normal expectation for a resolver to extract the mapped address. After the lookup issue is fixed, the received header would have the hostname. >From looking at Received.pm, I don't see that SA is trying to do DNS lookups; rnds_none seems to be about the MTA not having succeeded at rdns lookup, not SA checking it later. But if SA does look it up, teaching it about mapped addresses might be needed too.
Re: rDNS none in stats with IPv6
Greg Troxel wrote: In my SA stats, the majority (+90%) of email inbound is classified as rdns_none. (I presume you are trying to make this server IPv6 only instead of dual stack. When my machine had a globally routable v6 address I got some mail over v6 and some over v4, but didn't used mapped addresses.) When I get a few more minutes, I will go over the reply again, and reply properly. I couldn't believe the response (on and off list) regarding help with IPv6 issues and issues in general. I think that I'll be happy here ;) Steve
Re: rDNS none in stats with IPv6
Greg Troxel wrote: In my SA stats, the majority (+90%) of email inbound is classified as rdns_none. I have a suspicion that this is due to the IPv6-IPv4 mapped address being written into the headers when I am speaking to a non-native IPv6 MTA: Received: from unknown (HELO mail.apache.org) (:::140.211.11.2) by pearl.ibctech.ca with SMTP; 28 May 2008 09:13:00 - (I presume you are trying to make this server IPv6 only instead of dual stack. ...well, not intentionally. My intentions were/are to make this a fully dual-stacked machine that hosts my personal domain that is my first fully IPv6 compliant machine that I've configured. When my machine had a globally routable v6 address I got some mail over v6 and some over v4, but didn't used mapped addresses.) Unfortunately, I'm not intently using mapped addresses. :) I've got a hacked version of Qmail that uses Simscan to fire SA (at least I believe this is how it works). I'll need to go through the Qmail sources to find out where it's writing these mapped addresses. To be honest, I think that the work should focus on fixing the resolver (or whatever calls the resolver) to extract the IPv4 address out of the mapped address, instead of eliminating the mapped address entirely. There are legitimate needs to use mapped addresses. It seems that your SMTP listener is not correctly doing reverse dns lookups of mapped addresses, How can I identify *exactly* what is my SMTP 'listener', and how DNS is called, and by what? and I'm not sure what the right fix is. Either the SMTP code should notice the mapped address, pull out the v4 address, and look it up, or the resolver should do this automaticall I agree. I personally think that the mapped address should remain in the header however. Although I've never tested sending to a mapped address directly, I'll have to...it would be interesting to see how a return to a mapped address ends up if my IPv4 BGP peers go down, but my IPv6 stays up. (generally pretty hard core about this sort of thing), Nice to meet you, I am very much as well (particularly IP and routing :) "dig -x :::140.211.11.2" returns NXDOMAIN on a query of ;2.0.b.0.3.d.c.8.f.f.f.f.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa. IN PTR so I'd guess that it's not a normal expectation for a resolver to extract the mapped address. No, I see the exact same thing via FBSD, but seems right. I've been going over the resolver code itself lately, so I'll have a look. Perhaps it could be fixed right there, and then the SMTP engine (or anything else that relies on DNS) could stay the same. After the lookup issue is fixed, the received header would have the hostname. This is why I didn't know if it were appropriate for the SA list... essentially, I would like to follow up on where in my infrastructure this is broken :) Just think, I set out to set up a simple mail server on IPv6. While doing so, I've written more patches for software in the last week than I have my whole life...and I'm not even a programmer ;) Thanks for the input. Steve
Re: rDNS none in stats with IPv6
Received: from unknown (HELO mail.apache.org) (:::140.211.11.2) by pearl.ibctech.ca with SMTP; 28 May 2008 09:13:00 - Can someone inform me if this is an SA thing, and if so, where to begin looking/testing with the source to correct this issue? The Received headers are parsed in Received.pm. Hmmm...just out of curiosity, what is the first entry below used for, if Resolver.pm is used for header checks? pearl# locate Resolver.pm /usr/local/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/DnsResolver.pm /usr/local/lib/perl5/site_perl/5.8.8/mach/Net/DNS/Resolver.pm Steve
Re: rDNS none in stats with IPv6
Hmmm...just out of curiosity, what is the first entry below used for, if Resolver.pm is used for header checks? pearl# locate Resolver.pm /usr/local/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/DnsResolver.pm /usr/local/lib/perl5/site_perl/5.8.8/mach/Net/DNS/Resolver.pm ...nevermind, sorry for the noise. Steve
Re: rDNS none in stats with IPv6
I've added debugging code to new_dns_packet() and bgsend() (DnsResolver.pm) to print out $host, $type and $class to a log file. What I found is that the mapped address entries are not even seen by DnsResolver.pm at all, hence, there is no DNS lookup even attempted on them. I'm off to find out where exactly the evaluation/gathering of the IP addresses takes place, and try to design a regex that will take the ::: into consideration properly. What I'd like to have happen is the mapped address sent merrily along all the way to the system resolver, then have the system resolver do what needs to be done. Am I taking the right approach here? Or should I have the IPv4 address stripped out of the v6 mapped address prior to pushing it through the Perl resolver gateways? Steve
Re: rDNS none in stats with IPv6
Steve Bertrand wrote: I've added debugging code to new_dns_packet() and bgsend() (DnsResolver.pm) to print out $host, $type and $class to a log file. What I found is that the mapped address entries are not even seen by DnsResolver.pm at all, hence, there is no DNS lookup even attempted on them. Hmmmwhat's worse that I just found out is that *NO* IPv6 addresses are being seen by DnsResolver.pm at all. Steve
Re: rDNS none in stats with IPv6
First, I would advise you not to use mapped addresses unless you really need to use them. On BSD, there's a sysctl to control whether v4 connections will match v6 sockets: net.inet6.ip6.v6only = 1 Best practice seems to be to have daemons open a v4 and v6 socket separately, and avoid mapped addresses. This will get you out of inverse resolving v6 ipv4-mapped addresses, and get you out of teaching SA to extract v4 addresses for checks from the mapped addresses. Then, there's the issue about getting your MTA to resolve v6 addresses. To be honest, I think that the work should focus on fixing the resolver (or whatever calls the resolver) to extract the IPv4 address out of the mapped address, instead of eliminating the mapped address entirely. There are legitimate needs to use mapped addresses. Well, you are of course welcome to that. I think it will prove harder than avoiding mapped addresses.
Re: rDNS none in stats with IPv6
Steve Bertrand writes: > I've added debugging code to new_dns_packet() and bgsend() > (DnsResolver.pm) to print out $host, $type and $class to a log file. > > What I found is that the mapped address entries are not even seen by > DnsResolver.pm at all, hence, there is no DNS lookup even attempted on them. > > I'm off to find out where exactly the evaluation/gathering of the IP > addresses takes place, and try to design a regex that will take the > ::: into consideration properly. > > What I'd like to have happen is the mapped address sent merrily along > all the way to the system resolver, then have the system resolver do > what needs to be done. > > Am I taking the right approach here? Or should I have the IPv4 address > stripped out of the v6 mapped address prior to pushing it through the > Perl resolver gateways? SpamAssassin doesn't perform DNS lookups on the Received headers if at all possible -- it's assumed that your MTA will do that in advance. --j.
Re: rDNS none in stats with IPv6
SpamAssassin doesn't perform DNS lookups on the Received headers if at all possible -- it's assumed that your MTA will do that in advance. Thanks for that. I found this out late last night, and I believe I've got the issue resolved. Regards, Steve
