In
<C6DDA43B91BFDA49AA2F1E473732113E5DBADE(_at_)mou1wnexm05(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
Just because we are engineers does not mean that Marketing is not
going to be critically important for our success. Don't knock
marketting, it is a very valuable asset.
Argh. I didn't say that Marketing wasn't important, I said that SPF
didn't gain it's current popularity by marketing. Working code more
than just helps, it enabled marketing to be done. No one involved
with SPF could pull off what has been done with Caller-ID and
DomainKeys and get so much attention without being able to show
working code.
This is why I would really like it if we could work a way round to
call whatever end up with either SPF or Caller-Id. The CallerID
name is an amazingly good piece of communication, [...]
Caller-ID is, indeed, a very good name. Unfortunately, I now know of
at least three companies that have used it, and the trademark isn't
owned by MicroSoft. I suspect that Caller-ID is out.
We realized that people would publish SPF records, just to make a
public statement by the domain owners that they want to protect their
brand names and good reputation. This has benefits even if few people
are actually checking the SPF records.
Actually there seem to be quite a few people checking now.
Yep, there are, and as I said, the number of emails being checked is
doubling every 2-3 weeks since last December.
With this in mind, we was decided that we needed to pay *very* close
attention to making it as easy as possible for people to publish SPF
records, and for those SPF records to require minimal maintenance.
Hence the creation of the 'mx', 'ptr' and 'include' mechanisms, and
the "SPF wizards" web pages which help people create SPF records.
And that was the right design choice for SPF given that it did not have
the IETF imprimatur behind it.
I still think it is the right design choice.
But that is not the right strategy for MARID. The constituency we
talk to is much more likely to believe that less is more. The principle
that we should avoid situations where we end up with inconsistent
configurations is a good one, but that should still be possible within
a minimalist approach.
I'm not sure what 'constituency' you are referring to or why anything
will have changed. The domain owners and mail admins are still the
people who will have to actually make the changes and it is the email
users who will inform the domain owners/mail admins if they made a
stupid change. (Email users quite possibly will inform domain
owners/mail admins of their opinions via their wallet.)
-wayne