Re: Fwd: Re: [spfbis] SPFBIS proposed charter

Hector,

Thoughts interspersed below:

On 12/18/2011 5:37 PM, HECTOR SANTOS wrote:
> 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 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
>

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
> 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?
>

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.