On Jun 12, 2013, at 2:37 PM, Scott Kitterman <[email protected]> wrote:
> On Wednesday, June 12, 2013 09:07:29 PM Murray Kucherawy wrote: >> On 6/12/13 1:54 PM, "Scott Kitterman" <[email protected]> wrote: >>> On Wednesday, June 12, 2013 04:24:40 PM Tim Draegen wrote: >>>> On Jun 12, 2013, at 3:47 PM, Benny Pedersen <[email protected]> wrote: >>>>> so in other words: >>>>> >>>>> 127.0.2.0/24 >>>>> 127.0.0.0/8 >>>>> >>>>> gives the same error in spf ? >>>> >>>> No errors, these are properly formed. >>>> >>>> I'll try my best to explain this, maybe something more concise will >>>> >>>> fallout >>>> >>>> afterward: >>>> >>>> 127.0.2.0 as bits looks like: >>>> 01111111.00000000.00000010.00000000 >>>> >>>> The netmask "/24" is (255.255.255.0): >>>> 11111111.11111111.11111111.00000000 >>>> >>>> Notice how you can apply the netmask "covers" all of 127.0.2.0 with only >>>> zeroes left over? Same with the 2nd example: >>>> >>>> 127.0.0.0: >>>> 11111111.00000000.00000000.00000000 >>>> >>>> netmask "/8" (255.0.0.0): >>>> 11111111.00000000.00000000.00000000 >>>> >>>> Now, check out 207.68.169.173/30: >>>> >>>> 207.68.169.173: >>>> 11001111.01000100.10101001.10101101 <<<<<<<<<<<< that last "1" is a >>>> >>>> "host >>>> >>>> bit" netmask "/30": >>>> 11111111.11111111.11111111.11111100 >>>> >>>> Network objects (207.68.169.173/30 in this case) should not contain host >>>> bits (that last "1"). >>>> >>>> Malformed network objects: today's piece of esoterica! >>> >>> In the new ipaddress module in python3.3, having host bits are errors by >>> default, you have to specify that you don't want strict processing to >>> avoid >>> them, so it doesn't suprise me it comes up elsewhere. >>> >>> ipaddress.IPv6Network(netwrk, strict=False) >> >> Is that rigidity specified somewhere or is it just common practice? For >> my own implementations I've always just ignored any host bits set; >> basically if you want to see if host A is in network B with mask C, you >> see if A&C == B&C, and that's it. > > As is often the case, the situation seems clear as mud standards wise. RFC > 4632 seems to be the state of the art. It says, "bits in a 32-bit IPv4 > address are interpreted as the network number" and "In CIDR notation, a > prefix > is shown as a 4-octet quantity, just like a traditional IPv4 address or > network number". In other words, it's LIKE an IPv4 address, but it's not an > IPv4 address. Every single example in 4632 has no host bits set. > > I think technically being strict and not considering an IP address with host > bits as a network name is more correct, but I think in practical terms it's > probably over strict. > I think this is where John Postel comes in... It is correct for dmarcian to raise a warning and for spf libraries to do A&C == B&C rather than A&C == B Is there still room for a note in SPFbis RFC? _______________________________________________ dmarc-discuss mailing list [email protected] http://www.dmarc.org/mailman/listinfo/dmarc-discuss NOTE: Participating in this list means you agree to the DMARC Note Well terms (http://www.dmarc.org/note_well.html)
