In <403CEA41(_dot_)6608(_dot_)55F55F(_at_)localhost> "Ernesto Baschny"
<ernst(_at_)baschny(_dot_)de> writes:
Meng,
here's a couple of thoughts about Microsoft's proposal which I noticed at
my first tries in writing the cid2spf tool:
[good analysis snipped]
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.
I think you meant '?' instead of '~' here. You got it right in your
cid2spf tool.
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 [...]
[...] , but one might wonder if this is a bad or good
thing.
This was discussed and thought about quite a bit. I'm obviously
biased, but I think the SPF way is better. The MX records (incoming
MTAs) are often not going to be the same as the outgoing MTAs. If,
for some reason, the SPF/C-ID record of an included/indirect domain
goes away, then SPF is failsafe, while C-ID can cause false
rejections. It makes no difference if the record went away
accidentally, or on purpose, or because of a DNS server problem.
Other points:
* SPF's exp= modifier allows a configurable rejection message for MTA
rejects. C-ID doesn't, but then, C-ID is designed to be done in the
MUA rather than the MTA.
* SPF's power allows for possible DoS attacks on either the receiving
MTA, or an unrelated third party. C-ID is much more "obviously
safe" in this regard.
* SPF allows a single record to return any of +, -, ? or ~, depending
on the situation. C-ID can only return +/- or ?.
* C-ID has "hashedPuzzle" and "allETPSigned" mentioned in their XML
schema, but they aren't documented anywhere.
-wayne