In <4076D557(_dot_)5090602(_at_)Royer(_dot_)com> Doug Royer
<Doug(_at_)Royer(_dot_)com> writes:
I just read this document.
It seem to me to be SPF except in XML. What are the advantages
of Caller-ID over SPF?
MS C-ID deals with RFC2822 identities, while SPF deals with RFC2821
identities. In this respect, SPF and C-ID are complementary
technologies rather than competing technologies.
C-ID also doesn't have as many different mechanisms to validate
against (e.g. no a:, ptr:, exists:, etc. mechanism. The C-ID <a> mechanism
is equivalent to the SPF ip4:/ip6: mechanisms, not the SPF a:
mechanism). C-ID also doesn't have things like macro-variables, the
include/redirect stuff, softfail result codes, etc. If I recall
correctly, C-ID records have the choice of returning the SPF
equivalents of "pass"/"fail" or returning "unknown" for everything.
An SPF record can be constructed to return any of the status. For
example, "v=spf1 +mx -exists:dnsbl.example.org ~ptr:isp.dialup.com ?all".
For those that see SPF as too complicated, this is a feature. For
those that want this functionality, this is a problem. Choose your
poison.
While C-ID is not an exact subset of SPF, there are programs around
that will translate many C-ID records into SPF records. Also, over
the last 6 months or so, people have played with using SPF records to
validate the RFC2822 data, but nothing solid has come from it. Once
upon a time, the SPF spec even had the "scope=" modifier to let domain
owners choose whether they wanted RFC2821 checking, RFC2822 checking,
or both. This was removed because RFC2822 checking was not well
enough understood.
Oh, take this comparison with a grain of salt, it was done off the top
of my head and there are likely things I forgot about and/or
misremembered.
-wayne