Radu Hociung wrote:
["anticidr"]
While the first one does not require queries, it is very
space inefficient.
Yes, and hard to read / debug manually. OTOH my "personal SPF
ideology" is that a receiver is only interested in FAILs.
The possible FAIL and rejecting mails before they go into more
expensive checks like SURBL is IMNSHO the main reason, why a
receiver would consider to use SPF at all. That's the part I
like most in this "m=" thread, you want some simple FAILs fast.
The second one requires at least one query.
It's more like "exactly one additional query", -include:not.me
at the begin of a policy, and for the "included" not.me policy
you have enough bytes for really complex cases, "v=spf1 +all"
are 11 char.s, the remaining 400+ bytes can be weird CIDRs like
"-ip4:12.34.123.234/21", about 21+1 char.s per CIDR.
About 20 CIDRs for you to define "not.me" with this trick. So
that's IMHO good enough to drop the "m=" idea, because it only
saves one query if the complete "not.me" stuff fits into the
"main" policy.
If you need any redirect= or similar only because the m= gets
too long, you could always use a simple -include:not.me trick.
In other words, I like the idea behind "m=" and think we should
get it into Andy's "SPF cookbook", but I prefer Greg's solution
-include:not.me instead of a new "m=" modifier. SPF is already
burdened with too many mechanisms and modifiers, it's not the
time to add a new essentially redundant "m=".
[ Not for you, but general: I'm on record since at least nine
months, that the top priority before anything else should be
to get a proper RfC for v=spf1 "as is" modulo some necessary
fixes. It's really difficult for me to concentrate on new
ideas for spf2.0 (or v=spf2) while v=spf1 is not ready. This
is just my bi-weekly rant and has nothing to do with "m=". ]
Bye, Frank