spf-discuss
[Top] [All Lists]

RE: (SPF-Pass) Re: [Council watch] Today featuring <grumpy>

2005-06-02 03:44:03
Added to items listed below:

WHEN is the website going to be updated to REMOVE all references to CALLER
ID?

This has been requested since JANUARY, 2005!

Bruce Barnes
Chicago IL

-----Original Message-----
From: owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
[mailto:owner-spf-discuss(_at_)v2(_dot_)listbox(_dot_)com]On Behalf Of johnp
Sent: Thursday, June 02, 2005 01:43
To: spf-discuss(_at_)v2(_dot_)listbox(_dot_)com
Subject: (SPF-Pass) Re: [spf-discuss] [Council watch] Today featuring
<grumpy>



How long is it since Meng attended a meeting?

Why is the council not able to do a simple task of documenting the
existing and in-use version of spf?

Why does the council repeatedly fail to resolve the website issue?

Why does the council have such ridiculously long discussions about
points which have been beaten to death on spf-discuss?

When is the council going to resign and stand for re-election?

spf is dying on it's feet because of these shortcomings.


Slainte,
JohnP



Frank Ellermann wrote:
Hi, watching the SPF Council IRC log while the Council is in
session is something I shouldn't do anymore - yesterday it
was one "omigod - what are they doing now" after the other.

It also had its funny moments of course.  As almost always
it started with about 30 minutes waiting to reach "quorum",
in that case waiting for Meng.

"Grumpy" talked a bit about getting grumpier, and then most
points of the agenda were moot, no Meng, no quorum, nothing
about the Web page, the mailing list intro, and the minutes
of the last meeting.

Fortunately the last meeting had decided that draft issues
can be decided by three Council members while the Chair is
on vacation.

So Julian, Mark, and Wayne tackled the remaining "for Conucil
review" issues.  The order of presentation was unfortuately
somewhat arbitrary.  I'd understand "chronological", or if
one review request covers A-B-C, and another only A, start
with A-B-C, because then A could be automatically clear...

...but okay, they started with A, what to do about the case
redirect=any.invalid.  That caused quite a lot of ad hoc
brainstorming, drafting tables of possible solutios.  Or in
other words, two of our esteemed SPF Council members were
completely unprepared for the agenda, had not the faintest
idea about hundreds of articles about this issue discussed
in spf-discuss, and enjoyed the funs of "the making of SPF"
online in a telechat.

Based on the dubious assumption "nobody would deliberately
include NXDOMAIN" they still came to the correct solution.

IIRC it was Terry who mentioned that he includes non-existing
policies intentionally because they might exist in future.

Admittedly that was back when the SPF Community discussed the
finer points of processing limits and include:not.me, but all
in all just another brick in the wall.

After about 75 minutes they finally had the correct solution
"PermError in all cases of errors incl. redirect=any.invalid".

Then it went seriously surreal, they tackled A-B-C (minutes
after deciding A).

22:24 <grumpy> Ok, as for Frank's point one, I think we just did that.

Indeed.  Actually A-B-C was a package making sense together,
not three individual points.

22:27 <Julian> 2 - other cases of NXDOMAIN or domain literals
[...]
22:27 <Julian> I think Frank wants a formal resolution that
               SPF(non-existent-domain) == PermError will not happen.

Exactly, the A-B-C package doesn't work with NOT B.

22:29 <grumpy> Well, I think we already ruled on it, and thus I don't
               think we should re-open the issue unless someone who
               voted against it has changed their mind.
22:29 <grumpy> otherwise, what is the point of voting?

Let me see, that was the famous TILT tie, two yes, two no, and
it was about NOT B.  The TILT came from Mark, who later changed
his mind or at least apparently agreed with me in the _immediate_
predecessor of "for Council review A-B-C".

The NOT B motion came from Julian, who later announced that he
will not upheld his NOT B request.  And that makes two of two
yes-votes who changed their mind about supporting NOT B.

And in fact I proposed A-B-C as a package, not the isolated B.

22:31 <MarkK> we already decided on it

Yes, and you TILTed this decision.

22:31 <Julian> Not exactly.

True.  Sometimes decisions about NOT B can be very different
from B, especially if the B is in fact the part of a concept.

22:35 <grumpy> ok.
[...]
22:35 <grumpy> so, we are all on the same page, I think.
22:35 <MarkK> yes, we are :)

Wayne needed four minutes to convince himself that Mark really
agrees with B.  Pray that it's true this time.  At least Julian
promised to stop promoting NOT B for v=spf1.

22:35 <Julian> 3 - Receivers may treat PermError like FAIL, and
               TempError like SOFTFAIL, SMTP offers error codes
               5xx and 4xx resp.

Log reordered to reflect the logical flow of arguments.

22:35 <grumpy> I disagree with that, and we decided the PermError
               thing in the last meeting.

That was the meeting where A-B-C wasn't discussed because neither
the subject "for council review" nor an additional article in the
new thread "pointers for the Council / Wayne" was found in time
by any Council member.

22:36 <MarkK> I am still vehemently opposed to PermError = 'softfail'.
22:36       * Julian too.

Me too.  The A-B-C package wasn't for fun.

22:38 <grumpy> Ok, so the first part of Frank's point 3 has been
               already decided.

The surreal part begins, Wayne thinks that C consists of C1 and
C2.  Actually C2 is only a rationale for C1, and C is a part of
the A-B-C package, not an isolated point.  As discussed only two
hours before in:

<http://mid.gmane.org/429DFCAE(_dot_)251B(_at_)xyzzy(_dot_)claranet(_dot_)de>

22:38 <Julian> All I could remember was that we decided that
               "treat PermError like SoftFail" would have to go...

Me too.   Without minutes I won't ckeck it, but SOFTFAIL does
not fly with A-B-C, and NO SOFTFAIL is not exactly the same as
C = FAIL, because some users like Mark would also accept NEUTRAL.

And others like Scott really want NEUTRAL.  But like SOFTFAIL a
NEUTRAL does not fly with A-B-C (C = FAIL).

22:39 <grumpy> The second part is that TempError and SoftFail
               should get 4xx SMTP codes?
22:40 <grumpy> I agree with TempError, but certainly not SoftFail.

There's no secod part, the A-B-C package was posted 2005-22-05,
when the spec. still said "PermError like SOFTFAIL" and 4xx.

22:42 <Julian> grumpy: I think the current wording is fine if
               we do s/SHOULD/should/ or something equivalent.

Indeed, actually I don't care, these statements begin with "if
a message is rejected" etc., they don't say "SHOULD reject".

22:45 <grumpy> Having investigated those code numbers, I think
               it should be a SHOULD.

Note for later. Wayne had excellent reasons to give the codes.

22:56 <grumpy> Motion: the current language for PermError and
               SoftFail is fine and we should move on.

I obviously disagree for PermError, somehow the "investigated
code numbers" were removed, and A-B-C wants them simply BACK,
for crying out loud.

23:00 <MarkK> Julian: I do not think we can really be without
              indicating some sort of required action.

Yes, A-B-C wants some action for a PermError, like say a 5xx in
the form as it was, complete with Wayne's investigated DSN code.

23:03 <Julian> The motion is just saying that the spec shall not
               make formal recommendations on receiver policy.
               Only _if_ the receiver decides to reject, then we
               make a _formal_ recommendation on what SMTP reply
               code he should use.
23:03 <Julian> Votes?
23:03 <Julian> 2300u: yes
23:03 <grumpy> 2300u yes
23:03 <MarkK> 2300u: yes

So what exactly did they just decide ?  They already had A and B
of the A-B-C package.  Part C was "put the f*cking codes back in".

The resolution says "if the receiver decides to reject, then we
put the f*cking codes back in".  Now that's precisely what A-B-C
wanted:  
<http://mid.gmane.org/429DFCAE(_dot_)251B(_at_)xyzzy(_dot_)claranet(_dot_)de>

Wow, what a headache.  Wayne, please put the codes back in.  Bye


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com


-------
Sender Policy Framework: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Read the whitepaper!  http://spf.pobox.com/whitepaper.pdf
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com