On Mon, 7 Jun 2004, Julian Mehnle wrote:
I'm thinking about forking SPF into "The New SPF" and a non-XML "SPF1"
variant, i.e. keep The Old SPF going separately and independently from The
New SPF.
Who's with me?
A "fork" implies that one branch of the fork plans to ignore the other branch
completely. I think what is needed is not a "fork". In fact, I suggest we
*not* call it a fork. I really like the proposed term "layers". We need to
keep layer 1 (SPF1 - before DATA - RFC 2821). Layer 2 (XML/CID - after DATA -
RFC2822) can proceed independently. They are not mutually exclusive. There is
value to using either or both.
There are some proposed extensions to layer 1 which basically copy some data
from layer 2 to layer 1 and verify it later by comparing to the
actual RFC 2822 header. This may allow more messages to be rejected
in layer 1 (if the copied data is a lie, it will be rejected in layer 2).
These extensions are worth considering. However, trying to directly combine
layer 1 with layer 2 will kill both.
It will be much easier to sell supporting both SPF and XML syntax if
each syntax is confined to its own layer. Layer 1 needs the lightweight
SPF syntax. Layer 2 benefits from the flexibility of XML - especially
the ability to extract only the subtrees supported by local software.
Users and vendors would not be required to implement both. If they
only want to check layer 1 authentication, they need only parse SPF1.
If they want to authenticate RFC 2822 headers, (other than the
ones copied to layer 1 in a future revision of SPF1) and/or message body
and signatures, they will need to parse XML.
--
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.