On Sun, 2004-03-28 at 08:17 -0600, wayne wrote:
Uh, yes, that is certainly a bug, and a kind of a stupid one on my
part. I'll try to release a new version soon. (I correctly query
for AAAA records, and then proceed to look for A records in the results.)
Doesn't getaddrinfo() do this all for you if used appropriately?
If you have an IPv4 addressed that was mapped into IPv6
(e.g. ::FFFF:d.d.d.d), should the a: and mx: mechanisms check for A
RRs or AAAA RRs?
I'd suggest A RRs. The ::FFFF:d.d.d.d addresses _are_ IPv4 addresses,
basically. That's what you'll get if you receive a connection from a
real IPv4 host on an IPv6 socket which is set up to receive either IPv4
or IPv6 connections.
Similarly, with the exists: mechanism, should the IPv6 address be
looked up, or unmapped IPv4 address?
For ::FFFF:d.d.d.d, again I'd suggest looking up the IPv4 address.
Remember that SPF doesn't really use either IPv4 or IPv6, it is just
comparing things and such. No network connections are opened, and the
OS doesn't even need to support IPv6 (or IPv4 for that matter).
Well, except to the extent that unless it can handle IPv6 you're not
going to be getting an IPv6 address from getpeername() are you? :)
But for the SPF lookup part when treated as a black box, of course
you're right.
Basically, I suspect that anytime I get an IPv4 mapped IPv6 address, I
should just proceed as if I had gotten an IPv4 address. Does this
sound right?
It does to me.
You might want to ponder the question of whether you _also_ want to look
up 2002::/16 addresses as IPv4 too. Addresses in the range
2002:xxyy:zzww::/48 are guaranteed to be coming from the IPv4 address
xx.yy.zz.ww.
Also, when evaluating the exits: mechanism, right now it looks for an
A RR, which matches the way that DNSBLs all work. When you get a real
IPv6 address (not just a mapped IPv4 address), should the exists:
mechanism look for an A record, or an AAAA record? Are there DNSBL
out there for IPv6? If so, how do they work? (I think we should
continue to try to be compatible with DNSBLs.)
I don't know of a DNSBL for IPv6, but I see no reason why it should
return AAAA records in its output just because the _input_ is of the
form 'x.y.z.........2.0.0.2.dsnbl.domain.org', any more than a
domain-based DNSBL needs to return a TXT record instead of an A record
for e.g. bigfoot.com.postmaster.rfc-ignorant.org.
Seems reasonable to continue to use A records.
Since all that is being returned by DNSBLs (and therefore the exits:
mechanism) is, in effect, a flag and since A records are shorter than
AAAA records, I suspect that the exist: mechanism should look for an A
RR.
That seems reasonable to me too.
I'll try get a new release of libspf-alt out soon with this IPv6 stuff
cleared up.
If you want IPv6 for testing, and haven't got it already -- are you
aware you can enable '6to4' IPv6, where you automatically get a /48
subnet derived from your IPv4 address, with about two lines of addition
to most recent Linux initscripts, and probably also a similar amount of
effort on other systems?
--
dwmw2