Re: IP6 bugs in libspf2

At 01:30 07/09/2013  Saturday, Michael Deutschmann wrote:
>Some serious bugs in libspf2's support for "ip6" mechanisms have come to
>my attention.  It was a little tricky to diagnose because the three bugs
>interact in ways that make the problems hard to see.
>
>It's relevant to discuss this here rather than some libspf2-specific
>forum, because it means that SPF publishers may want to avoid using the
>ip6 mechanism to avoid spurious fails.


i would say if it silent ignores ipv6: (that hit the bug)

then its the duty of the receivers (not the senders) to upgrade/fix

but as this will take time and senders want their mail unhampered

it would be better for 'us' (ie the community)
but someone better/smarter than me

to offer a way for spf-publishers to automate testing their spf records to find any ipv6: lines that will be ignored due to the bug so they can take action

(if none their spf needs no alteration)


if effected ranges found suggest a method for work around such as

(apologies in advance for the length of this post)

(example assuming original posters ip6:2800:3f0:4000::/36 is the only bug hitting range in his record )


instead of -all at end of record first fail normally for so far un passed ip4 

-ip4:0.0.0.0/0 

then fail the lowest largest possible ip6 supernet(s) below your affected ip6 subnet

-ip6:::/3           (0000:: - 1fff:ffff....)
-ip6:2000::/5       (2000:: - 27ff::ffff.....)
---
-ip6:2800::/18      (2800:: - 2800:1fff.....)
-ip6:2800:2000::/20 (2800:2000:: - 2800:2fff.....)
-ip6:2800:3000::/21 (2800:3000:: - 2800:37ff.....)
-ip6:2800:3800::/22 (2800:3800:: - 2800:3bff.....)
-ip6:2800:3c00::/23 (2800:3c00:: - 2800:3dff.....)
-ip6:2800:3e00::/24 (2800:3e00:: - 2800:3eff.....)

then fail the largest possible ip6 supernet(s) above your affected range(s)

-ip6:8000::/1        (8000:: - ffff:ffff...)
-ip6:4000::/2        (4000:: - 7fff:fff...)
-ip6:3000::/4        (3000:: - 3fff:fff....)
-ip6:2c00::/6        (2c00:: - 2fff:fff...)
-ip6:2a00::/7        (2a00:: - 2bff:fff...)
-ip6:2900::/8        (2900:: - 29ff:fff...)
----
-ip6:2800:3f80::/25 (2800:3f80:: - 2800:3fff.....)
-ip6:2800:3f40::/26 (2800:3f40:: - 2800:3f7f.....)
-ip6:2800:3f20::/27 (2800:3f20:: - 2800:3f3f.....)
-ip6:2800:3f10::/28 (2800:3f10:: - 2800:3f1f.....)
----
-ip6:2800:3f08::/29 (2800:3f08:: - 2800:3f0f.....)
-ip6:2800:3f04::/30 (2800:3f04:: - 2800:3f07:ff.....)
-ip6:2800:3f02::/31 (2800:3f02:: - 2800:3f03:ff.....)
-ip6:2800:3f01::/32 (2800:3f01:: - 2800:3f01:ff.....)

assuming all subnets below 32 dont trigger the bug 
it at least cuts down the false-passes if you decide to ~all or ?all

(you can go on to the third/fourth etc but i got lazy and these are guaranteed to not hit the buffer issue)

the deeper you go the less chance forgeries will get false-passes from non-bug-effected receivers that continue to the redirect(below)

next use leftover dns lookups
v=spf1 a:_ipv6_1.domain.com a:_ipv6_2.domain.com etc up to 7

_ipv6_(1-9).domain.com   IN A as many of your highest volume ipv6 ips (that are in an effected subnet) as possible

so some affected ip6-ips still pass positively

then (to ensure the normal records exp= text dosn't trigger for the below fails) 
<http://www.openspf.org/RFC_4408#mod-exp>http://www.openspf.org/RFC_4408#mod-exp    6.2 end note

redirect:_ipv6fail-bugwarn.domain.com

_ipv6fail-bugwarn  IN TXT      "v=spf1 [-~?]all exp=_libspf2-may-be-broken.domain.com"

and
_libspf2-may-be-broken  IN TXT "the libsp2 on receivers system may result in errors due to http://description-of-bug-page if this may be the case please report the case to them or submit it for review via http://reporter-tracker-url/?report=r=%{r}&s=%{s}&i=i{i}"

just as an idea
assuming sender interested in setting up a tracker
(exists: tracking would be nice but %{r} only available to exp=)