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.