-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com] On Behalf Of
jpinkerton
Sent: dinsdag 7 december 2004 8:28
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: Re: [spf-discuss] Agenda item: SenderID Position Statement
As I said - we must associate with all other technologies
equally, and it's *really* important to *not* point out their faults.
Having said that - I like MarkK's idea of a document with all the
technical info on "gotchas" in using spf records, which would have
to be written *very* even-handedly.
I dunno. Certainly Sendmail's whitepaper didn't treat all
technologies equally, nor did they shy away from pointing
out faults. Same goes for Meng's whitepaper (although it certainly
covers many more proposals). I don't think that is the point of
such statements.
Fair comment, but if we are going to be leaders in this
field, let us be the ones to set the standard of such documents.
There is no reason to not write something up regarding the other usages
of SPF records and keep it even-handed and friendly to all other
anti-spam technologies.
I do not believe we are under requirement to treat all other proposed
technologies equally. But, to me, there is a difference between a
positional paper like "Why SenderID is bad" and simply showing forth, as
part of our own SPF documentation, that, when SPF records are used for a
particular purpose, it will lead to problems/unexpected behavior.
The response of the SPF community to the "sendmail" whitepaper is still
due, I think, regardless of what else we do. I'm sure this will soon crop
up in a council gathering. :) In fact, I will ask the chair to put it on
the agenda.
- Mark
System Administrator Asarian-host.org
---
"If you were supposed to understand it,
we wouldn't call it code." - FedEx