In <20040328075529(_dot_)GA20719(_at_)merkur(_dot_)atlantica> Jasmin Buchert
<jasmin(_at_)pacifica(_dot_)ch> writes:
* IPv6 is *now* supported, making libspf-alt the first SPF
implementation to do so. Testing, however, has been limited.
IPv6 addresses are working :) but only with ip6:<ipv6 address> in my SPF
record. Shouldn't it also work with just v=spf1 a if the domain has AAAA
records?
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.)
I do have a few IPv6 questions though:
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?
Similarly, with the exists: mechanism, should the IPv6 address be
looked up, or unmapped 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).
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?
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.)
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.
I'll try get a new release of libspf-alt out soon with this IPv6 stuff
cleared up.
-wayne