I
On Jun 16, 2004, at 2:39 AM, Jim Lyon wrote:
I think that Greg has done an excellent write-up of the positions.
Position 1 was originally taken by Microsoft Caller ID.
Position 2 was originally taken by SPF.
I see position 3 as the best of both worlds, and heartily support it.
I see position 4 as the worst of both worlds.
I believe that "syntax" extensibility will be crucial in the future.
I believe that "feature" extensibility has a positive but small value,
but probably isn't worth the cost.
I see authenticating a domain as fairly well understood at this point,
but the necessary additional services are just beginning to emerge. You
need to tie the reputation and accreditation to the authentication, and
we may find that it's crucial to do so in the MARID record. Reputation
and accreditation are new and poorly understood areas, so I would not
credit anyone's crystal ball on what will be required. Given that, I
think syntax extensibility is critical and that the possibility of
feature extensibility is also critical, with the caveat that the
feature extensibility must be backwards compatible, an exercise that by
definition has to be left to the designers of the new feature. With
syntax extensibility you can in theory get some backwards compatible
semantic extensibility.
So like Jim, I heartily support position 3, which I would define as
backwards compatibility for the existing SPF syntax. I'll observe that
SenderID has a feature extension (SUBMITTER, the PRD algorithm) over
SPF.
Many thanks to Greg for taking the time to write up the positions.
Margaret.
(I have not read the current draft closely enough to understand how
publishing domains express their wish to be treated as SPF v1 or
SenderID so I have held off on commenting on how well I think that will
work.)