On Tue, 29 Mar 2005, David MacQuigg wrote:
I'm just going by what I have read on this list. As I understand it, the
objections to SPF at the vote on the last draft had to do with DNS loading.
It has to do with problems in design and higher dns load is just a
visible end-result of those. Particularly various IETF people and those
involved in dns have problems with:
1. (Ab)use of of TXT record
2. Use of dns for what amounts to general-purpose email policy database
3. Structure of SPF is not properly layered and technically wrong.
What may seem like a convinience to some of yoy as far as being
able to define both hosts with "a" and "mx" operators and ip
addresses directly with "ip4" is not correct way to do such design
(and that is obvious to almost every serious protocol engineer).
It should first be layer listing hosts/networks authorized to act
on behalf of given domain and then those hosts ip addresses may be
further looked (if this is needed, which is not necessary if host
is already verified in some other way) in dns. Basicly RMX
or Paul Vixie's MAIL-FROM is a lot more cleaner design...
4. This structure of many spf operators and macros may cause high dns
load and this load is not always easy to predict and because of
the incorrect layered design there is possibility of loops and
security issues that otherwise could be taken care of easily.
If we can address those concerns by something as simple as adding a modifier
that doesn't break anything, I would say go for it.
You can't address major concerns with simple modifier.
I don't usually like "adding features" in a situation like this, but I think
of masks as a counter to some features that were added without much thought
as to abuse. The purpose is not to add new conveniences, but limit abuse.
...
I think Radu addressed this point yesterday. As I understand it, we are free
to define any syntax we want within the string on the right side of m=.
Maybe to avoid confusion we should write the compact notation as
24~24.30.203.
The purpose of spf-classic draft is to document current use of SPF and you
can't go walking around with major change to syntax that would not be
undertood by current SPF clients as many people pointed before. If you are
interested in contributions and changes to syntax, those would need to go
to next step in development of SPF (likely SPF3 as SPF2 has been
"contaminated" by MARID experience and further anauthorized use for
so-called SenderID drafts). There are many things to talk about for next
SPF and I was hoping the formation of the council would have helped to
quickly resolve SPF1 issues and move those along and that now we'd be well
on the way of working on UnifiedSPF and next version of SPF record.
Unfortunetly SPF council has been slow and UnifiedSPF has not been
mentioned in almost 4-6 months...
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net