On Sun, Jan 21, 2007 at 09:18:36PM +0000, Julian Mehnle wrote:
What about the blue color?
I already said: "Apart from that"... IOW the color is fine with me.
If you want to change it anyway: make it brighter please.
For an indefinite amount of time; until the software changes or until
the SPF council revokes the license.
Assuming there isn't a new test suite release... I think once the imple-
mentation passes the current test suite, they should be able to keep using
the logo even with new implementation releases -- until the implementation
is found to no longer pass the test suite. We don't want to tie up the
council or the implementation makers with continuously re-certifying new
implementation releases.
I see your point, you see mine. I agree that not every minor change
should automatically lead to retesting (hence my "within reason").
How about this:
---cut here---
Applicants for a license need to be able to be reached by electronic
mail. It is the applicant's responsibility to monitor this email address
and to inform the council of any changes. Sending an email to the
registered email address is sufficient to revoke a license, unless
delivery problems are clearly out of the applicant's control.
(choosing the wrong provider, having a too tight spam filter, and so on
is not sufficent "out of the applicant's control" !)
[note: perhaps a monthly verification email, which not only allows the
council to notice delivery problems but also allows the applicant to
do the same]
An applicant may stop using the logo and return the license. This also
stops above responsibility.
Should a new test suite be released, the SPF council may -at it's own
discretion- revoke licenses. The council will do so if there's reasonable
justification, e.g. when a bug was found in the previous release, one which
would allow non-conformant implementations to pass the test suite.
The applicant is responsible for staying conformant, even after bug fixes
in their software. If there's reason for doubt, the applicant will signal
the council and the license is revoked. In general, the applicant should
only do this when changes in his software may have impacted the implementation's
conformance (i.e. do not resubmit if you changed the help file).
In case of bad judgement from the applicant, the council may invite
the applicant to discuss his motives on spf-discuss or a more private
channel (at the sole discretion of the SPF council). This could happen
if too many changes are reported, or too few (in which case the software
is no longer conformant after a major change). The track record of the
applicant will decide if a new license is granted.
Once a license is revoked, a timer is started. The applicant will have
to respond within a week (604800 seconds) to avoid being listed on the
"license revoked" page. A retest must be passed within two weeks after
the timer was started (1209600 seconds).
---cut here---
We do not want a situation where products are significantly altered
(e.g. suddenly becomes SID software), and no incentive exists to report
such a change to the council.
Why would someone voluntarily report a major change if they can sit
back and relax? Answer: they generally won't, unless they know it
may hurt their future chances of getting a license.
Of course, any implementation that applies SPF (v1) records to the email
body is bogus and should not receive the approval, no matter what the
outcome of testing it against a test suite is. Such an implementation
is not 4408 compliant!
This is an important point. Note that an RFC 4406/7 compliant implemen-
tation wouldn't strictly violate RFC 4408 because the latter only says
"NOT RECOMMENDED" in 2.4/2. What do others think?
OK, a test for the test suite then:
helo domain1.example.com
mail from:<user(_at_)domain1(_dot_)example(_dot_)com>
...
DATA
From: "Joe A. User" <user(_at_)example(_dot_)com>
...
with SPF records:
domain1.example.com. TXT "v=spf1 +all"
example.com. TXT "v=spf1 -all"
If this is rejected "due to SPF", then IMHO: no license.
If rejecting this mail due to SPF _is_ SPFv1 compliant, I wish to
decline my nomination for the council.
Alex
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735