Subtitle: extensibility is bad
As someone else has pointed out, SPFv1 is already completely extensible in
any way desired by means of the 'exists' mechanism and a custom DNS
server.
o The cost of using 'exists' generalized extensions is borne by the
sender - a good thing.
o The semantics of any extensions are defined and implemented by the sender.
There is no need to get millions of mail receivers to track an evolving
standard. This is good.
o Extensibility at the mail receiver end is bad. It doesn't matter that
XML provides extensibility. We don't want extensibility for the
mail receiver. The sender can implement any desired extensions on
his end.
o Extensibility looks good to M$ only because they are envisioning
every mail MTA on the planet running M$ software, allowing them to
coordinate rollout of extensions with new versions of M$ software.
Consumers everywhere will prefer M$ software for MTA because it won't have as
many problems working with the latest round of extensions to the
extensible XML CID/SPF.
o I was originally daunted by the thought of 'a custom DNS server', but
server people have pointed me to code that makes setting one up in Python
trivial. This is good enough for me right now. A VM prevents buffer
overflow in the custom code, and if the interpreter doesn't run strings
through /bin/sh behind your back (leaving Perl out, I think), security
of the custom code will be reasonable. Ultimately, the
security of a custom DNS would be improved by having the front line DNS
server proxy requests to a back end server that is not directly available
to the public. A simple port redirector would allow the custom DNS
server to be effectively sandboxed now - if no standard DNS runs on the
same host.
--
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.