Yes - lets deploy SPF as is, or close to it. It is easy on internet
resources and easy to implement.
Other authentication, verification scheme can be developed and deployed
separately and on top of SPF.
Perhaps an optional field could be added to the SPF DNS resource record
that would point to a sender's key server, or alternative authentication
scheme server. A field something like 'ks=123.45.67.89'.
The challenge is get wide acceptance of SPF - I have heard that the
Merak Mail Server http://MerakMailServer.com will have a SPF enable beta
version of their ICE WARP mail server available very soon, like in a few
days. This is an exciting development.
George Young
-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of Stuart
D. Gathman
Sent: Wednesday, June 02, 2004 10:27 AM
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Sender Permitted From vs Sender Policy
Framework
On Wed, 2 Jun 2004, Meng Weng Wong wrote:
| There is actually no need for any mechanism other than exists.
The above is true if we limit sender authentication to designated
sender schemes. However, if we admit the possibility of non-IP-based
schemes eg. DomainKeys, PGP, SMIME, Vanquish, PennyBlack, etc etc, the
case for new mechanisms makes more sense.
But all these other schemes can be evaluated only after the
DATA phase. Because of that, I don't see any advantage in merging
them with SPF.
As long as SPF remains uncontaminated, XML is actually a good framework
for gathering all the DATA phase schemes under one roof. A mail
receiver can pick and choose which schemes he cares to implement. For
instance, checking DomainKeys, PGP, and SMIME, but ignoring Vanquish,
PennyBlack, and Bonded Sender.
The nature of SPF is that *all* defined mechanisms must be implemented
by any receiver, if any are, for it to be useful. You cannot pick and
choose, saying, "I'll do MX, but ignore A." It is logically
evaluated by the sender, with a small set of mechanisms evaluated by the
receiver as an optimization. For SPF, receiver side extensibility is
exactly what we *don't* want. If you really really want to add another
receiver side mechanism (despite not really needing to since you could
use 'exists'), the only way to do it is via version numbers, and
publishing old versions as well as new.
The DATA phase schemes, on the other hand, are ameneble to picking and
choosing. They are logically evaluated by the receiver, and amount to a
variety of seals, some of which the receiver is able to recognize and
validate. XML allows the receiver to parse the whole lot, ignoring the
ones it doesn't recognize or care about.
You could argue that SPF is just another 'scheme'. That all schemes are
independent, but data within a scheme is interdependent. The problem is
that the Big Feature(tm) of SPF is efficiently evaluating before DATA so
that you can detect, and ultimately reject, sender forgeries without
wasting too many resources. If you have to fetch a big XML glob of
dozens of after DATA schemes and parse it to pick out the SPF data, you
have negated a large part of the benefit of SPF. You are not going to
fit all the after DATA schemes into 1 DNS TXT record any way, so there
is no penalty for fetching the XML for after DATA schemes separately
from the SPF record. There *is* a penalty to having to fetch the whole
shooting match before DATA.
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703
591-6154 "Confutatis maledictis, flamis acribus addictis" - background
song for a Microsoft sponsored "Where do you want to go from here?"
commercial.
-------
Sender Policy Framework: http://spf.pobox.com/
The Inbox Event at the Marriott San Jose features SPF.
June 2: Email Accountability Symposium (free)
June 3: SPF Strategy BOF (free) where industry will coordinate
deployment timeline
Times: 6:30pm - 8pm, both sessions. http://www.inboxevent.com/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com