Greg Connor wrote:
--wayne <wayne(_at_)midwestcs(_dot_)com> wrote:
Unfortunately, this merger has caused deep divisions in the SPF
community. Meng had previously run things pretty much by rough
consensus. When the XML issue last came up, it was rejected, pretty
much the way it has been rejected this time.
You are right. I imagined that people would have an emotional reaction
to XML. I did. What I was surprised by is the number of people willing
to act on their emotional reaction to it. But, it's a factor we have to
consider.
The reaction to XML is not an emotional reaction per-se. If there were
not so many solid technical reasons for excluding XML from pre-DATA
authentication (bandwidth and parser overhead primarily) I would not
object to it. XML is mother beautiful in the right context. Pre-DATA
SMTP source validation and DNS is not that context.
Personally, I have at least as many problems with the "caller-id
algorithm" to select the domain to check. It is rapidly changing, and
untested. It will require changes to most MUAs to correctly display
the verified address before it will become useful. It doesn't stop
bounces until after the "flag day". From what I know, the C-ID
algorithm breaks around 20% of the mailing lists, where-as SPF breaks
none.
The PRA algorithm is a more fundamental change than XML. But, I think
based on my experience here, and in SPAM-L and MARID, it is still
possible to get what most domain owners want out of the new selection
method.
PRA means that the new protocol is NOT pre-DATA source validation.
Therefore, the new protocol is NOT a replacement for SPFv1, however
beautiful and effective it may be, and whatever the people who
hashed it out might think.
In other words, not operating on any message headers is seen as a defect
in SPF, and not operating on the envelope info is seen as a defect in
CID. I am willing to consent to groveling through DATA headers, in
order to get the best of both worlds, provided there is a coherent
strategy for getting 2821 MAIL FROM rejections as a logical next step.
I think it's a good thing. If it turns out to not be a better thing
than SPF+SRS, then we still have the option of rolling out SPF+SRS.
I would say that what the NP does is necessary, but it does not
provide the advantages of SPF, and does not replace SPF.
I say, WE NEED something like the proposed protocol. The discussion
for the new protocol SHOULD CONTINUE, but it DOES NOT replace SPF.