IETF had real problem is that it did not wish to deal with how their
protocols would be deployed. This is the main reason of failures of
number
of protocols that have been created and why others are less used then
they could be. Certain conclusion must (and have) been drawn out of
this
and it would be unfortunete if we choose to go the same road again.
IMHO, the largest deployment hurdle will be to get 63 million of
domain owners (growing at 1.5 million per month) to publish and
maintain a DNS record. (See my post at spf-discuss for source).
Presenting these non-technical people with the complexity of choosing
which scope their approved mail servers will be used and other complex
options we might provide them, seems to run counter to the 80/20 rule
for deployment.
A very small minority of those domains will do the actual publishing
themselves. They will rely on their vendors to publish for them and to
exchange the necessary information.
Yes and no.
Agreed for the majority of domains that do publish, and this is precisely what
worries me. Then you have 3rd parties (not the ones sending the e-mail) making
decisions and assumptions for the actual users, and thus:
1. More likelihood of a war on scope where some camps refuse to declare
"mailfrom" or "spf", because they have a vested interest to declare only "pra"
or vice versa.
2. More likelihood that the actual users voilate the rules in the DNS record,
because the user has no concept they exist or what they mean.
3. Thus because of the two scenarios above and because recipients could care
less about the sender's woes, you will have adhoc algorithms sprouting about to
deal with the fragmented reality that results.
And no, disagree, that the majority of domains will publish records, especially
if there is no concensus, much complexity and confusion about scoping, useage,
confusing press statements (lack of concensus and simplicity), etc..
The average domain owner does not know what DNS is and if they do, they
have no idea who manages DNS for them. The record update problem is
serious and needs to be addressed within the industry, but the end user
education needs to take the form of telling people that (a) this exists
and (b) who to call.
What exists? How do we explain it to them if the underlying standard is
confused and fragmented? We are already seeing confusing press statements
about SPF that say spammers are using it.
We are much better off to get a simple concensus, than a complex fragmented
mess. In the latter scenario, Microsoft will "save the day" by being the
unified, de facto choice. Just observe history.
[...]
The assumption that small domains all have simple configurations is
just not valid. It's probably true for small personal domains, and
small technical domains, but those are not the majority.
What is your point of saying this? You mean we can not provide a simple way to
specify the approved mail servers? You mean that we can never make it simple
enough to explain to users?
Failure to scope will make it harder, not easier, for small domains, if
for no other reason than figuring out what a rational receiver is
likely to do with the record will be that much harder for whoever is
doing the domain administration.
Can you tell me today the differences between the way AccuSpam, SpamAssassin,
CloudMark, and a zillion other anti-spam are going to interpret the SPF or
SenderID DNS record??
I assert that specifying scope is nothing more than a hopeful hint. In
reality, the only the scope is specified by what data you are actually exposing.
This is currently a very low cost
service - do we want to make it expensive?
How does not specifying scope make it more expensive?
I think specifying scope and having multiple records is going to make it much
more expensive for both maintainers, receivers (verifiers), and also in terms
of fragmentation and proprietary wars.