RE: (SPF-Pass) Re: [Council watch] Today featuring <grumpy>2005-06-02 03:44:03Added 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
|
|