headers
Scott Kitterman | 2 Dec 2011 00:00

Fwd: Re: [spfbis] SPFBIS proposed charter

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 <msk <at> cloudmark.com>
To: spfbis <at> ietf.org <spfbis <at> ietf.org>

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

From: spfbis-bounces <at> ietf.org [mailto:spfbis-bounces <at> ietf.org] On Behalf
Of Murray S. Kucherawy
Sent: Wednesday, November 30, 2011 12:01 PM
To: spfbis <at> 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.
(Continue reading)

Permalink | Reply | 4 comments |
headers
HECTOR SANTOS | 17 Dec 2011 03:40
Favicon

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

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.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Scott Kitterman | 17 Dec 2011 04:06

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

On Friday, December 16, 2011 09:40:14 PM HECTOR SANTOS wrote:
> 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
Permalink | Reply | 2 comments |
headers
HECTOR SANTOS | 17 Dec 2011 07:12
Favicon

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

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Murray S. Kucherawy | 18 Dec 2011 05:24

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

> -----Original Message-----
> From: Scott Kitterman [mailto:spf2 <at> kitterman.com]
> Sent: Friday, December 16, 2011 7:07 PM
> To: spf-discuss <at> listbox.com
> 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
Permalink | Reply | 0 comments |
headers
HECTOR SANTOS | 18 Dec 2011 15:29
Favicon

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

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)

Murray S. Kucherawy wrote:

> 
>> -----Original Message-----
>> From: Scott Kitterman [mailto:spf2 <at> kitterman.com]
>> Sent: Friday, December 16, 2011 7:07 PM
>> To: spf-discuss <at> listbox.com
(Continue reading)

Permalink | Reply | 8 comments |
headers
Brian G. Peterson | 18 Dec 2011 18:25
Gravatar

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

On Sun, 2011-12-18 at 09:29 -0500, HECTOR SANTOS wrote:
> 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.

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
(Continue reading)

Permalink | Reply | 7 comments |
headers
Commerco WebMaster | 19 Dec 2011 00:36

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

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.

On 12/18/2011 10:25 AM, Brian G. Peterson wrote:
> On Sun, 2011-12-18 at 09:29 -0500, HECTOR SANTOS wrote:
>> 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.
>>
(Continue reading)

Permalink | Reply | 6 comments |
headers
HECTOR SANTOS | 19 Dec 2011 01:37
Favicon

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

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.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Commerco WebMaster | 19 Dec 2011 06:39

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
(Continue reading)

Permalink | Reply | 4 comments |

Gmane