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

Scott Kitterman wrote:
> 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
>