Frank Ellermann wrote:
Radu Hociung wrote:
let's quickly analyze a mask like m=-65/6 m=213/8
How would this be specified with an excluding-include
(Frank you gotta give this thing a name ;) )
IIRC it was Greg's (our listmom) idea to do something with
"-include" and "+all".
My sincere apologies, Greg, I will be more careful in the future with
giving credit.
/* expand m=-65/6 */
ip4:0.0.0.0/2 ip4:128.0.0.0/1 ip4:96.0.0.0/3
ip4:80.0.0.0/4 ip4:72.0.0.0/5 ip4:68.0.0.0/6
/* expand m=213/8 (213=128+64+16+4+1)*/
-ip4:0.0.0.0/2 -ip4:128.0.0.0/1 -ip4:96.0.0.0/3
-ip4:64.0.0.0/4 -ip4:(128+64+32).0.0.0/5 ...
What exactly do you want with 213/8, there's no "-" in
m=213/8. If you want a PASS for this /8 you'd just say
+ip4:213.0.0.0/8
Well, all mask modifers evaluate as a group. Only one is required to
carry the "final result" prefix '-'. For the others it's implied. The
order in which the masks are evaluated does not matter.
So "m=-65/5 m=213/8" is equivalent to "m=-65/5 m=-213/8", while
"m=-65/5 m=+213/8" is not legal.
It is not legal for the following reason:
if the incoming ip is 80.0.0.1, you can't tell by looking at the mask if
this should be rejected with the + or with the -
So, since conflicting prefixes don't make sense, it makes no sense to
require more than one of the mask modifiers to specify the default prefix.
Or is the "-" a typo, and you want a FAIL for all IPs
not belonging to 65/6 or 213/8 ?
Frank, would you mind running the script you wrote to
generate the equivalent include list?
My stupid "anticidr" script handles only one CIDR, but
in that case combining the results manually should be easy:
`anticidr 65/6`: see above
`anticidr 213/8` verbose:
0.0.0.0/1 from 0.0.0.0 up to 127.255.255.255
128.0.0.0/2 from 128.0.0.0 up to 191.255.255.255
192.0.0.0/4 from 192.0.0.0 up to 207.255.255.255
208.0.0.0/6 from 208.0.0.0 up to 211.255.255.255
212.0.0.0/8 from 212.0.0.0 up to 212.255.255.255
224.0.0.0/3 from 224.0.0.0 up to 255.255.255.255
216.0.0.0/5 from 216.0.0.0 up to 223.255.255.255
214.0.0.0/7 from 214.0.0.0 up to 215.255.255.255
`anticidr 213/8` SPF-format:
-ip4:128.0.0.0/2 -ip4:192.0.0.0/4 -ip4:208.0.0.0/6
-ip4:212.0.0.0/8 -ip4:214.0.0.0/7 -ip4:216.0.0.0/5
-ip4:224.0.0.0/3 -ip4:0.0.0.0/1
Combination of anticidr( 65/6 or 213/8 ):
-ip4:128.0.0.0/2 -ip4:192.0.0.0/4 -ip4:208.0.0.0/6
-ip4:212.0.0.0/8 -ip4:214.0.0.0/7 -ip4:216.0.0.0/5
-ip4:224.0.0.0/3 -ip4:0.0.0.0/2 -ip4:96.0.0.0/3
-ip4:80.0.0.0/4 -ip4:72.0.0.0/5 -ip4:68.0.0.0/6
The same in "-include:not.me" style:
me. IN SPF "v=spf1 -include:not.me ..."
not.me. IN SPF "v=spf1 -ip4:65.0.0.0/6 -ip4:213.0.0.0/8 +all"
The "anticidr"-style is unreadable, but your optimizer could
use it.
Because non-PASS mechanims in an included SPF record *do not match*,
Your example would be equivalent to
me. IN SPF "v=spf1 +all"
I will assume you meant:
me. IN SPF "v=spf1 -include:not.me ..."
not.me. IN SPF "v=spf1 ip4:65.0.0.0/6 ip4:213.0.0.0/8 -all"
Dang it, it's a good thing that only compilers are allowed to create
masks. ;)
This record set says "I want to deny senders in nets 65 and 213". I
wanted to say "I want to deny senders that are neither in 65 nor in 213"
The exact opposite. That's why a mask is needed, to allow you to say the
exact opposite of what a mechanism can say.
I think we should also legislate a punishment for manually-created masks. ;)
Seriously though, it will be punishment enough that the manually created
mask will most likely be the opposite of what was intended, and it would
only break the publisher's SPF record.
Unfortunately, the expanded list of ip4: mechanisms grows
very fast as the CIDR increases.
Sure, the worst /32 "anticidr" case has 32 parts, hasn't it ?
At some point your optimizer has to trade "policy length" and
"queries", a chain of "simple" redirect= can be worse than a
really simple "include:not.me".
That's correct. But a really good mask is equivalent to a really long
include, which itself is likely to require more than 1 TXT field.
Poor masks such as /6 and /8 are not even worth the trouble, so unless a
mask is good, it doesn't help much. So if it's not worth the trouble,
it's also not worth adding an include that specifies most of the world
as a possible sender.
But if the mask is any good (/27 or lower), the cost of the equivalent
include method may be several daisy chained includes.
So the better the mask gets, the harder/costlier it is to make it
replace it with includes.
The poorer the mask, the less point there is in an equivalent include.
Frank, out of curiosity, what is the include list for
65.0.0.32/27 ?
Verbose, because my quick and dirty script could be erroneous:
0.0.0.0/2 from 0.0.0.0 up to 63.255.255.255
64.0.0.0/8 from 64.0.0.0 up to 64.255.255.255
65.0.0.0/27 from 65.0.0.0 up to 65.0.0.31
128.0.0.0/1 from 128.0.0.0 up to 255.255.255.255
96.0.0.0/3 from 96.0.0.0 up to 127.255.255.255
80.0.0.0/4 from 80.0.0.0 up to 95.255.255.255
72.0.0.0/5 from 72.0.0.0 up to 79.255.255.255
68.0.0.0/6 from 68.0.0.0 up to 71.255.255.255
66.0.0.0/7 from 66.0.0.0 up to 67.255.255.255
65.128.0.0/9 from 65.128.0.0 up to 65.255.255.255
65.64.0.0/10 from 65.64.0.0 up to 65.127.255.255
65.32.0.0/11 from 65.32.0.0 up to 65.63.255.255
65.16.0.0/12 from 65.16.0.0 up to 65.31.255.255
65.8.0.0/13 from 65.8.0.0 up to 65.15.255.255
65.4.0.0/14 from 65.4.0.0 up to 65.7.255.255
65.2.0.0/15 from 65.2.0.0 up to 65.3.255.255
65.1.0.0/16 from 65.1.0.0 up to 65.1.255.255
65.0.128.0/17 from 65.0.128.0 up to 65.0.255.255
65.0.64.0/18 from 65.0.64.0 up to 65.0.127.255
65.0.32.0/19 from 65.0.32.0 up to 65.0.63.255
65.0.16.0/20 from 65.0.16.0 up to 65.0.31.255
65.0.8.0/21 from 65.0.8.0 up to 65.0.15.255
65.0.4.0/22 from 65.0.4.0 up to 65.0.7.255
65.0.2.0/23 from 65.0.2.0 up to 65.0.3.255
65.0.1.0/24 from 65.0.1.0 up to 65.0.1.255
65.0.0.128/25 from 65.0.0.128 up to 65.0.0.255
65.0.0.64/26 from 65.0.0.64 up to 65.0.0.127
27 parts make sense, I didn't check the details, bye, Frank
No need to check the details, I think the expansion can be as much as
double that for simple masks of one m= modifier, and I think it gets
much more complex than additive when more than one modifier is involved.
In fact, I believe the length of the list grows geometrically as a
function of the fragmentation and width (narrowness?) of the mask set.
I could prove it, but I don't think it's worth the effort, as your list
proves my point just as well.
Thank you very much.
Radu.