At 09:07 PM 3/29/2005 -0800, William Leibzon wrote:
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.
As I understand it, these all relate to DNS loading. In other words, if
loading were not a concern, these flaws in design would be a minor issue.
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.
If we could limit DNS queries to one per email (even just in a special
"defense mode") would that not address the major concerns? My expectation
is that mail system admins would invoke this "defense mode" for only a few
hours, until the DoS storm subsided, and 90% of the legitimate mail would
get through, even during the most intense parts of the storm.
Think positive!! We have a problem with the potential abuse of DNS. How
would you solve this problem, if you really wanted to?
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.
I don't know the history, but it is my understanding that we need to
address the DNS loading issue in SPF1. Maybe the council could give us
some guidance on that. I don't see the m= proposal as a "major change in
syntax". Using the "unknown modifier" is extending the syntax in a way
that was anticipated. Current SPF clients will simply ignore it.
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...
I expect at some point there will be a unified standard allowing
interoperability of the most prevalent methods. This could
include methods as different as SenderID/SPF and DomainKeys. I'll be
happy to participate in that development.
-- Dave
************************************************************ *
* David MacQuigg, PhD email: dmquigg-spf at yahoo.com * *
* IC Design Engineer phone: USA 520-721-4583 * * *
* Analog Design Methodologies * * *
* 9320 East Mikelyn Lane * * *
* VRS Consulting, P.C. Tucson, Arizona 85710 *
************************************************************ *