Meng,
here's a couple of thoughts about Microsoft's proposal which I noticed at
my first tries in writing the cid2spf tool:
CID is XML, SPF is ASCII. Size does matter in this case.
CID will concatenate multiple TXT records into one big XML by enumerating
each record to get around the problem of the randomness in the order of
the returned TXT records. SPF does not provide any solution for it, since
its record size is much smaller than the XML of CID and will probably
always fit in a single TXT record.
CID has the A, R and MX tags. SPF has IP4/IP6 (which handle both CID's A
and R tags), MX (like CID's MX) + the following mechanisms: PTR, EXISTS.
To list the allowed senders, in CID a network admin has to announce all
the addresses of them to the public. Drawback: A company who wants to
allow just a couple of servers but doesn't really want to give away its
network infrastructure has no way to do this. In SPF you can use PTR or
EXISTS to have your own private list of allowed IPs (and even change
those whenever you want without having to alter the SPF-record in DNS).
You can't use hostnames in R-tags in CID like you can in IP4/IP6 of
SPF, so things like myname.dyndns.org/24 are not possible.
In SPF you can specify a different domain for the MX mechanism, which
will include the MX-servers for THAT domain. In CID you have only the
empty MX-tag which refers to the current domain.
On CID your record is either active or in "testing" mode, which means
the record has no effect at all (similar to SPFs '~' action). There is
nothing in between like SPFs softfail.
In CIDs A and R tags you can negate an address or range to exclude them
from your list. While writing cid2spf I thought there was no way of doing
this in SPF, but of course there is: Just place the excluded addresses
at the beginning with '-ip4' to fail those.
CID provides a way to include hosts specified by another domain using
the <indirect> tag. This is similar to SPFs include directive, but has
a major difference when the referred domain doesn't provide any CID/SPF
record at all: In CID, if this is the case, the list of hosts will
automatically include the MX-servers for the referred domain (as if
the referred domain declared <m><mx/></m> for its outgoing servers). In
SPF, if the referred domain has no SPF entries (result = "none"), the
result of "unknown" will be returned (as if the domain didn't published
SPF entries). The same functionality as CID is provided by the enhanced
MX mechanism of SPF: You can specify mx:other-domain.com and those will
be added to your list of servers. The only disadvantage of this is not
automatically switching to the SPF-entry of other-domain.com when they
decide to publish one, but one might wonder if this is a bad or good
thing.
I think using just a single <indirect> with no other servers listed in
your CID would emulate a REDIRECT modifier of SPF.
The order of processing of the hostnames is defined in the specification
and cannot be altered by the domain owner by changing the order of the
tags in the CID-record, like you can do in SPF, where the order is
important. Since CID only offers the ability to list IP addresses, there
is no real need to preserve the order. Either its included or not. With
SPF you have many more possibilities (think macros and exist!).
Of course, CID doesn't provide the neat macros we have in SPF, so any
other kind of checks you might want to do are not possible. This would
include checking for the user-part of the sending name (using EXISTS),
checking in local databases for allowed IPs, etc.
--
Ernesto Baschny <ernst(_at_)baschny(_dot_)de>
http://www.baschny.de - PGP: http://www.baschny.de/pgp.txt
Sao Paulo/Brasil - Stuttgart/Germany
Ernst(_at_)IRCnet - ICQ# 2955403