[spfbis] SPFBIS proposed charter

[Scott Kitterman]

FYI. Anyone who's interested in working on updating SPF should really
be subscribed to the SPFbis mailing list. Since decisions are going to
be made by rough consensus of the people on that list, it would be good
to have more people with a history of involvement in SPF there.

Scott K

-------- Original Message --------
Subject: Re: [spfbis] SPFBIS proposed charter
Date: Wed, 30 Nov 2011 12:06:58 -0800
From: Murray S. Kucherawy <***@cloudmark.com>
To: ***@ietf.org <***@ietf.org>

Sorry I'm new to this whole email thing, and I failed to attach it.
It's attached here.


From: spfbis-***@ietf.org [mailto:spfbis-***@ietf.org] On Behalf
Of Murray S. Kucherawy
Sent: Wednesday, November 30, 2011 12:01 PM
To: ***@ietf.org
Subject: [spfbis] SPFBIS proposed charter

Hello all, and welcome to the SPFbis mailing list.

As usual, our first order of business is to hash out a charter for the
working group. Many of you have already seen it privately, and it was
circulated and discussed briefly within the APPS area working group
session in Taipei and its mailing list. Attached is the latest version,
a product of all of the above.

So the usual questions:


- Does this charter capture an accurate description of the
problem to be solved (in our case, it's really the work to be done)?

- Is the charter appropriately broad and/or limited in scope?

- Who is willing to review and comment on documents in the
working group?

- Who is willing to act as document editor(s)?

- Who is likely to implement (or, since SPF is already out
there, who is likely to update their implementations to match any
changes in the specs) and participate in interoperability testing?

- Who is willing to co-chair a working group?

I'll put down my answers as: I agree with the current charter in terms
of its goals and scope, and I also volunteer to review and/or edit
documents, or act as a co-chair.

Our responses to this will be feedback to the APPS area directors as to
whether or not there's enough interest to warrant a BoF in Paris, or
even to skip that step and just charter the working group.

Thanks,
-MSK

[HECTOR SANTOS]

This effort definitely needs a co-chair the counteract any ill
direction this may take.I already see a security problem with the is
proposed scope extension for the same reasons that any payload
technology, i.e, Sender-ID, had - forcing high overhead on receivers
to receive the DATA payload. We been through these conflicts already
and SenderID was forced to introduce the SMTP-level SUBMITTER protocol
to help pre-empt and resolve this critical payload acception conflict.
This issue CAN NOT, MUST NOT and WILL NOT be ignored. That along is
enough to ignore this effort.

In short, the MAIL-FROM must be SPF verified first before any
additional scope processing can be done.

MAIL FROM: SCOPE TAG, IF ANY (SPFBIS proposal)

FAIL don't bother

PASS check if available

SOFT This is always the case that we had, and why other
email authentication was considered to help the
indeterminate state.

Here is a heads up:

If this SPFBIS extended scope tag idea attempts to tell SPF receivers
to bypass the MAIL FROM (or HELO/EHLO check), then we have a serious
APPEAL level security problem with this SPFBIS effort. It would NO
LONGER be SPF - but a different protocol altogether.

Post by Scott Kitterman
FYI. Anyone who's interested in working on updating SPF should really
be subscribed to the SPFbis mailing list. Since decisions are going to
be made by rough consensus of the people on that list, it would be good
to have more people with a history of involvement in SPF there.
Scott K
-------- Original Message --------
Subject: Re: [spfbis] SPFBIS proposed charter
Date: Wed, 30 Nov 2011 12:06:58 -0800
Sorry I'm new to this whole email thing, and I failed to attach it.
It's attached here.
Of Murray S. Kucherawy
Sent: Wednesday, November 30, 2011 12:01 PM
Subject: [spfbis] SPFBIS proposed charter
Hello all, and welcome to the SPFbis mailing list.
As usual, our first order of business is to hash out a charter for the
working group. Many of you have already seen it privately, and it was
circulated and discussed briefly within the APPS area working group
session in Taipei and its mailing list. Attached is the latest version,
a product of all of the above.
- Does this charter capture an accurate description of the
problem to be solved (in our case, it's really the work to be done)?
- Is the charter appropriately broad and/or limited in scope?
- Who is willing to review and comment on documents in the
working group?
- Who is willing to act as document editor(s)?
- Who is likely to implement (or, since SPF is already out
there, who is likely to update their implementations to match any
changes in the specs) and participate in interoperability testing?
- Who is willing to co-chair a working group?
I'll put down my answers as: I agree with the current charter in terms
of its goals and scope, and I also volunteer to review and/or edit
documents, or act as a co-chair.
Our responses to this will be feedback to the APPS area directors as to
whether or not there's enough interest to warrant a BoF in Paris, or
even to skip that step and just charter the working group.
Thanks,
-MSK

[Scott Kitterman]

Post by HECTOR SANTOS
This effort definitely needs a co-chair the counteract any ill
direction this may take.I already see a security problem with the is
proposed scope extension for the same reasons that any payload
technology, i.e, Sender-ID, had - forcing high overhead on receivers
to receive the DATA payload.

Think if it the other way around. Think of it as an additional tool that's
avaialable if you decide to receive DATA. It's not meant to force anything.


Scott K

[HECTOR SANTOS]

Scott,

That's the point. Knowing how things will be ram, molded in such a WG
with the principals involved, it isn't an option if one say its
supports SPF-BIS. IOW, there will be those who will say you are not
compliant if you don't support the new scope stuff. That is not BIS work.

This is all DEJA-VU. We been threw this before with the SPF vs
SENDER-ID issues and expecting new technologies to be more RFC5322
related. Its why we once considered a HEAD proposal for these type of
needs:

http://www.isdg.net/public/ietf/drafts/draft-santos-smtphead-00.html

There will be problems with this SPFBIS with this scope introduction.
You can not do this with the current widely adopted and implemented
SPF protocol. For what purpose? To stop the SMTP level lookup?
Change its direction? If so, thats a different protocol. People will
get confused if they begin to focus on using a scope believing thats
how SPF receivers will work - i.e. they won't expect they mail failing
at the return path check by current SPF implementations or those that
CHOICE to not support the SPFBIS because of compliance workings most
likely to be injected in there. This can only work if and only if, as
I stated in the previous message the MAIL FROM check is not preempted.
It has to work with a SOFT result or even FAIL, otherwise SPFBIS will
introduce all sorts of security problems or erroneous expectations.
But the new people focus on the scope, and don't get the normal return
path setup right - PROBLEMS! For sure!

SPF is simple. Straight forward - its an SMTP level lookup independent
of the payload.

In addition, whats wrong with using the SUBMITTER keyword? That is
the WHOLE purpose of it - to pass the DOMAIN to the SMTP transport to
avoid having to transmit the payload.

Lets not screw it up please. This is not BIS work if it proposes new
stuff that will most definitely create two different sets of mindset.
--
HLS

Post by Scott Kitterman

Post by HECTOR SANTOS
This effort definitely needs a co-chair the counteract any ill
direction this may take.I already see a security problem with the is
proposed scope extension for the same reasons that any payload
technology, i.e, Sender-ID, had - forcing high overhead on receivers
to receive the DATA payload.

Think if it the other way around. Think of it as an additional tool that's
avaialable if you decide to receive DATA. It's not meant to force anything.
Scott K

[Murray S. Kucherawy]

-----Original Message-----
Sent: Friday, December 16, 2011 7:07 PM
Subject: Re: [spf-discuss] Fwd: Re: [spfbis] SPFBIS proposed charter
Think if it the other way around. Think of it as an additional tool
that's avaialable if you decide to receive DATA. It's not meant to
force anything.

Right. Nobody's changing SPF itself. In fact, the charter makes it perfectly clear that we're not to do that at all, except to remove unused stuff or to apply changes or errata that have already been widely deployed.

Any extensions are (by the very nature of something called an "extension") completely optional at both ends. If you don't want to implement it, don't.

-MSK

[HECTOR SANTOS]

Thats fine, and yes Extension are Extensions when mean OPTIONAL. So
anything new added to the RFC bis, MUST NOT be rammed it down people's
throat using odd readings of RFC 2119. In other words, people are
still compliant with SPF and SPF BIS while completely ignoring this
ILLEGAL CROSS BOUNDARY scope extension. I don't want to see
statements like you made recently such as:

"Put another way, you can't claim compliance with this document
unless you apply the SHOULD, but extant implementations are
otherwise completely unaffected.

IOW, you CAN NOT make this cross boundary scope extension a SHOULD for
SPFBIS if you truly believe what you stated. If you feel
differently, then this not BIS work but a new protocol and new mandate
for a new version of SPF - a different protocol.
--
Hector, Engineering & Technical Support
Santronics Software, Inc.
http://www.santronics.com (sales)
http://www.winserver.com (support)
http://www.winserver.com/AupInfo (Online AUP Help)

-----Original Message-----
Sent: Friday, December 16, 2011 7:07 PM
Subject: Re: [spf-discuss] Fwd: Re: [spfbis] SPFBIS proposed charter
=20
Think if it the other way around. Think of it as an additional tool
that's avaialable if you decide to receive DATA. It's not meant to
force anything.

Right. Nobody's changing SPF itself. In fact, the charter makes it perfec=
tly clear that we're not to do that at all, except to remove unused stuff o=
r to apply changes or errata that have already been widely deployed.
Any extensions are (by the very nature of something called an "extension") =
completely optional at both ends. If you don't want to implement it, don't.
-MSK
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbo=
x.com/member/]
Archives: https://www.listbox.com/member/archive/735/=3Dnow
RSS Feed: https://www.listbox.com/member/archive/rss/735/993478-34c23837
Modify Your Subscription: https://www.listbox.com/member/?D99347=
8&D993478-798244e6
Unsubscribe Now: https://www.listbox.com/unsubscribe/?D993478&id=
_secret=3D993478-3e6ef724&post_id=3D20111217232443:34B82E4E-2930-11E1-A93B-=
DF76EFF22AC7
Powered by Listbox: http://www.listbox.com

[Brian G. Peterson]

Post by HECTOR SANTOS
Thats fine, and yes Extension are Extensions when mean OPTIONAL. So
anything new added to the RFC bis, MUST NOT be rammed it down people's
throat using odd readings of RFC 2119. In other words, people are
still compliant with SPF and SPF BIS while completely ignoring this
ILLEGAL CROSS BOUNDARY scope extension. I don't want to see
"Put another way, you can't claim compliance with this document
unless you apply the SHOULD, but extant implementations are
otherwise completely unaffected.
IOW, you CAN NOT make this cross boundary scope extension a SHOULD for
SPFBIS if you truly believe what you stated. If you feel
differently, then this not BIS work but a new protocol and new mandate
for a new version of SPF - a different protocol.

I'm not taking sides here, since I am not really familiar with the
technical details anymore, but a implementation is compliant if it meets
all of the MUST directives.

SHOULD directives have always been strong recommendations, but in no
standards process that I have ever been associated with (and there have
been many) have the *recommendations* in SHOULD directives been required
for compliance. You may not have as broad of interoperability as you
would like without implementing SHOULD directives, but that doesn't mean
you are non-compliant.

Now, I would suggest from plain meaning of the word 'Extension' that no
extension would ever be required for standards compliance. MUST and
SHOULD directives could still be applied within each extension method to
make the *extensions* compliant and inter-operable with each other.

Cheers,

- Brian

[Commerco WebMaster]

Brian,

Excellent point. MUST defines the absolute minimum criteria for
compliance with an RFC. SHOULD often defines best practice additions
which extend an RFC.

As the charter of this RFC bis, as I understand it, is not to add any
functionality (required as MUST or otherwise) to the existing draft
specification from which the bis shall become based, the argument over
extension compliance for this process seems moot.

If there is a desire to add functionality to the specification as a
requirement to implementation (a MUST case) then perhaps that is for a
V3 or V4 SPF task force to hash out.

Alan M.

Post by Brian G. Peterson

Post by HECTOR SANTOS
Thats fine, and yes Extension are Extensions when mean OPTIONAL. So
anything new added to the RFC bis, MUST NOT be rammed it down people's
throat using odd readings of RFC 2119. In other words, people are
still compliant with SPF and SPF BIS while completely ignoring this
ILLEGAL CROSS BOUNDARY scope extension. I don't want to see
"Put another way, you can't claim compliance with this document
unless you apply the SHOULD, but extant implementations are
otherwise completely unaffected.
IOW, you CAN NOT make this cross boundary scope extension a SHOULD for
SPFBIS if you truly believe what you stated. If you feel
differently, then this not BIS work but a new protocol and new mandate
for a new version of SPF - a different protocol.

I'm not taking sides here, since I am not really familiar with the
technical details anymore, but a implementation is compliant if it meets
all of the MUST directives.
SHOULD directives have always been strong recommendations, but in no
standards process that I have ever been associated with (and there have
been many) have the *recommendations* in SHOULD directives been required
for compliance. You may not have as broad of interoperability as you
would like without implementing SHOULD directives, but that doesn't mean
you are non-compliant.
Now, I would suggest from plain meaning of the word 'Extension' that no
extension would ever be required for standards compliance. MUST and
SHOULD directives could still be applied within each extension method to
make the *extensions* compliant and inter-operable with each other.
Cheers,
- Brian

[HECTOR SANTOS]

First, the proposed charter has contradictions, like making out of
scope the old MARID SPF vs SENDER-ID debates which is 100% pertinent
to the idea of whether this scope extension is a good idea or not. No
way to have a legitimate engineering WG debate without highlighting
the fact that the same reason to reject it will be the same reasons
SENDER-ID was required to be a separate protocol. Simply put, SPF is
not a PAYLOAD technology, SENDER-ID is a PAYLOAD technology and the
"twine shall never meet." Introducing this scope in SPF violates the
boundary layers.

Second, I don't pay attention to what that charter says (especially
when written by this person, which I don't mind saying I have a hard
time agreeing with his engineering thinking often especially when it
comes to PRODUCT R&D) but how would the proposed extension by applied
with 100% compatibility without FORCING it down people's throat.

1) SPF receivers are NOT REQUIRED to ADD/OR enable the scope extension,

2) Administrators adding a scope to their 5321.From domain that
includes a scope:

a) MUST NOT attempt to force preemption of the 5321.From check,
b) MUST NOT assume receivers will support or honor the scope
information,
c) SPF receivers MAY honor the scope extension,
d) SPF receivers MAY skip the 5321.From check

Regardless of what the charter says, this is the only way it can be
implemented without harming current operations.

The design issue will be how to best leverage this scope extension the
proper way which means under what the SPF boundary conditions available:

NONE n/a
PASS Is scope used as a double check?
SOFTFAIL Seems more applicable here.
FAIL Should scope override 5321 level SPF "HARD" failure?

Thanks
--
Hector, Engineering & Technical Support
Santronics Software, Inc.
http://www.santronics.com (sales)
http://www.winserver.com (support)
http://www.winserver.com/AupInfo (Online AUP Help)

Post by Commerco WebMaster
Brian,
Excellent point. MUST defines the absolute minimum criteria for
compliance with an RFC. SHOULD often defines best practice additions
which extend an RFC.
As the charter of this RFC bis, as I understand it, is not to add any
functionality (required as MUST or otherwise) to the existing draft
specification from which the bis shall become based, the argument over
extension compliance for this process seems moot.
If there is a desire to add functionality to the specification as a
requirement to implementation (a MUST case) then perhaps that is for a
V3 or V4 SPF task force to hash out.
Alan M.

Post by Brian G. Peterson

Post by HECTOR SANTOS
Thats fine, and yes Extension are Extensions when mean OPTIONAL. So
anything new added to the RFC bis, MUST NOT be rammed it down people's
throat using odd readings of RFC 2119. In other words, people are
still compliant with SPF and SPF BIS while completely ignoring this
ILLEGAL CROSS BOUNDARY scope extension. I don't want to see
"Put another way, you can't claim compliance with this document
unless you apply the SHOULD, but extant implementations are
otherwise completely unaffected.
IOW, you CAN NOT make this cross boundary scope extension a SHOULD for
SPFBIS if you truly believe what you stated. If you feel
differently, then this not BIS work but a new protocol and new mandate
for a new version of SPF - a different protocol.

I'm not taking sides here, since I am not really familiar with the
technical details anymore, but a implementation is compliant if it meets
all of the MUST directives.
SHOULD directives have always been strong recommendations, but in no
standards process that I have ever been associated with (and there have
been many) have the *recommendations* in SHOULD directives been required
for compliance. You may not have as broad of interoperability as you
would like without implementing SHOULD directives, but that doesn't mean
you are non-compliant.
Now, I would suggest from plain meaning of the word 'Extension' that no
extension would ever be required for standards compliance. MUST and
SHOULD directives could still be applied within each extension method to
make the *extensions* compliant and inter-operable with each other.
Cheers,
- Brian

-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/
[http://www.listbox.com/member/]
Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/993478-34c23837
https://www.listbox.com/member/?&
https://www.listbox.com/unsubscribe/?&&post_id=20111218183619:14698A1A-29D1-11E1-B863-E166C5ACC682
Powered by Listbox: http://www.listbox.com

[Commerco WebMaster]

Hector,

First, the proposed charter has contradictions, like making out of scope
the old MARID SPF vs SENDER-ID debates which is 100% pertinent to the
idea of whether this scope extension is a good idea or not. No way to
have a legitimate engineering WG debate without highlighting the fact
that the same reason to reject it will be the same reasons SENDER-ID was
required to be a separate protocol. Simply put, SPF is not a PAYLOAD
technology, SENDER-ID is a PAYLOAD technology and the "twine shall never
meet." Introducing this scope in SPF violates the boundary layers.

I was of the impression reading the out of scope remark as being a
decision to avoid discussion of the SENDER-ID fork of SPF, which has
some show stopping issues that arguably stunted its implementation in
favor of the MARID SPF draft. MARID SPF was pretty clean and easy
enough to implement as a publishing adopter. I would guess is the way
most adopters implemented SPF (MARID not SENDER-ID). I would think the
SENDER-ID proponents and supporters may have gone to DKIM, if they found
SPF V1 alone inadequate for their needs.

As I remember, the entire stated goal of SPF V1 was simply to disallow
people from misusing the domain names of other people who hold the names
via such activities as SPAM. SPF has been doing that successfully for
many publishers for quite a few years now.

Second, I don't pay attention to what that charter says (especially when
written by this person, which I don't mind saying I have a hard time
agreeing with his engineering thinking often especially when it comes to
PRODUCT R&D) but how would the proposed extension by applied with 100%
compatibility without FORCING it down people's throat.

I think you are in agreement with the thoughts that Brian Peterson
offered regarding MUST vs SHOULD RFC arguments.

1) SPF receivers are NOT REQUIRED to ADD/OR enable the scope extension,

Reasonable, as it goes back to keeping the integrity of what I think
that SPF V1 was all about.

2) Administrators adding a scope to their 5321.From domain that includes
a) MUST NOT attempt to force preemption of the 5321.From check,
b) MUST NOT assume receivers will support or honor the scope information,
c) SPF receivers MAY honor the scope extension,
d) SPF receivers MAY skip the 5321.From check

That sounds right too. Arguably, to implement the additional scope
components, one would need some sort of feedback from the receiver to
indicate its level of support and I don't think there is such a way to
do that clearly within the existing SPF V1 implementation draft.

Regardless of what the charter says, this is the only way it can be
implemented without harming current operations.

Again, here is where you lose me, I do not see what you are seeing.
Perhaps it is me being thick headed, but is not the purpose of SPF bis
to formalize the MARID SPF RFC draft into a standard RFC for SPF V1? If
that is the case, then I'm not clear what the issue really is.

The design issue will be how to best leverage this scope extension the
NONE n/a
PASS Is scope used as a double check?
SOFTFAIL Seems more applicable here.
FAIL Should scope override 5321 level SPF "HARD" failure?

Again, perhaps an SPF V3 draft issue, but why not have a RFC5312FAIL to
more specifically indicate what is failing in implementations which
choose to support 5321, rather than use the existing and defined SPF
SOFTFAIL response?

Thanks

Alan M.

[Murray S. Kucherawy]

-----Original Message-----
Sent: Sunday, December 18, 2011 9:39 PM
Cc: HECTOR SANTOS
Subject: Re: [spf-discuss] Fwd: Re: [spfbis] SPFBIS proposed charter
I was of the impression reading the out of scope remark as being a
decision to avoid discussion of the SENDER-ID fork of SPF, which has
some show stopping issues that arguably stunted its implementation in
favor of the MARID SPF draft.

Correct. We are specifically and deliberately proscribing the reopening of those old debates with respect to SPFbis itself. They serve no useful purpose here.

I would think the
SENDER-ID proponents and supporters may have gone to DKIM, if they
found SPF V1 alone inadequate for their needs.

There are undoubtedly people that still believe Sender-ID is the way to go. There's nothing stopping them from implementing it.

The fact is, however, that SPF has seen enough widespread implementation to warrant advancement to and along the Standards Track, so that's what we're doing. It really is as simple as that.

As you've seen, there are always the grandiloquent among us that don't or won't believe such statements. It's their prerogative to do so, but we shouldn't let them get in the way.

A substantial number of people behind this effort have no skin in the game in terms of the old MARID debates. For example, I'm not even an active SPF proponent (I prefer DKIM) and I wasn't part of MARID, but I'm helping to advance this work because there's a need to encourage convergence on a single, standard protocol in terms of path authorization, and there are some things that want to build on it, but having SPF at Experimental is sometimes an issue. So it really is time for this to happen. I'm willing to put the work in, and circulating the charter is a call for consensus and for the like-minded to pitch in.

I think you are in agreement with the thoughts that Brian Peterson
offered regarding MUST vs SHOULD RFC arguments.

I believe RFC2119 defines MUST and SHOULD adequately, and I'll leave it at that.

Post by HECTOR SANTOS
1) SPF receivers are NOT REQUIRED to ADD/OR enable the scope
extension,

Reasonable, as it goes back to keeping the integrity of what I think
that SPF V1 was all about.

Right. Moreover, I believe that falls within the definition of "extension". Establishing such a requirement in the base document about an extension means a new version of the protocol, and that's not what we're doing here. And that would mean the extension isn't really an extension anymore. And the charter says clearly that major changes can't be made to the base specification itself, so the claimed contradiction doesn't exist.

Again, here is where you lose me, I do not see what you are seeing.
Perhaps it is me being thick headed, but is not the purpose of SPF bis
to formalize the MARID SPF RFC draft into a standard RFC for SPF V1?
If that is the case, then I'm not clear what the issue really is.

Ditto.

-MSK


-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]
Modify Your Subscription: http://www.listbox.com/member/ [http://www.listbox.com/member/]

Archives: https://www.listbox.com/member/archive/735/=now
RSS Feed: https://www.listbox.com/member/archive/rss/735/6959934-50ec8f89
Modify Your Subscription: https://www.listbox.com/member/?member_id=6959934&id_secret=6959934-b7c4528d
Unsubscribe Now: https://www.listbox.com/unsubscribe/?member_id=6959934&id_secret=6959934-edadf31a&post_id=20111219020016:19075E56-2A0F-11E1-AD62-CC00FFE1F442
Powered by Listbox: http://www.listbo

[Tim Draegen]

Post by Murray S. Kucherawy
A substantial number of people behind this effort have no skin in the game in terms of the old MARID debates. For example, I'm not even an active SPF proponent (I prefer DKIM) and I wasn't part of MARID, but I'm helping to advance this work because there's a need to encourage convergence on a single, standard protocol in terms of path authorization, and there are some things that want to build on it, but having SPF at Experimental is sometimes an issue. So it really is time for this to happen. I'm willing to put the work in, and circulating the charter is a call for consensus and for the like-minded to pitch in.

I'm in this boat, here, although I am an active SPF proponent.

Ready to pitch in; no issues with the clarity or scope of the charter!

-= Tim

[Stuart D Gathman]

Long ago, Nostradamus foresaw that on 12/20/2011 12:35 PM, Tim Draegen

Post by Tim Draegen
I'm in this boat, here, although I am an active SPF proponent.
Ready to pitch in; no issues with the clarity or scope of the charter!
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]

Is there anyway to change to website links to openspf.net ? Still no
word from the owner of the (now defunct) openspf.org domain.

[Scott Kitterman]

Post by Stuart D Gathman
Long ago, Nostradamus foresaw that on 12/20/2011 12:35 PM, Tim Draegen

Post by Tim Draegen
I'm in this boat, here, although I am an active SPF proponent.
Ready to pitch in; no issues with the clarity or scope of the charter!
-------------------------------------------
Sender Policy Framework: http://www.openspf.org [http://www.openspf.org]

Is there anyway to change to website links to openspf.net ? Still no
word from the owner of the (now defunct) openspf.org domain.

I believe I've fixed it. I'll find out for sure when I read this message.

Scott K