Subject: [spfbis] Issue: Revisit use of "check_host()"

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 7 Feb 2012 23:07:41 -0800

I'm sure some or all of you will be unthrilled that I brought this up, but nevertheless...

The use of "check_host()" in a standards track RFC smacks of us defining an API, which I think the IETF tries to avoid.  (The greybeards in here can correct me if I'm wrong.)  After staring at the RFC4408 text for a while, it seems to me it could be rewritten to avoid this construct without losing any detail.

I realize that's a little bit hypocritical coming from one of the co-editors of RFC6376, which defined a set of inputs, some outputs (one required, others optional), and some end states, but RFC4408 is a lot more blatant about it, for example by going so far as naming the function; somehow in my head it crosses a line that RFC6376 avoided.  I think it comes down to the difference between specifying a function and describing an algorithm.

I'd like us to consider this, even if said consideration in the end lasts only about 90 seconds and consists of solid consensus telling me it's fine the way it is.  :)

-MSK

---

From: S Moonesamy <[email-masked]>
Date: Wed, 08 Feb 2012 02:47:40 -0800

Hi Murray,
At 11:07 PM 2/7/2012, Murray S. Kucherawy wrote:
>The use of "check_host()" in a standards track RFC smacks of us 
>defining an API, which I think the IETF tries to avoid.  (The 
>greybeards in here can correct me if I'm wrong.)  After staring at 
>the RFC4408 text for a while, it seems to me it could be rewritten 
>to avoid this construct without losing any detail.

This is being tracked as Issue #11 ( 
http://trac.tools.ietf.org/wg/spfbis/trac/ticket/11 ).

>I'd like us to consider this, even if said consideration in the end 
>lasts only about 90 seconds and consists of solid consensus telling 
>me it's fine the way it is.  J

All issues raised will be considered by the WG.

Regards,
S. Moonesamy

---

From: Hector Santos <[email-masked]>
Date: Wed, 08 Feb 2012 08:01:03 -0500

Ok, this is starting to concern me.  Everyone's issue posted but my 
own were not added to the issued tracker when I believe my issue is 
fundamentally realistic about indirectly dealing SENDER-ID with a real 
RFC that exist and is supported by both senders and receivers.  You 
didn't even give it a chance for discussion and yet added stuff with 
potentials to get IETF Appeals (Issue #10 shoved down our throats).

The fact you choose not to add my issue, tells me this WG is going to 
be another DKIM with isolation and selective input ending up with up 
with a terrible Consensus By Osmosis process.

Are you deliberately trying to create chaos with this in-your-face 
ignorance?

--

This

S Moonesamy wrote:
>> greybeards in here can correct me if I'm wrong.)  After staring at the 
>> RFC4408 text for a while, it seems to me it could be rewritten to 
>> avoid this construct without losing any detail.
> 
>> lasts only about 90 seconds and consists of solid consensus telling me 
>> it's fine the way it is.  J
> 
> _______________________________________________
> spfbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spfbis
> 
> 
-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

---

From: S Moonesamy <[email-masked]>
Date: Wed, 08 Feb 2012 05:13:50 -0800

Hi Hector,
At 05:01 AM 2/8/2012, Hector Santos wrote:
>fundamentally realistic about indirectly

Would that be Issue #4 ( http://trac.tools.ietf.org/wg/spfbis/trac/ticket/4 )?

>  dealing SENDER-ID with a real RFC that exist and is supported by 
> both senders and receivers.  You didn't even give it a chance for 
> discussion and yet added stuff with potentials to get IETF Appeals 
> (Issue #10 shoved down our throats).

Issue #10 was raised in a message to the SPFBIS mailing list.  It was 
added to the tracker like any other issue posted to the mailing list.

>The fact you choose not to add my issue, tells me this WG is going 
>to be another DKIM with isolation and selective input ending up with 
>up with a terrible Consensus By Osmosis process.

See Issue #4.

>Are you deliberately trying to create chaos with this in-your-face ignorance?

No.

Regards,
S. Moonesamy
SPFBIS WG co-chair

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 08 Feb 2012 07:29:09 -0600

>Are you deliberately trying to create chaos with this in-your-face 

Hector,

I wonder if yours might not be left aside because it's outside the scope of the charter? No need for accusations.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 08 Feb 2012 08:51:25 -0500

S Moonesamy wrote:
> Would that be Issue #4 ( 
> http://trac.tools.ietf.org/wg/spfbis/trac/ticket/4 )?

My sincere apology for not focusing on the all the items listed. I 
thought I clicked and open all of them. I apparently didn't.  My apology.

> Issue #10 was raised in a message to the SPFBIS mailing 
> list.  It was added to the tracker like any other issue posted to 
> the mailing list.

Yes, and probably the question is whether allowing a "small thread" to 
see what may be the "obvious" immediate concerns before adding 
something to the tracker is warranted.  Even my own.

For example, in this issue #10, proposed as a replacement as it was 
stated, IMO, is guaranteed to be controversial and will not be 
realistically supported by long time established SPF operations and 
product vendors.  Proposed as an alternative is more realistic.   So 
perhaps a small thread to correct the proposal would save time when 
ISSUE #10 is discussed.  IOW, it will be what I will state on this 
issue.  Received-SPF  MUST NOT be eliminated in SPF-BIF not because I 
may or not believe using AUTH-RES is better, but rather because the 
proposal presumes the 3rd party filters will be in sync with changes 
and not broken when the SMTP receiver drops support for it.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Feb 2012 09:01:37 -0500

On Wed, Feb 08, 2012 at 08:51:25AM -0500, Hector Santos wrote:

> Yes, and probably the question is whether allowing a "small thread"
> to see what may be the "obvious" immediate concerns before adding
> something to the tracker is warranted.

Sorry, no, it is not, for the reasons we've already outlined more than
once.

We want to get all the issues out first.  If we attempt to have a
"small" thread to discuss whether each issue really is an issue, then
we will in effect debate all issues twice.  We'll never get anything
done that way.  I ask your indulgence in trying the approach we have
asked the WG to use.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Hector Santos <[email-masked]>
Date: Wed, 08 Feb 2012 09:11:14 -0500

Scott Kitterman wrote:
> 
> I wonder if yours might not be left aside because it's outside the scope of the charter? 

I was wrong. It was added. Faulty eyes. :(

I don't believe it is out of scope nor should be.  The facts are:

   - RFC 4405 is a SMTP protocol related to SPF non-payload outcomes,
   - There is large support for it by senders,
   - I can only speak for our package, but we support (SMTP 
receiver/forwarder) it.

I don't want to see what happen to DKIM with its rigid, unpopular 
decision to limit the input to the DKIM evaluators when in fact, the 
reality was there are more parameters, like Author Domain.

To me, we should think about the purity of the protocol model for SPF 
and that does include the possibility of seeing additional input, 
currently the RFC4405 SMTP extension for the SUBMITTER keyword:

      5321.MAIL FROM:<return-path> [SUBMITTER=PRA]

It also relates to issue #11 (check_host) process model description as 
an algorithm. Although I feel the issuer seems to be describing a 
different view in issue #11 than what was done in DKIM-BIF.  Issuer 
clarification is needed.

Anyway, I feel Issue #4 and Issue #11 are related. The SPF "evaluator" 
or Check_Host() as it is defined, SHOULD NOT be locked in to just two 
parameters.  It needs to be open ended and in the same way some did 
not want add specifically AUTHOR-DOMAIN as part of the input (an 
unrealistic mistake to ignore what was already done), we should not 
ignore the fact that SUBMITTER may be already realistically part of a 
SPF implementation for check_host().

---

From: S Moonesamy <[email-masked]>
Date: Wed, 08 Feb 2012 06:58:44 -0800

Hi Hector,
>thought I clicked and open all of them. I apparently didn't.  My apology.

It's alright.

>something to the tracker is warranted.  Even my own.

What may be obvious to me might not be obvious to other WG 
participants.  As an individual, it is easier for me not to have to 
figure out which questions will generate a "small thread".  It's less 
work for me to add the "questions" into the tracker ( 
http://trac.tools.ietf.org/wg/spfbis/trac/report/1 ).  If I missed an 
issue or if I misunderstood the issue, WG participants can point it 
out.  Disagreements will happen.  We can either talk about them and 
find an acceptable resolution or we can follow the IETF process to 
the letter.  I have a preference for the first alternative as it is 
snowing. :-)

>issue.  Received-SPF  MUST NOT be eliminated in SPF-BIF not because 
>I may or not believe using AUTH-RES is better, but rather because 
>the proposal presumes the 3rd party filters will be in sync with 
>changes and not broken when the SMTP receiver drops support for it.

I wonder which issue won't be controversial. :-)  Issue #10 is 
mentioned in a thread about Issue #4.  It is more work for me to 
follow the discussions about the issues when that happens.

The work of this working group will span over several months.  There 
is ample time to consider each issue calmly and work towards a 
resolution based on WG Consensus.

Regards,
S. Moonesamy