This is the recent traffic on the #SPF-council IRC channel on
irc.pobox.com. Anyone may join the channel, but only council
members can talk.
| 23:33 | <Julian> | I just haven't had the time to sort out which ones... |
| --- Wed May 18 20:05:08 UTC 2005 --- |
| 20:05 | * | grumpy pokes his head in, sees his own shadow, and disappears for an hour |
| 20:58 | <MarkK> | good evening |
| 20:58 | <csm> | hello |
| 20:59 | <grumpy> | hi guys |
| 20:59 | <Julian> | hi MarkK |
| 20:59 | <Julian> | hi all |
| 20:59 | <csm> | I literally just drove back up to my house about 5 minutes ago |
| 20:59 | * | Julian too. |
| 21:00 | <grumpy> | thanks for phoning me Chuck and letting me know what was up. |
| 21:00 | <csm> | no worries |
| 21:00 | <grumpy> | I'm guessing we don't have an agenda, right? |
| 21:00 | <Julian> | One day we need to do a voice conference. That would be fun. |
| 21:00 | <csm> | just the one you sent |
| 21:00 | <grumpy> | ok |
| 21:00 | <grumpy> | Well, how long should we wait for freeside? |
| 21:00 | <Julian> | Let me see if I can add an issue or two to it. |
| 21:02 | <csm> | well in my own defense... I sent my email requesting topics for the meeting several days ago... |
| 21:02 | <Julian> | 15min or 30min, depending on how much time we all have. |
| 21:02 | <Julian> | csm: Well, Wayne did suggest some. Perhaps I can add one or two more in a few minutes. |
| 21:03 | <MarkK> | we can (and probably really should) put all summarized items mentioned by wayne on the agenda |
| 21:04 | <grumpy> | has everyone read the minutes? |
| 21:04 | <MarkK> | the website stuff and all will have to wait until Meng shows up |
| 21:04 | <csm> | MarkK: yes |
| 21:07 | <grumpy> | Well, I'm ready to start at any time and, unlike people on the other side of the pond, I can be here for several hours. |
| 21:07 | <grumpy> | let me know when we timeout on Meng. I'll be catching up on spf-discuss until then. |
| 21:22 | <MarkK> | dyd all y'all just got the email from the simpledns guy, too? |
| 21:22 | <MarkK> | (checking it out) |
| 21:22 | <grumpy> | nope, but I saw the forward made by csm. |
| 21:22 | <grumpy> | very cool |
| 21:23 | <Julian> | What simpledns guy? |
| 21:23 | <grumpy> | Julian: read spf-council |
| 21:23 | <csm> | ck mail |
| 21:26 | <grumpy> | btw, I emailed freeside a few minutes ago, just in case he wasn't sure that we were meeting rightnow.... |
| 21:27 | <MarkK> | (as far as I can see, that software allows for adding TXT records, but still refers to the spf-wizard at pobox for creating the string; I had hoped this program had a built-in wizard; oh well). |
| 21:29 | <csm> | okay well he has itmed out IMHO |
| 21:29 | <csm> | timed |
| 21:29 | <MarkK> | but his email stresses yet again the importance for us to update our site(s) |
| 21:29 | <MarkK> | csm: I consider him timed out as well |
| 21:29 | <csm> | okay |
| 21:29 | <grumpy> | ditto.... :-< |
| 21:29 | <csm> | let the meeting come to order |
| 21:29 | <grumpy> | Julian are you here? |
| 21:30 | * | grumpy is very grumpy about Meng blowing us off. |
| 21:30 | * | csm too |
| 21:30 | <csm> | Julian? |
| 21:30 | * | MarkK seconds that sadness, as we already postponed until this week |
| 21:30 | <csm> | the first order of business is the minutes |
| 21:32 | <Julian> | I'm here. |
| 21:32 | * | Julian just sent an addition to the agenda to spf-council. |
| 21:32 | * | grumpy goes and checks his email |
| 21:32 | <csm> | the chair would entertain a motion for approval of th eminutes |
| 21:33 | <Julian> | Motion: Please approve the 2005-04-27 meetin gminutes. |
| 21:33 | <Julian> | Motion: Please approve the 2005-04-27 meeting minutes. |
| 21:33 | <csm> | Second? |
| 21:33 | <MarkK> | 2132u: seconded |
| 21:33 | <grumpy> | 2233u(?) seconed |
| 21:34 | <csm> | votes? |
| 21:34 | <grumpy> | 2132u yea |
| 21:34 | <Julian> | 2132u: yes |
| 21:34 | <grumpy> | MarkK: ? |
| 21:34 | <MarkK> | 2132u: yes |
| 21:35 | <csm> | so ordered |
| 21:35 | <Julian> | Thanks. I just made the meeting minutes page public. |
| 21:35 | <csm> | the next item is the chair's report... I have no report... |
| 21:35 | <csm> | the next item is Meng's report |
| 21:35 | <csm> | he is AWOL |
| 21:35 | <csm> | what's next? |
| 21:36 | <grumpy> | Well, do we have anything to discuss before we start plowing into the I-D stuff? |
| 21:37 | <Julian> | I can report that I will definitely make progress on the website front _this_ week. |
| 21:37 | <grumpy> | good. |
| 21:37 | <MarkK> | Not from me; except to say, on the record, that I wanted Meng to be here, so we might (among other things) work on the website stuff |
| 21:37 | <csm> | Julian: what about the web site? |
| 21:38 | <MarkK> | julian/wayne, did meng give you access to his pobox site? |
| 21:38 | <Julian> | Well, obviously various people want _two_ websites. A preliminary one based on the current one, and a long-term new one. |
| 21:38 | <grumpy> | MarkK: no |
| 21:38 | <Julian> | MarkK: I doubt he wants to give us _direct_ access to the current one. |
| 21:38 | <grumpy> | Meng said that he would rsync to a development one |
| 21:38 | <grumpy> | which is fine with me |
| 21:38 | <Julian> | grumpy: Yeah. He probably can't justify giving us root access or something. |
| 21:39 | <MarkK> | grumpy: yes, that is how I remember it too |
| 21:39 | <MarkK> | which is ok with me |
| 21:39 | <csm> | frankly I don't care what Meng wants |
| 21:39 | <csm> | at this point I think it's clear we have to go elsewhere |
| 21:39 | <grumpy> | he also wants a certain set of tools (mason?), but I kind of think that should be up to whoever is actually doing the work. |
| 21:39 | <Julian> | Well, it's the machines of pobox.com. We can't decide about _those_ machines. |
| 21:40 | <csm> | we have been offered other machines |
| 21:40 | <Julian> | csm: This is just about the _temporary_ site. |
| 21:40 | <MarkK> | as long as he gives the access, so we can start building; "build it and he will come", eh? :) |
| 21:40 | <grumpy> | right. |
| 21:40 | <grumpy> | until we actually *do* something, spf.pobox.com is the best we have. |
| 21:40 | <MarkK> | csm has offered machines (he has been offered machines, that is; and he offered them to us, I believe) |
| 21:40 | <Julian> | Please bear with me a few more days. |
| 21:41 | <csm> | Julian: of course but I need you to listen for a second... |
| 21:41 | <Julian> | Shoot. |
| 21:41 | <csm> | please entertain the notion of moving away from pobox.com |
| 21:41 | <MarkK> | csm showed me the specs; and they seemed more than adequate for our purpose |
| 21:43 | <grumpy> | Ok, any more on the website? |
| 21:43 | <Julian> | csm: You waiting for a reaction from _me_? |
| 21:43 | <Julian> | ...right now, I mean? |
| 21:44 | <csm> | Julian: all I am doing is saying that ultimately I believe we will get more done if we stop depending on Meng... he cannot show up to meetings consistently... he wastes our time... I think it's time we move on from that |
| 21:45 | <grumpy> | I agree, but until we have something to move around, it is a moot point. |
| 21:45 | <Julian> | I do understand that. Please, bear with me for a few more days. |
| 21:45 | <grumpy> | again, spf-classic.{com,org} is available |
| 21:45 | <csm> | okay |
| 21:45 | <MarkK> | csm: as long as URL's are hardcoded to the pobox site, we cannot depart from that just yet |
| 21:45 | <csm> | who owns those? |
| 21:45 | <grumpy> | I do |
| 21:45 | <csm> | MarkK: what URL's? |
| 21:46 | <grumpy> | MarkK: well, maybe Meng will be willing to redirect spf.pobox.com to the new site. |
| 21:46 | <Julian> | There's also http://www.mail-spf.org and .com |
| 21:46 | <MarkK> | csm: the 'why' pages |
| 21:46 | <csm> | much less work for him... |
| 21:46 | <csm> | MarkK: it may be time to patch some code |
| 21:46 | <Julian> | csm: BTW, there will be a new reference implementation as soon as the spec is frozen. |
| 21:46 | <grumpy> | yep, after getting the spec done, I intend to start coding again. |
| 21:47 | <grumpy> | (famous last words. ;-) |
| 21:47 | * | Julian too. :) |
| 21:47 | <Julian> | Ok, let's move on to the I-D stuff. |
| 21:47 | <MarkK> | I am with csm, though, that I am getting increasingly less confident in Meng's ability/willingness to show up |
| 21:48 | <csm> | ditto in spades! |
| 21:48 | <grumpy> | Ok, should I lead the I-D stuff, or does the chair want to do that? |
| 21:48 | <MarkK> | julian: yes, let's |
| 21:49 | * | csm listens |
| 21:49 | <grumpy> | ok, I guess that means I lead. ;-) |
| 21:49 | <Julian> | grumpy: Go! |
| 21:50 | <grumpy> | The first item is the "syntax error = perm error = message rejected" thing |
| 21:50 | * | Julian gathers context. |
| 21:50 | <grumpy> | As I mentioned in my post to spf-council, I have updated the I-D so that perm error no longer says that you SHOULD reject. That is receiver policy. Instead it says that it SHOULD be treated similar to SoftFail. |
| 21:51 | <Julian> | Hmm. That's receiver policy, too. |
| 21:51 | <MarkK> | grumpy, before we go into detail on that, can I first ask the overall question on whether we are going to do away with forced receiver policy altogether? (in which case all these 'dictacted' behaviors have become moot) |
| 21:52 | <grumpy> | Not really, it just kicks it over to a differen paragraph, which dictates no receiver policy. |
| 21:52 | <Julian> | MarkK: I'd phrase it a little bit differently: let's define what's receiver policy and what's not. |
| 21:52 | <MarkK> | ok |
| 21:52 | <Julian> | grumpy: But receivers may want to react to PermError differently than to SoftFail. |
| 21:53 | <Julian> | And we can't really stop them from doing so. Also, it is not essential that those two results are treated identically. |
| 21:53 | <grumpy> | it doesn't say identical, and it doesn't say MUST |
| 21:54 | <Julian> | Oh, it says "similar". But what's _that_ supposed to mean, really? |
| 21:54 | <grumpy> | whatever the receiver wants it to mean. ;-) |
| 21:54 | <Julian> | Great, then why not just omit it from the spec? |
| 21:54 | <Julian> | We should explain what the results mean, not how receivers MUST or SHOULD react. |
| 21:55 | <MarkK> | 'softfail' is the result of a correct SPF lookup which essentially says "fail, but not really." I do not see why that should be treated like a PermEerror with 5.x.x codes |
| 21:55 | <MarkK> | julian: yes |
| 21:56 | <grumpy> | I can't see getting rid of all suggested receiver policies. |
| 21:56 | <grumpy> | not unless we make a BCP receiver policy document. |
| 21:57 | <MarkK> | grumpy: and I was not suggesting we do; :) I just wanted to know whether this is what we were headed towards |
| 21:57 | <Julian> | grumpy: No, but I can't really see the value of specifically recommending that PermError be treated "similar" to SoftFail. |
| 21:57 | <Julian> | We don't have to drop _all_ recommendations on receiver policy. But probably _that_ one. |
| 21:57 | <grumpy> | while I don't want to turn the I-D into a how-to document, I think we need to give a rough idea what is expected. |
| 21:58 | <Julian> | csm: What's your take on this? |
| 21:58 | <csm> | keep it short |
| 21:58 | <MarkK> | I still think we need to create a 'deployment' document, outling in detail such things as receiver policy |
| 21:59 | <csm> | and sop far as PermError? |
| 21:59 | <grumpy> | MarkK: good idea. go for it. ;-) |
| 21:59 | <csm> | there is no such thing as permanent on the net |
| 21:59 | <Julian> | I don't think we really need such a thing, because we already have so much of this in the spec. |
| 21:59 | <MarkK> | wayne: ok, I will |
| 21:59 | <grumpy> | Ok, one of the reasons I said "similar to SoftFail" is that it was short. |
| 21:59 | <Julian> | But it's more or less meaningless. |
| 22:00 | <MarkK> | julian: bit if we start taking this stuff out of the spec, then a receiver policy implementation document may be usefuk |
| 22:00 | <Julian> | MarkK: But then we would have to take _a lot_ out of the spec. |
| 22:00 | <Julian> | Or at least, most of that stuff would then be redundant. |
| 22:00 | <csm> | there is no such thing as permanent on the net |
| 22:01 | <csm> | keep the doc short |
| 22:01 | <grumpy> | do people need a copy of the SoftFail/PermError wording? |
| 22:01 | <MarkK> | julian: this document would be unofficial; so it would simply cover all 'hot' items and controversies |
| 22:01 | <Julian> | grumpy: Out of interest: do you think that not making explicit recommendations on receiver policy means chaos (to some degree)? And if so, why? |
| 22:01 | <Julian> | 2.5.7. PermError |
| 22:01 | <Julian> | A "PermError" result means that the domain's published records |
| 22:01 | <Julian> | couldn't be correctly interpreted. Checking software SHOULD treat |
| 22:01 | <Julian> | this result similar to the "SoftFail" result. Be aware that if the |
| 22:01 | <Julian> | domain owner uses macros (Section 8), it is possible that this result |
| 22:02 | <Julian> | is due to the checked identities having an unexpected format. |
| 22:02 | <Julian> | -- |
| 22:02 | <Julian> | grumpy: I could live with the current (-01pre6) wording if s/SHOULD/should/. |
| 22:02 | <csm> | PermError seems a poor name for this |
| 22:02 | <grumpy> | I think the discussion of the receiver policy options gives the sender policy creators an better understanding of what the terms mean. |
| 22:03 | <Julian> | csm: It's a permanent error in the sense that manual intervention is required to clear it. |
| 22:03 | <grumpy> | csm: it is better than "unknown" |
| 22:03 | <MarkK> | wayne: I am really not happy with treating a permerror like 'softfail' |
| 22:03 | <Julian> | csm: That's analoguous to the RFC 2821 4xx/5xx reply code semantics. |
| 22:03 | <csm> | okay but lemme ask something |
| 22:04 | <csm> | what's the error if the dns host is unreachable? |
| 22:04 | <grumpy> | that is a TempError |
| 22:04 | <csm> | okay so the error you are meaning to describe above is a misconfiguration |
| 22:04 | <grumpy> | Julian: I could live with s/SHOULD/should/ also. |
| 22:04 | <MarkK> | (in SPF terms: transient 4.x error) |
| 22:04 | <grumpy> | csm: right |
| 22:05 | <csm> | call it PABKAC |
| 22:05 | <csm> | PEBKAC |
| 22:05 | <Julian> | grumpy: Could you live with $SECTION_TEMPERROR =~ s/SHOULD/should/, too? |
| 22:05 | * | grumpy double checks |
| 22:06 | <Julian> | Uhm, wait. |
| 22:06 | <grumpy> | Uh, I don't think so. |
| 22:06 | <Julian> | We should be consistent with using (or not using) KEYWORD language in all 2.5.x (result codes) sections. |
| 22:06 | <grumpy> | The SHOULD in TempError is a recommendation for the SMTP reject codes |
| 22:06 | <MarkK> | julian: a miosconfiguration is PermError, right? So, why treat is like 'softfail'? That does not make sense to me |
| 22:06 | <Julian> | MarkK: Yes. |
| 22:07 | <Julian> | I just said I "could live" with it, not that I liked it. |
| 22:07 | <grumpy> | MarkK: please explain (again?) what you don't like about PermError == quasi-SoftFail? |
| 22:07 | <Julian> | In order to accept that compromise (s/SHOULD/should/), I'd want to have something in return. ;-) |
| 22:07 | <csm> | I just think PermError is a poor description |
| 22:07 | <Julian> | csm: Suggest a better one. |
| 22:08 | <csm> | PEBKAC |
| 22:08 | <Julian> | Motion: Move discussion about $current_issue to spf-discuss, and move on to next item. |
| 22:08 | <MarkK> | wayne: 'softfail' is the result of a policy decision; PermError is really a permant type of error, that really should be met with 5.x.x codes. |
| 22:08 | <grumpy> | I would like to get this stuff resolved |
| 22:08 | <MarkK> | me too |
| 22:09 | <Julian> | We can't keep discussing this for another 30 minutes. |
| 22:09 | <grumpy> | as far as using "PEBKAC", I don't think that is a better name. |
| 22:09 | * | Julian neither. |
| 22:09 | <grumpy> | MarkK: Ok, so your opinion is that PermError should recommend 5xx codes? |
| 22:09 | <grumpy> | Remember, mengwong-spf-* say no such thing. |
| 22:10 | <Julian> | grumpy: That would be better than the current wording. |
| 22:10 | <grumpy> | nor do SPF implementations |
| 22:10 | <Julian> | Implementations never "recommend" anything. |
| 22:10 | <MarkK> | wayne: yes; but more that 'softfail' should not be treated with 5.x.x codes; hence, they are not the same |
| 22:10 | <grumpy> | no, but we want the spec to document what currently exists. |
| 22:11 | <Julian> | Guys, we shouldn't be discussing this here or now. |
| 22:11 | <MarkK> | currently I think implementation send 5.x.x codes on PermErrors |
| 22:11 | <Julian> | If there's need for _extensive_ discussion, move it to spf-discuss. |
| 22:12 | <MarkK> | I do *not* want that for 'softfail' |
| 22:12 | <MarkK> | ok, I am done |
| 22:13 | <Julian> | Also, I don't feel I'm able to vote on this issue. Obviously, there's significant need for further discussion. |
| 22:13 | <grumpy> | Ok, let's move it back to spf-discuss |
| 22:13 | <grumpy> | votes? |
| 22:14 | <Julian> | 2213u: seconded |
| 22:14 | <MarkK> | As long as we have it on record, and in the minutes please, that I oppose 'softfail' = PermError |
| 22:14 | <grumpy> | 2213u: yea |
| 22:14 | <Julian> | 2213u: yes |
| 22:14 | <MarkK> | PermError = 'softfail', I meant |
| 22:14 | <MarkK> | 2213u: yes |
| 22:14 | <grumpy> | ok |
| 22:14 | <Julian> | csm: You still there? :) |
| 22:15 | <grumpy> | before we move on to the next item, would it be possible to have another meeting before next Wed? |
| 22:15 | <Julian> | Possibly. |
| 22:15 | <MarkK> | I like that |
| 22:15 | <grumpy> | with the assumption that Meng's schedule is irrelevant. |
| 22:15 | <Julian> | Sunday or Monday? |
| 22:16 | <grumpy> | Yeah, either one. |
| 22:16 | <grumpy> | csm? |
| 22:16 | * | grumpy wonders if we have lost quorum... |
| 22:16 | <Julian> | Let's define the next meeting date later. |
| 22:16 | <grumpy> | ok |
| 22:16 | <MarkK> | csm? |
| 22:16 | <Julian> | But let's wait for Chuck first. |
| 22:17 | <grumpy> | I'm going to set up the next item, and then wait for csm |
| 22:17 | <grumpy> | the next item is "MUST accept source routes" |
| 22:18 | <grumpy> | IMHO, this is useful language, but not critical. I think we have spent way too much time discussing half a sentence. |
| 22:18 | <grumpy> | Ok, wait(csm) |
| 22:19 | <Julian> | Why do we need to vote on that? Was it really controversial? |
| 22:20 | <grumpy> | A review was requested, therefore we should vote on it. |
| 22:20 | <csm> | sorry |
| 22:20 | <csm> | phone |
| 22:20 | <csm> | but I have eyes on screen again |
| 22:20 | <grumpy> | csm YOU MUST *NOT* HAVE LIFE OUTSIDE SPF! |
| 22:20 | <grumpy> | ;-) |
| 22:20 | <csm> | nbwaaaaaaaaahahahahaha |
| 22:21 | <grumpy> | Ok, does anyone want to discuss this issue? |
| 22:21 | <csm> | which? |
| 22:21 | <grumpy> | the next item is "MUST accept source routes" |
| 22:22 | <grumpy> | motion: the current draft language is fine |
| 22:22 | <Julian> | grumpy: I'm still trying to understand the issue. |
| 22:22 | <grumpy> | ok |
| 22:23 | <grumpy> | Once upon a time, there were many different forms of email addresses, including things like "dsndata.com!wayne@backbone.uucp" |
| 22:23 | <grumpy> | such addresses are inherently ambigious since it could mean "first deliver to dsndata.com, and then send it off to wayne@backbone.uucp", or it could mean delivering to backbone.uucp first |
| 22:24 | <grumpy> | there are a few other features, such as 821 source routes and the %-hack. |
| 22:24 | <grumpy> | all of these have been coded into various MTAs over the years, and are often still supported. |
| 22:24 | <grumpy> | and doing non-obvious stuff. |
| 22:25 | <grumpy> | spammers have, for many years, used these features to try and create open relays |
| 22:25 | <MarkK> | Is it not safe to say the RHS dmain should be used for SPF? |
| 22:25 | <grumpy> | MTAs would verify one part of the "address" is local and therefore ok to relay, and do another thing. |
| 22:26 | <Julian> | Uhm, I had overlooked this suggestion by Frank. I think the current wording can be improved, but I don't think that Franks suggestion is optimal. |
| 22:26 | <Julian> | Also, I don't think I should make an alternative suggestion here and now. |
| 22:26 | <grumpy> | MarkK: no, not if the MTA transforms the address after it accepts it. |
| 22:26 | <Julian> | Therefore, if this is put to vote now, I'm going to abstain. |
| 22:26 | <grumpy> | which is another common thing for MTAs to do. |
| 22:27 | <Julian> | I wonder why no one replied to Frank's suggestion. |
| 22:27 | <MarkK> | wayne, I meant in: MAIL FROM:<"some@where"@example.com> |
| 22:27 | <grumpy> | I think I did. Or I was involved in discussing it with him. |
| 22:28 | <MarkK> | the transformation issue, I agree, is trickier |
| 22:28 | <MarkK> | (as SPF is usually done before such transformation takes place) |
| 22:28 | <Julian> | Why can't we just say "SPF doesn't support source routes"? |
| 22:29 | <MarkK> | julian: that seems like a good solution. :) |
| 22:29 | <grumpy> | MarkK the problem is that "backbone!wayne@spammer.com" could be transformed by the MTA after the SPF check into wayne@backbone |
| 22:29 | <grumpy> | Julian: it isn't a matter of what SPF supports, it is a matter of what kind of bogus data can be thrown at the MTA in order to trick the SPF checks |
| 22:30 | <MarkK> | Otherwise, we have to do the transformation manually; and like wayne said, some of those transformation are ambiguous |
| 22:30 | <MarkK> | wayne: but can the SPF software really make/guess the correct transformation? |
| 22:31 | <Julian> | (The reason why no one replied to Frank's message is probably that he didn't start a new thread.) |
| 22:31 | <Julian> | grumpy: Well, SPF(source-route) == PermError. q.e.d. |
| 22:31 | <grumpy> | MarkK: sure, it is all part of the same MTA |
| 22:31 | * | Julian ducks |
| 22:32 | <grumpy> | This is really just a heads up to SPF implementers, not SPF publishers. |
| 22:32 | <Julian> | Isn't there a defined way to resolve the ambiguity of source routes and co.? |
| 22:32 | <MarkK> | grumpy: I do not see how; if SPF is processed at MAIL FROM, how will the (standard) implementation know how your MTA would interpret the address, later on? |
| 22:33 | <Julian> | Also, weren't source routes and bang paths meant to be sort of backwards compatible to regular RFC 821 mailbox addresses? If so, we can just take the thing after the @. |
| 22:33 | <MarkK> | julian: SPF(source-route) = None, perhaps? |
| 22:33 | <Julian> | No, no, no. |
| 22:33 | <Julian> | You make my head hurt. |
| 22:33 | <grumpy> | heh |
| 22:34 | <Julian> | "None" meany something completely different than SPF(nonsense-of-some-sort) should mean. |
| 22:34 | <Julian> | s/meany/means/ |
| 22:34 | <MarkK> | better than PermError, methinks; because that would mean SPF would break source-routing |
| 22:34 | <MarkK> | good luck getting that past the IETF. :) |
| 22:35 | <grumpy> | yeah, we can't break source routes. |
| 22:35 | <Julian> | Source routes break SPF. |
| 22:35 | <Julian> | Again: weren't source routes and bang paths meant to be sort of backwards compatible to regular RFC 821 mailbox addresses? If so, we can just take the thing after the @. |
| 22:35 | <MarkK> | I doubt the IETF will see it that way |
| 22:35 | <grumpy> | Ok, maybe instead of saying "Care must be taken to correctly extract the <domain> from the <sender>" |
| 22:36 | <grumpy> | I should say "Care must be taken to correctly interpret the data passed to the MAIL FROM command" |
| 22:37 | <grumpy> | or some such thing. |
| 22:37 | <MarkK> | (implementors might do an internal EXPN command, to try and ascertain how their MTA will 'decode' the source-route; but this would be a implementors issue, rather) |
| 22:37 | <Julian> | Implementors are going to wonder _how_ to actually interpret it. _If_ this issue is complicated _and_ we cannot sidestep it by saying SPF(source-route/bang-path) == PermError, we should give a pointer to where this stuff is defined. |
| 22:38 | <grumpy> | but, it appears to me that we don't have a clear idea of what we want, therefore maybe we should take it to spf-discuss |
| 22:38 | <Julian> | Probably true. |
| 22:39 | * | Julian has marked Frank's message as unread and important. |
| 22:39 | <MarkK> | wayne: at least I know that I do not want a PermError on source-routes; we should probably bring the rest to spf-discuss |
| 22:40 | <grumpy> | motion: move this back to spf-discuss |
| 22:40 | <Julian> | If we say SPF(source-route) == None, it will not only distort and pollute the meaning of "None" even further, it will also be a nice way to circumvent SPF. |
| 22:40 | <Julian> | 2240u: seconded |
| 22:40 | <grumpy> | votes? |
| 22:40 | <csm> | aye |
| 22:40 | <Julian> | 2240u: yes |
| 22:40 | <grumpy> | 2240u: yea |
| 22:40 | <MarkK> | julian: agreed, but do you also agree that PermError is undesired? |
| 22:40 | <Julian> | MarkK: No. |
| 22:41 | <Julian> | But I agree that SPF(source-route) may not be the best solution. |
| 22:41 | <grumpy> | Next item: |
| 22:41 | <MarkK> | 2240u: yes |
| 22:41 | <grumpy> | NOT RECOMMENDED |
| 23:05 | <grumpy> | No change in -01pre7 was made for this. |
| 23:05 | <grumpy> | I think people are still actively discussing this. |
| 23:05 | <Julian> | -01pre_7_? Have I missed something? |
| 23:05 | <grumpy> | this has, in part, to do with the whole "authorized" vs "authenticated" thing. |
| 23:06 | <grumpy> | Uh, I released -01pre7 last night. |
| 23:06 | <Julian> | Oops, I have missed something, yeah. |
| 23:06 | <grumpy> | Or, early this morning for you. |
| 23:06 | <Julian> | I haven't had a chance to read spf-discuss during the last 36h. |
| 23:06 | <grumpy> | It is nothing big. I just wanted to clear the change queue before the meeting. |
| 23:07 | <Julian> | ...which didn't help since I didn't manage to read -01pre7. ;-) |
| 23:07 | <Julian> | Anyway... |
| 23:07 | <grumpy> | Ok, do people want to discuss this? |
| 23:07 | <Julian> | Not here. I'm not up to date with spf-discuss. |
| 23:07 | <grumpy> | Again, I think the current language is acceptable, but then, if I didn't, I would have changed it. |
| 23:08 | <grumpy> | motion: we send this back to spf-discuss |
| 23:08 | <Julian> | 2308u: seconded |
| 23:08 | <grumpy> | votes? |
| 23:08 | <grumpy> | 2308u yes |
| 23:08 | <MarkK> | 2308u: yes |
| 23:08 | <grumpy> | csm? |
| 23:08 | <csm> | 2308u yes |
| 23:08 | <grumpy> | 3 votes, motion passes |
| 23:08 | <grumpy> | Ok, next item: |
| 23:08 | <grumpy> | As an addition agenda item, William suggested that the council take a |
| 23:08 | <grumpy> | vote on whether we want to pursue Proposed Standard or Experimental |
| 23:08 | <grumpy> | status for the I-D, and I agree. (We could also do Informational.) |
| 23:08 | <Julian> | 2308u: yes, that makes 4 yes. |
| 23:09 | <Julian> | What are the exact differences between those? |
| 23:09 | <Julian> | IOW, where are those defined? |
| 23:09 | <grumpy> | I talked with my Father this morning about this, and as a decade+ lurker on the IETF stuff, he says "go for it." |
| 23:09 | <Julian> | "go for $WHAT"? |
| 23:09 | <grumpy> | A Proposed Standard is something that is, well, a standard |
| 23:09 | <Julian> | Informational? Experimental? Proposed Standard? |
| 23:10 | <grumpy> | or, on the track to be an Internet Standard. |
| 23:10 | <csm> | so lets go for it then |
| 23:10 | <grumpy> | "it" == "try for proposed standard" |
| 23:10 | <Julian> | I see. |
| 23:10 | <grumpy> | Experimental is *not* a standard, and it will say so right at the top. |
| 23:10 | <MarkK> | I like to go for "it" |
| 23:10 | <grumpy> | It is supposed to be for, well, experimenting with a protocol and learning about what will happen. |
| 23:11 | <Julian> | I think most of the IETF guys think of SPFv1 being experimental. But I consider it a proposed standard. |
| 23:11 | <grumpy> | Information is what you use when you want to publish a protocol, but don't want to go through the IETF process. |
| 23:11 | <grumpy> | One of the IESG reviewers asked why it wasn't a Proposed STandard |
| 23:11 | <Julian> | Hmm. |
| 23:12 | <Julian> | What have we pursued up to now? |
| 23:12 | <grumpy> | going for a Proposed Standard will mean that there will be an IETF-wide last call, where everyone who doesn't like anything about SPF will come out and shoot it down. |
| 23:12 | <grumpy> | I haven't pursued anything, it was assumed (incorrectly) that spf-classic was part of the MARID I-Ds |
| 23:12 | <Julian> | "will [...] shoot it down"? Does that mean everyone in the IETF has veto powers? |
| 23:13 | <grumpy> | and therefore, following the recommendation when MARID was shut down, it was going to be made an experiemental |
| 23:13 | <grumpy> | No, it means that there needs to be a rough consensus (judged by the IESG) that the document has no technical errors or omissions and that it is something that is worth trying out as a standard. |
| 23:13 | <grumpy> | (hence proposed) |
| 23:14 | <Julian> | Ok. |
| 23:14 | <Julian> | Motion: The SPFv1 specification shall long for IETF Proposed Standard status. |
| 23:14 | <grumpy> | People will say "SPF BREAKS FORWARDING!!!!", but that isn't a valid reason why a document describing SPF should not go forward. |
| 23:14 | <grumpy> | 2314u seconded |
| 23:14 | <Julian> | (Well, spam breaks forwarding, too.) |
| 23:15 | <grumpy> | basically, this just means that we will have to put a lot of work into explaining SPF, and there is a possiblity that we will end up with Experimental anyway. |
| 23:15 | <grumpy> | votes? |
| 23:15 | <csm> | votes? |
| 23:15 | <Julian> | 2314u: yes |
| 23:15 | <grumpy> | 2314u yea |
| 23:15 | <csm> | 2314u: yes |
| 23:16 | <Julian> | MarkK: ? |
| 23:16 | <grumpy> | wait(quorum check) |
| 23:16 | <MarkK> | 2314u: yes |
| 23:16 | <Julian> | Weee! |
| 23:16 | <grumpy> | Ok, the next three are Julian's so maybe it would be best for him to take the lead |
| 23:17 | <grumpy> | I'd like to vote on: |
| 23:17 | <grumpy> | * the SPF(non-existent-domain) == "PermError" issue, |
| 23:17 | <grumpy> | * the s/prefix/$SEMANTICALLY_DESCRIPTIVE_NAME/ issue, |
| 23:17 | <grumpy> | * the "section 9.3.1.2 does not warn about the 63 character limit" issue. |
| 23:17 | <grumpy> | You can read about all of those in |
| 23:17 | <grumpy> | s/next three/final three/ |
| 23:17 | <Julian> | Ok. /me takes the conch. |
| 23:17 | <grumpy> | Julian? |
| 23:18 | <Julian> | Well, the SPF(non-existent-domain) == "PermError" issue is probably going to be voted down (is it?), but I want to get this clarified once and for all. |
| 23:18 | <Julian> | Any comments? |
| 23:19 | <Julian> | ... |
| 23:19 | <grumpy> | ... |
| 23:20 | <csm> | I dunno what the issue is... can somebody give me the 10 cent version? |
| 23:20 | <grumpy> | I strongly feel that SPF(NXDOMAIN) == "None" is the right thing to do. It matches the description of "None" in the draft better than the description for PermError and it is far more backwards compatible with previous specs and implemenatations |
| 23:21 | <csm> | no domain? |
| 23:21 | <Julian> | SPF should not be applicable to non-existent domains or syntactically invalid identities, and should return PermError in those cases. The behavior defined in past SPFv1 specification drafts is inconsistent, so we have to be backwards _in_compatible in one way or another anyway. |
| 23:21 | <csm> | that's the error here? |
| 23:21 | <grumpy> | csm: If you do an SPF check on a non-existant domain, say foo.moongroup.com, should the result be "none" because no record was found, or "permerror" |
| 23:22 | <csm> | no9ne |
| 23:22 | <csm> | none |
| 23:22 | <csm> | if there is no record of the domain that is not an error in the SPf protocol |
| 23:22 | <Julian> | Also, if you do an SPF check on "foo" (syntactically invalid domain), should the result be "None" or "PermError"? |
| 23:23 | <Julian> | csm: The point is that MTAs should check for the existence of the domain _before_ even calling SPF. |
| 23:23 | <grumpy> | there is no SPF record, therefore "None". |
| 23:23 | <csm> | I go with grumpy |
| 23:23 | <grumpy> | Julian: agreed, they should. |
| 23:23 | <Julian> | Also, if you do an SPF check on "foo" (syntactically invalid domain), should the result be "None" or "PermError"? |
| 23:23 | <grumpy> | MarkK? |
| 23:23 | <csm> | it's got nothing to do with SPF |
| 23:23 | <MarkK> | The point is rather moot, I think, as NXDOMAIN in MAIL FROM is likely already weeded out by the MTA before SPF gets a o at it |
| 23:24 | <Julian> | csm: Exactly. That's why SPF(weird_situation) should not be defined to give a nominal result code such as "None". |
| 23:25 | <grumpy> | 2.5.1. None |
| 23:25 | <grumpy> | A result of "None" means that no records were published by the |
| 23:25 | <grumpy> | domain, or that no checkable sender domain could be determined from |
| 23:25 | <grumpy> | the given identity. The checking software cannot ascertain if the |
| 23:25 | <grumpy> | client host is authorized or not. |
| 23:25 | <Julian> | MarkK: If the point is moot, what's the problem with defining SPF(non-existent-domain or syntactically-invalid-domain) == PermError?</devils-advocate> |
| 23:25 | <Julian> | grumpy: Yes, that's the _current_ definition of "None". My proposal would change it. |
| 23:25 | <grumpy> | 2.5.7. PermError |
| 23:25 | <grumpy> | A "PermError" result means that the domain's published records |
| 23:25 | <grumpy> | couldn't be correctly interpreted. |
| 23:25 | <grumpy> | Julian: then you are proposing changing long standing terms. |
| 23:25 | <Julian> | grumpy: You're omitting text from 2.5.7. :) |
| 23:26 | <csm> | but a PermError when there is no such domain? |
| 23:26 | <csm> | come on... |
| 23:26 | <Julian> | One last try at explaining it: |
| 23:26 | <Julian> | ... |
| 23:26 | <MarkK> | I can find a rationale for PermError; but I can live with 'none' |
| 23:27 | <Julian> | Look at it this way: if SPF(non-existent-domain) == None, then people are certainly _not_ going to rely on SPF because most of them don't _want_ to allow non-existent domains for the envelope sender. |
| 23:28 | <Julian> | s/rely on SPF/rely on SPF for non-existent domains/ |
| 23:28 | <grumpy> | yeah, but I wouldn't anyway. |
| 23:28 | <Julian> | But "None" usually means "let it pass". |
| 23:29 | <grumpy> | Where as PermError does what? |
| 23:29 | <grumpy> | ;-) |
| 23:30 | <grumpy> | wait(quorum) |
| 23:30 | * | csm creeps away for a bio break |
| 23:30 | <Julian> | What's that? |
| 23:31 | <grumpy> | uh, the WC |
| 23:31 | <Julian> | I see. :) |
| 23:32 | <Julian> | Re PermError: usually it does NOT mean "let it pass". I doubt that many receivers do not reject on "PermError". |
| 23:32 | <Julian> | Especially since PermError has long been recommending exactly that, a 5xx SMTP reply code. |
| 23:32 | <grumpy> | I don't believe that is true. |
| 23:33 | <csm> | no Mark? |
| 23:33 | <grumpy> | no it hasn't. |
| 23:33 | * | grumpy suspects that mark will be back |
| 23:33 | <Julian> | I guess he lost his ISP connection once again. |
| 23:33 | <MarkK> | sorry, got disconnected (stupid XP froze) |
| 23:33 | <grumpy> | mark: lost stuff: |
| 23:33 | <grumpy> | <grumpy> wait(quorum) |
| 23:33 | <grumpy> | * csm creeps away for a bio break |
| 23:33 | <grumpy> | <Julian> What's that? |
| 23:33 | <grumpy> | <grumpy> uh, the WC |
| 23:33 | <grumpy> | <Julian> I see. :) |
| 23:33 | <grumpy> | <Julian> Re PermError: usually it does NOT mean "let it pass". I doubt that many receivers do not reject on "PermError". |
| 23:33 | <grumpy> | <Julian> Especially since PermError has long been recommending exactly that, a 5xx SMTP reply code. |
| 23:33 | <grumpy> | <grumpy> I don't believe that is true. |
| 23:33 | <grumpy> | <csm> no Mark? |
| 23:33 | <grumpy> | <grumpy> no it hasn't. |
| 23:34 | * | csm recommends a good open source operating system.... |
| 23:34 | <grumpy> | heh |
| 23:34 | <Julian> | grumpy: Why do you think that many receivers do not reject on "PermError"? |
| 23:34 | <MarkK> | grumpy: I think the vast majory will reject with 5.x errors |
| 23:34 | <grumpy> | that was the whole point of the first item on the I-D. |
| 23:35 | <grumpy> | all previous SPF specs say that you don't reject on PermError (aka unknown) |
| 23:35 | <grumpy> | and Scott was very concerned about the new language |
| 23:36 | <MarkK> | yes, ever since we switched from 'unknown' to PermError |
| 23:36 | <Julian> | I agree that we shouldn't prescribe receiver policy, but I think most receivers will reject on "PermError". I don't think that Scott's opinion is very representative. (No offense, Scott.) |
| 23:36 | <grumpy> | Unknown: indicates incomplete processing: an MTA MUST proceed as |
| 23:36 | <grumpy> | if a domain did not publish SPF data. |
| 23:36 | <grumpy> | -- mengwong-spf-0[01] |
| 23:36 | <Julian> | Granted. |
| 23:36 | <Julian> | Anyway, we're not making any real progress, as I expected. Let's vote. |
| 23:37 | <Julian> | Motion: SPF shall not be applicable to non-existent domains or syntactically invalid identities, and shall return PermError in those cases. The behavior defined in past SPFv1 specification drafts is inconsistent, so we have to be backwards _in_compatible in one way or another anyway. |
| 23:37 | <grumpy> | commentary in the motion is uh.... |
| 23:37 | <Julian> | It's rationale, sort of. |
| 23:37 | <grumpy> | anyway, seconded just so we can vote |
| 23:38 | <Julian> | Votes? |
| 23:38 | <grumpy> | 2338:u no |
| 23:38 | <Julian> | 2337u: yes |
| 23:38 | <csm> | 2337u: no |
| 23:38 | <MarkK> | 2338u: yes |
| 23:38 | <csm> | muahahahahahaha |
| 23:38 | <grumpy> | thanks freeside! |
| 23:38 | <Julian> | Interesting. |
| 23:38 | * | csm is laughing out loud |
| 23:38 | <Julian> | What about freeside? |
| 23:39 | <grumpy> | Uh, we have a tie |
| 23:39 | <csm> | oh he's not here so we have a tie |
| 23:39 | <grumpy> | if freeside was here, we wouldn't |
| 23:39 | <Julian> | Let me consult the resolutions. |
| 23:39 | <Julian> | Yeah, I guess it's a tie so the motion is void. |
| 23:40 | <Julian> | I'll repeat the motion when Meng is here. |
| 23:40 | <grumpy> | heh |
| 23:40 | <MarkK> | csm: why did you vote it down? |
| 23:40 | <csm> | because4 PermError on a non-existent domain is stupid... (no offense Julian)... it's not an error... it's a nothing |
| 23:40 | <Julian> | MarkK: Because he follows Wayne's reasoning. |
| 23:41 | <Julian> | No offense taken. |
| 23:41 | <Julian> | nothing = undefined = permerror. IMO. :-) |
| 23:41 | <csm> | an error is a broken record... |
| 23:41 | <Julian> | Whatever, let's move on. |
| 23:41 | <grumpy> | yeah, we will be back again to resolve other issues. |
| 23:41 | <Julian> | Two items left. |
| 23:41 | <MarkK> | csm: MTA's react with PermError on NXDOMAIN too |
| 23:42 | <grumpy> | MarkK: no they don't. They don't have term "PermError". |
| 23:42 | <csm> | MarkK: that doesn't apply to SPF... |
| 23:42 | <Julian> | The s/prefix/$SEMANTICALLY_DESCRIPTIVE_NAME/ issue. |
| 23:42 | <csm> | the MTA and SPF are doing different jobs |
| 23:42 | <MarkK> | csm: it just underlines the rationale |
| 23:42 | <csm> | anyway hold up |
| 23:43 | <csm> | we are almost 3 hours into this guys... |
| 23:43 | <grumpy> | and we are almost done... |
| 23:43 | <csm> | we need to table the remainder and do another meeting one night this weekend |
| 23:43 | <Julian> | I think "prefix" is a very bad name for a term in a formal grammar. Terms should have names that describe their semantical function, not their syntactical one. |
| 23:43 | <Julian> | I proposed "sign" as an alternative, but it wasn't liked much. So, do you, in general, agree with s/prefix/$SEMANTICALLY_DESCRIPTIVE_NAME/? |
| 23:44 | <Julian> | If so, we can find another name than "prefix" and "sign". |
| 23:44 | <grumpy> | I don't think it is a big deal, but I tend to agree with your logic. |
| 23:44 | <Julian> | csm: Just 10 more minutes. I'll make it quick. |
| 23:44 | <csm> | alright |
| 23:44 | <grumpy> | "sign", however, is a bad name |
| 23:45 | <grumpy> | and until such time as I hear a better name, I don't want to create the confusion of changing thins now. |
| 23:45 | <grumpy> | things, even |
| 23:45 | <Julian> | I propose "mode". |
| 23:45 | <Julian> | Any comments? |
| 23:45 | <grumpy> | Hmmmm.... I don't much like that one either. "result" is much more descriptive. |
| 23:46 | <grumpy> | or "match-result" |
| 23:46 | <grumpy> | or something. |
| 23:46 | <grumpy> | but I think we shouldn't entertain this motion until such time as we have a word that we want to use instead. |
| 23:46 | <Julian> | Anything that's semantically descriptive is fine with me. That includes "result" and "match-result", although the latter is not very elegant. |
| 23:46 | <Julian> | Ok, agreed. |
| 23:46 | <grumpy> | motion: move this item back to spf-discuss |
| 23:46 | <Julian> | Wait. |
| 23:46 | <grumpy> | tabled |
| 23:47 | <Julian> | Motion: Move this issue back to spf-discuss, noting the general consent that a _semantically_ descriptive name should be sought. |
| 23:48 | <grumpy> | 2346u: motion retracted |
| 23:48 | <grumpy> | 2347u: seconded |
| 23:48 | <Julian> | Votes? |
| 23:48 | <Julian> | 2347u: yes |
| 23:48 | <grumpy> | 2347u yes |
| 23:48 | <MarkK> | 2347u: yes |
| 23:48 | <csm> | 2347u: yes |
| 23:48 | <Julian> | So ordered. |
| 23:48 | <Julian> | Very last item. |
| 23:49 | <Julian> | The "section 9.3.1.2 does not warn about the 63 character limit" issue. I think this one is too complicated to be discussed and decided in 5 minutes. |
| 23:49 | <Julian> | So no motion from me. |
| 23:49 | * | Julian gives the conch to csm. |
| 23:50 | <grumpy> | csm? |
| 23:50 | <csm> | okay so... |
| 23:50 | <csm> | a meeting when? |
| 23:50 | <grumpy> | Soon. |
| 23:50 | <Julian> | I'd be fine with most days. Perhaps Sunday 21:00 UTC? |
| 23:50 | <Julian> | Or Monday 21:00 UTC? |
| 23:50 | <grumpy> | probably no sooner than Friday, but any other day is ok |
| 23:51 | <grumpy> | even saturday is ok with me. |
| 23:51 | <csm> | Sunday? |
| 23:51 | <csm> | MarkK? |
| 23:51 | <MarkK> | weekend would be fine |
| 23:51 | <grumpy> | Sunday then? |
| 23:51 | <csm> | Sunday it is then |
| 23:51 | <Julian> | What would be the main issues for the interim meeting? |
| 23:51 | <Julian> | More I-D hacking? |
| 23:51 | <grumpy> | yes |
| 23:51 | <csm> | blast the list with that info please |
| 23:51 | <Julian> | I'm asking because we need Meng present for most of the important stuff. |
| 23:51 | <csm> | do I hear a motion to adjourn? |
| 23:51 | <Julian> | Sunday 21:00 UTC. |
| 23:52 | <grumpy> | Julian: I don't think we can assume that Meng will be here. |
| 23:52 | <grumpy> | we can't keep waiting |
| 23:52 | <Julian> | Motion: Let's adjourn. |
| 23:52 | <grumpy> | seconded |
| 23:52 | <MarkK> | julian: I think we can almost assume he won't be here :( |
| 23:52 | <grumpy> | 2352u yes |
| 23:52 | <MarkK> | 2352u: yes |
| 23:52 | <Julian> | 2352u: yes |
| 23:52 | <csm> | so ordered |
| 23:52 | <grumpy> | thanks for the meeting! |
| 23:53 | <Julian> | Thanks, too! |
| 23:53 | <grumpy> | the IRC logs will be posted in 7 min (00:00 UTC) |
| 23:53 | <MarkK> | yes, at least we got a few items resolved |
| 23:53 | <grumpy> | Please try and review the draft as much as you can and catch up on spf-discuss if you can. |
| 23:53 | <Julian> | Just for the record, I seriously doubt I'll be able to finish this meeting's minutes before the interim meeting. |
| 23:54 | <grumpy> | ok. |
| 23:54 | <grumpy> | minutes are not as important if there are IRC logs |
| 23:54 | <grumpy> | (IMHO) |
| 23:54 | <Julian> | Yes. |
| 23:54 | <MarkK> | grumpy: I already have been talking about some of this stuff on discuss. :) |
| 23:54 | <grumpy> | MarkK: very true. |
| 23:54 | <Julian> | But reading IRC logs is very tedious. That's why writing the minutes is so tedious. |
| 23:55 | <grumpy> | csm: I would really welcome more draft review from you. You found some good things and you only got through a few pages... |
| 23:55 | <csm> | he-he |
| 23:55 | <grumpy> | Julian: agreed |
| 23:55 | <csm> | I will try to make some time for it |
| 23:55 | <grumpy> | thanks |
| 23:55 | <grumpy> | at least we are moving forward again. |
| 23:55 | <grumpy> | sorry about not getting the I-D out a couple of months ago. |
| 23:56 | <grumpy> | anyway, good night folks. I think I'm going to go out and enjoy the remaining sunshine. |
| 23:56 | <Julian> | Good night. |
| 23:56 | <MarkK> | grumpy: some of this issues are inescapably controversial it seems; it is up to us, of course, after lengthy talks on discuss, to cut the knot, so to speak |
| 23:57 | <grumpy> | MarkK: yes. |
| 23:57 | <MarkK> | goodnight, wayne; I will be heading out too |
| 23:57 | <grumpy> | and, frankly, most of these issues I could accept either way |
| 23:57 | <MarkK> | grumpy: me too; it is almost always possible to find a rationale for either side |
| 23:58 | <MarkK> | ok, goodnight all |
| 23:58 | <Julian> | MarkK: night. |