Subject: [spfbis] host bits in SPF

From: Franck Martin <[email-masked]>
Date: Thu, 13 Jun 2013 00:11:43 +0000

Could SPFbis, indicates the issue with CIDR notation

Considering host A, network B and net mask C

in the SPF record the CIDR notation should be strict A&C == B

While the spf check should use A&C == B&C

207.68.169.173/30 is not valid in an SPF record but 207.68.169.172/30 is valid

while the SPF library should not choke if it finds the first one in an SPF record.

---

From: S Moonesamy <[email-masked]>
Date: Wed, 12 Jun 2013 18:10:45 -0700

Hi Franck,
>while the SPF library should not choke if it finds the first one in 

This is an individual comment.  The prefix length is to identify an 
IP address block.  The above example did not take the network part 
into account.  Some people usually do sanity checks as they don't trust input.

Regards,
S. Moonesamy

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 12 Jun 2013 23:58:53 -0400

> into account.  Some people usually do sanity checks as they don't trust

It is not a particularly rare error for SPF record publishers to publish CIDR 
ranges that don't correctly start at the network boundary.  I think publishers 
SHOULD NOT do that, but they do.  Verifiers SHOULD ignore the host bits that 
are set so that (from the example above), ip4:207.68.169.173/30 SHOULD be 
treated the same as ip4:207.68.169.172/30 (even though it SHOULD NOT be 
published that way).

This is an area where it's, in my opinion, safe to apply Postel's Law and 
still be liberal about what we receive.  Most SPF implementations that I'm 
aware of already treat CIDR blocks with host bits set this way, but not all.  
For consistency, it might make sense to specify correct behavior more 
explicitly.  This came up in a discussion on another list.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 12 Jun 2013 22:44:50 -0700

On Wed, Jun 12, 2013 at 8:58 PM, Scott Kitterman <[email-masked]> wrote:

> > >207.68.169.173/30 is not valid in an SPF record but 207.68.169.172/30is
> > >valid
> > >

RFC4408bis as written explicitly ignores any host bits set beyond the CIDR
prefix:

   The <ip> is compared to the given network.  If CIDR prefix length
   high-order bits match, the mechanism matches.

That looks like the test is (client_addr & mask == policy_addr & mask),
which is perfectly valid to me.

The spec doesn't put any correctness requirements on the publisher, but it
does mean the protocol as defined is deterministic.  I don't think needs to
be changed.

-MSK