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.
| 18:51 | <grumpy> | :-< |
| 18:51 | <Julian> | It's not as if MX->CNAME would constitute net abuse or something. |
| 18:53 | <grumpy> | Well, fortunately, the list is pretty small, so you can just email everyone |
| 18:53 | <Julian> | Also, from the bogusmx.rfc-ignorant.org listing policy: "It should also be noted that at this time, hosts with IPv6-only connectivity are considered bogus, as IPv6 is not, at all, prevalent." -- I don't think this blocklist should be taken seriously. |
| 18:53 | <grumpy> | or, you can email me, and I'll forward it on |
| 18:53 | <Julian> | grumpy: Ok. |
| 18:53 | <grumpy> | yeah, I saw that |
| 18:53 | <grumpy> | I've heard of a lot of problems with "rfc-ignorant" |
| 18:54 | <grumpy> | I'm not sure if I use any of their lists, even as part of SA |
| 18:54 | <Julian> | I have no problems with bogus blocklists. Only with people who actually use them. |
| 18:55 | <grumpy> | heh |
| --- Wed Jun 1 20:04:36 UTC 2005 --- |
| 20:04 | * | grumpy pokes his head in |
| 20:04 | <grumpy> | meeting in an hour, right? |
| 20:04 | <Julian> | grumpy: Yeah. |
| 20:52 | <grumpy> | t-8min.... |
| 20:52 | * | grumpy really hopes that freeside and MarkK show up. |
| 20:59 | <grumpy> | hey MarkK! |
| 20:59 | <MarkK> | good evening |
| 20:59 | <Julian> | freeside: ping |
| 21:00 | <MarkK> | (bot wasn't opping me) |
| 21:00 | <MarkK> | I hope Meng is here; otherwise me have no quorum |
| 21:01 | <grumpy> | Well, we did pass the resolution saying that for the I-D stuff, we only need 3 |
| 21:02 | <MarkK> | yes, that is true |
| 21:03 | <grumpy> | Well, how long should we wait for freeside? |
| 21:03 | <Julian> | Has anyone sent him a mail? |
| 21:04 | <grumpy> | you mean besides the email he gets from the spf-council postings? |
| 21:04 | <Julian> | Yes... He seems to need that. |
| 21:04 | <grumpy> | no, I haven't. |
| 21:04 | <Julian> | I can do it. Just a moment. |
| 21:04 | <grumpy> | ok |
| 21:04 | <grumpy> | thanks |
| 21:05 | <grumpy> | does everyone have access to the I-D articles referenced in the agenda? |
| 21:05 | <MarkK> | yes |
| 21:05 | <grumpy> | I notice that listbox.com is down right now. |
| 21:05 | <MarkK> | and is started spewing old posts the other day |
| 21:06 | <Julian> | Message sent. |
| 21:07 | <grumpy> | did it spew old posts? |
| 21:07 | <grumpy> | how many and which ones? |
| 21:07 | <Julian> | grumpy: What do you mean by "I-D articles"? |
| 21:07 | <grumpy> | I released some posts that were held... |
| 21:07 | <Julian> | Oh, you mean the articles in the mailing list's web archive... |
| 21:07 | <grumpy> | yeah |
| 21:08 | <Julian> | Well, I can find them in my own mail archive, but it won't be easy without knowing their message IDs. |
| 21:08 | <grumpy> | Ah, listbox may be up again |
| 21:08 | <Julian> | Yes, it's up. |
| 21:08 | <MarkK> | wayne: you even replied to an old post of Frank, and then told him it was kinda old stuff, lol. :) Well, it was. |
| 21:09 | <grumpy> | Uh, Frank was complaining that we missed that "for SPF council review" post of his. |
| 21:09 | <grumpy> | which is true, I did miss it. |
| 21:10 | <grumpy> | but now I'm not sure why Frank was complaining because it appeared to be mostly old stuff. |
| 21:10 | <MarkK> | I think it was one of the 'BTFOOM' posts you replied to |
| 21:11 | <grumpy> | yes, but it was "for council review: .... (was: BTFOOM)" |
| 21:11 | <MarkK> | yes, but I believe that was actually an inadvertent repost |
| 21:11 | <grumpy> | Hmmmm... |
| 21:11 | <Julian> | We definitely need a different approach for SPFv2.1 (v3, whatever). We need an issue tracking system instead of endless threads on a mailing list. |
| 21:12 | <MarkK> | at at rate, until when will we wait for meng? |
| 21:12 | <MarkK> | at any rate, I meant |
| 21:12 | <Julian> | At least 'til 21:15, I'd say. |
| 21:12 | <grumpy> | Julian: I know that the IETF WG chairs have tools that they use for this kind of stuff. |
| 21:12 | <Julian> | grumpy: We could simply use Bugzilla or the like. |
| 22:24 | <grumpy> | (yowser! we really did have >900 messages last month.) |
| 22:24 | <Julian> | What do you think wrt Frank's #1? Does anybody want to make a motion of it? |
| 22:24 | <grumpy> | Ok, as for Frank's point one, I think we just did that. |
| 22:25 | <grumpy> | To quote from the second message I listed: "-02pre1 does not yet have redirect=invalid as a PermError like |
| 22:25 | <grumpy> | an include:invalid, roughly the rest of my point 1. " |
| 22:25 | <Julian> | So? |
| 22:26 | <Julian> | So no further resolution is required, right? |
| 22:26 | <grumpy> | So, I think we can say that we have (just) accepted that change and move on. |
| 22:26 | <grumpy> | right |
| 22:26 | <Julian> | 2 - other cases of NCDOMAIN or domain literals result in NONE |
| 22:27 | <Julian> | 2 - other cases of NXDOMAIN or domain literals result in NONE |
| 22:27 | <MarkK> | but those are not in the policy |
| 22:27 | <grumpy> | and we have already voted on that issue once |
| 22:27 | <MarkK> | right? |
| 22:27 | <Julian> | I think Frank wants a formal resolution that SPF(non-existent-domain) == PermError will not happen. |
| 22:28 | <Julian> | I can promise that I will not bring this up for SPFv1 anymore, but obviously, I'm not going to make the motion. |
| 22:29 | <Julian> | Does one of you want to make a motion for this? |
| 22:29 | <MarkK> | I once supported that idea, but, for now, am happy to leave those cases to the MTA to decide |
| 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? |
| 22:30 | <Julian> | Well, currently, it is defined that SPF(non-existent-domain) == None. I don't think we need a resolution confirming that. I already promised will not challenge it. |
| 22:30 | <grumpy> | Ok, so we don't need another resolution on this? |
| 22:30 | <Julian> | I don't think so. I just want to be sure you don't, either. |
| 22:31 | <grumpy> | I don't think we need one. |
| 22:31 | <grumpy> | MarkK? |
| 22:31 | <grumpy> | wait. |
| 22:31 | <MarkK> | we already decided on it |
| 22:31 | <Julian> | Not exactly. |
| 22:31 | <grumpy> | MarkK: by "leaving those cases to the MTA to decide", are you referring to Frank's point 2 or point 3? |
| 22:31 | <Julian> | MarkK: We're still at #2. |
| 22:32 | <MarkK> | point 2 |
| 22:32 | <grumpy> | Ok |
| 22:32 | <grumpy> | so, you are saying that it should be up to the MTA to decide if SPF(NXDOMAIN) == None or PermError? |
| 22:33 | <Julian> | Well, MTAs may decide not to perform an SPF check in the NXDOMAIN case, but within the SPF spec, it is defined that SPF(non-existent-domain) == None. |
| 22:33 | <grumpy> | Julian: that is my understanding also |
| 22:33 | <Julian> | So, _if_ an MTA decides to perform an SPF check in this case, the result is None. |
| 22:33 | <grumpy> | Yes. |
| 22:33 | <grumpy> | which is consistent with mengwong-spf-* |
| 22:34 | <MarkK> | julian: I mean, MTA will likely not process the message anyway, as NXDOMAIN in MAIL FROM will not be accepted (at least not by sendmail) |
| 22:34 | <grumpy> | MarkK: yes, but *if* it does process it... |
| 22:34 | <MarkK> | then we proceed with 'none' |
| 22:34 | <Julian> | MarkK: Yes, right. That's also what the spec says in the second to last paragraph of section 2.4. |
| 22:35 | <grumpy> | ok. |
| 22:35 | <Julian> | 3 - Receivers may treat PermError like FAIL, and TempError |
| 22:35 | <Julian> | like SOFTFAIL, SMTP offers error codes 5xx and 4xx resp. |
| 22:35 | <grumpy> | so, we are all on the same page, I think. |
| 22:35 | <MarkK> | yes, we are :) |
| 22:35 | <grumpy> | I disagree with that, and we decided the PermError thing in the last meeting. |
| 22:36 | <Julian> | As for #3, I think receivers should be allowed to treat any result code like any other. It's receiver policy. |
| 22:36 | <Julian> | grumpy: Did we? |
| 22:36 | <MarkK> | I am still vehemently opposed to PermError = 'softfail'. |
| 22:36 | * | Julian too. |
| 22:36 | <grumpy> | yeah, we basically removed the receiver policy out of PermError. |
| 22:36 | <Julian> | Did we actually decide this? I don't think so. |
| 22:37 | <Julian> | (Ok, striky my last sentence.) |
| 22:37 | <grumpy> | A "PermError" result means that the domain's published |
| 22:37 | <grumpy> | records couldn't be correctly interpreted. This signals |
| 22:37 | <grumpy> | an error condition that requires manual intervention to be |
| 22:37 | <grumpy> | resolved, as opposed to the TempError result. Be aware |
| 22:37 | <grumpy> | that if the domain owner uses macros (<xref |
| 22:37 | <grumpy> | target="macros"/>), it is possible that this result is due |
| 22:37 | <grumpy> | to the checked identities having an unexpected format. |
| 22:37 | <grumpy> | Julian: you even wrote up the replacement text. ;-) |
| 22:38 | <Julian> | I think my memory is defunct. |
| 22:38 | <Julian> | You're right. |
| 22:38 | <Julian> | Shame on my memory. |
| 22:38 | <grumpy> | Ok, so the first part of Frank's point 3 has been already decided. |
| 22:38 | <Julian> | All I could remember was that we decided that "treat PermError like SoftFail" would have to go... |
| 22:39 | <Julian> | grumpy: Right. |
| 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. |
| 22:40 | <Julian> | We definitely shouldn't RECOMMEND or REQUIRE that. |
| 22:40 | <MarkK> | certainly not softfail, no |
| 22:40 | <MarkK> | that is really receiver policy |
| 22:40 | <Julian> | Also, I don't think we should "SUGGEST" it, but we might "suggest" TempError --> 4xx. |
| 22:41 | <Julian> | It _might_ not be obvious to do 4xx on TempError. |
| 22:41 | <MarkK> | I am perfectly happy with SHOULD, though, for TempError = 4xx |
| 22:41 | <grumpy> | A "TempError" result means that the SPF client encountered |
| 22:41 | <grumpy> | a transient error while performing the check. Checking |
| 22:41 | <grumpy> | software can choose to accept or temporarily reject the |
| 22:41 | <grumpy> | message. If the message is rejected during the SMTP |
| 22:41 | <grumpy> | transaction for this reason, the software SHOULD use an |
| 22:41 | <grumpy> | SMTP reply code of 451 and, if supported, the 4.4.3 DSN |
| 22:41 | <grumpy> | code. |
| 22:41 | <Julian> | MarkK: I'm not, it's receiver policy. |
| 22:42 | <Julian> | grumpy: I think the current wording is fine if we do s/SHOULD/should/ or something equivalent. |
| 22:42 | <MarkK> | Julian: to me, TempError really intuitively gravitates towards 4xx. :) |
| 22:42 | <Julian> | MarkK: To me, too, but I'm not representative for the audience of the spec. :) |
| 22:42 | <grumpy> | mengwong-spf-01 says SHOULD also. |
| 22:42 | <MarkK> | but 'should' is no big loss |
| 22:43 | <grumpy> | I think the time to have been dogmatic about Sender vs Receiver Policy was a year ago. |
| 22:43 | <grumpy> | I would prefer to leave it unchanged. |
| 22:43 | <grumpy> | Although, actually, the SHOULD right now refers to the SMTP code mand the DSN code |
| 22:43 | <MarkK> | well, not the part about softfail getting 4xx, right? |
| 22:44 | <Julian> | grumpy: I was sort of dogmatic. Perhaps not exactly one year ago, since I was absent for a while during that time. But before and after that, I have always been quite dogmatic about not defining receiver policy. |
| 22:44 | <grumpy> | Yeah, but neither of us had much voice in the spec back then. :-/ |
| 22:44 | <grumpy> | MarkK: SoftFail doesn't get a 4xx right now in the spec. |
| 22:45 | <grumpy> | what I quoted was for TempFail. |
| 22:45 | <Julian> | I think s/SHOULD/should/ is really mostly a cosmetic issue, on a semantic level. |
| 22:45 | <MarkK> | I know; and me want to keep it that way :) |
| 22:45 | <Julian> | I mean, what's the point of keeping "SHOULD" here instead of "should"? |
| 22:45 | <grumpy> | Having investigated those code numbers, I think it should be a SHOULD. |
| 22:46 | <MarkK> | I like the wording for 'TempError' "as is" |
| 22:46 | <grumpy> | because if you don't have a good technical reason to use other SMTP/DSN numbers, you should stick with what is given. |
| 22:47 | <Julian> | grumpy: The thing is, not everyone might recognize that this "SHOULD" only really applies to the choice of the SMTP reply code. |
| 22:47 | <grumpy> | Well, then they need to learn to read. ;-) |
| 22:47 | <Julian> | But I'm not going to make a big issue out of this. Let's keep it as it is. |
| 22:47 | <grumpy> | ok |
| 22:47 | <MarkK> | yes |
| 22:47 | <grumpy> | do we need to vote on this? |
| 22:48 | <Julian> | Do we want a motion confirming the current wording? |
| 22:48 | <Julian> | I'll word one... |
| 22:48 | <Julian> | (to satisfy Frank's third review request) |
| 22:49 | <MarkK> | (btw, waye, I was referring to: [00:39] <grumpy> The second part is that TempError and SoftFail should get 4xx SMTP codes?) |
| 22:49 | <MarkK> | ok... |
| 22:51 | <grumpy> | Julian: are you typing? |
| 22:51 | <Julian> | Sort of, plus thinking. |
| 22:54 | <Julian> | Motion: No receiver policy shall be formally suggested (MAY), recommended (SHOULD), or prescribed (MUST) in the definitions of the "TempError" and "PermError" result codes. In particular, those result codes' definitions shall not explicitly suggest a treatment similar to any other result codes. |
| 22:55 | <Julian> | (I fear this is not entirely compatible with "if ... SHOULD use an SMTP reply code of 451", though... Ugh.) |
| 22:56 | <MarkK> | wait |
| 22:56 | <Julian> | (Any suggestions on how to make an exception for these SMTP reply code recommendations in the above motion?) |
| 22:56 | <grumpy> | Motion: the current language for PermError and SoftFail is fine and we should move on. |
| 22:56 | * | grumpy is only have serious with tha tmotion... |
| 22:57 | <grumpy> | that motion, even |
| 22:57 | <MarkK> | instead of giving explict 451, etc. codes, can we not say "SHOULD send 4xx/5xx" codes", and leave the exact numbers to receiver policy? |
| 22:57 | <Julian> | grumpy: The problem with "the current language is fine"-style motions is that they preclude the possibility of changing other parts of the language later. |
| 22:59 | <grumpy> | Well, *if* you can convince one of the people to change their vote, then you can re-open an old issue. |
| 22:59 | <Julian> | MarkK: We could (I'm really indifferent on that), but that would not resolve the problem that my above motion could be interpreted to preclude _any_ "SHOULD" whatsoever in the TempError and PermError definitions, which is not what I want to say. |
| 22:59 | <Julian> | Ok, one more try: |
| 22:59 | <Julian> | ... |
| 23:00 | <Julian> | Motion: No receiver policy shall be formally suggested (MAY), recommended (SHOULD), or prescribed (MUST) in the definitions of the "TempError" and "PermError" result codes. In particular, those result codes' definitions shall not explicitly suggest a treatment similar to any other result codes. However, formal recommendations for the choice of SMTP reply codes shall be included. |
| 23:00 | <Julian> | (I added the last sentence.) |
| 23:00 | <MarkK> | Julian: I do not think we can really be without indicating some sort of required action. |
| 23:01 | <Julian> | Well, there's a difference between making _formal_ recommendations and _informal_ ones. |
| 23:02 | <Julian> | (formal == RFC 2119, I think that should be clear, right?) |
| 23:02 | <MarkK> | s/SHOULD/should/, you mean? |
| 23:02 | <MarkK> | right |
| 23:02 | <Julian> | MarkK: No... My motion implies that the current wording is fine. |
| 23:02 | <MarkK> | ok then, all the better :) |
| 23:03 | <MarkK> | yes, I now see the last sentence (sorry, missed it) |
| 23:03 | <grumpy> | 2300u seconded |
| 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 |
| 23:03 | <Julian> | Thanks. |
| 23:03 | <grumpy> | Ok, so we are finished with Frank's stuff, right? |
| 23:04 | <Julian> | Wait a second. |
| 23:04 | <Julian> | Yes, I think so. |
| 23:05 | <grumpy> | And this, I think, is similar to what we discussed in the last meeting, only with Neutral instead of Pass. |
| 23:05 | <Julian> | I need to skim that again. |
| 23:05 | <grumpy> | and I think we discussed it in our pre-meeting also. |
| 23:05 | <Julian> | Yes. |
| 23:06 | <MarkK> | Ah yes; I suggest this rewording (right before the official start of the meeting): 'confidence in the legitimacy of the use of identity by the relay'. |
| 23:07 | <Julian> | IMO, authorized shared MTAs resulting in Pass is a non-issue, really. |
| 23:07 | <MarkK> | authorized? always, yes. |
| 23:08 | <Julian> | *thinking* |
| 23:08 | <grumpy> | ditto |
| 23:08 | <grumpy> | MarkK: can you put that wording into the Neutral paragraph? |
| 23:09 | <MarkK> | no, this was meant for 'pass' |
| 23:09 | * | grumpy could live with Neutral being defined the way it is, but could also accept Scott's suggested wording. |
| 23:09 | <grumpy> | Oh |
| 23:09 | <grumpy> | "nevermind!" |
| 23:09 | <Julian> | I think the semantics of Scott's suggestion are good, but I also think it is more verbose than necessary. I can try to find a different wording. |
| 23:10 | <grumpy> | I think it is also a little restrictive to just one special case. |
| 23:10 | <MarkK> | I think what it boils down to, as detractors like Douglas Ottis (sp?) have pointed out, that we should back away more from saying SPF 'authenticates' things. |
| 23:10 | <Julian> | grumpy: Yes, I think the intended semantics can be expressed in a more general way. |
| 23:11 | <Julian> | MarkK: I don't think we are saying that anywhere, do we? |
| 23:11 | <grumpy> | MarkK: If I understand DougO's point, CSV mandates responsibility, while SPF doesn't. |
| 23:11 | <Julian> | (...even though I think SPF should be able to express that.) |
| 23:11 | <grumpy> | Hence, CSV is better than SPF because you can take action against CSV publishers (by putting them on MAPS and such.) |
| 23:12 | <MarkK> | julian: yes, we are: where we say we 'can proceed with confidence in the identity' suggest authenticity |
| 23:12 | <Julian> | grumpy: The thing is, receivers will do the same with SPF-authorized domains anyway. |
| 23:13 | <grumpy> | Receivers will do the same with domains that don't use SPF or CSV. |
| 23:13 | <grumpy> | I think MarkK's suggestion for changing the language for Pass is a good idea. |
| 23:14 | <MarkK> | It was one of the thing DougO was raving about |
| 23:14 | <grumpy> | Unless someone objects, I think I will encorporate it. |
| 23:14 | <grumpy> | to be quite honest, I have long ago given up greading most of what DougO writes. |
| 23:15 | <MarkK> | lol |
| 23:15 | <grumpy> | At best, I skim. |
| 23:16 | <MarkK> | he was rather fierce, actually; but he did not seem to understand SPF really well, to be honest; but I digress. |
| 23:16 | <Julian> | (pasting text, so take care...) |
| 23:16 | <MarkK> | Can we have a motion to accept my rewording? |
| 23:16 | <Julian> | 2.5.2. Neutral |
| 23:16 | <Julian> | The domain owner has explicitly stated that they |
| 23:16 | <Julian> | - don't know |
| 23:16 | <Julian> | + cannot or do not want to assert |
| 23:16 | <Julian> | whether the IP address is authorized or not. A "Neutral" result MUST be |
| 23:16 | <Julian> | treated exactly like the "None" result; the distinction exists only |
| 23:16 | <Julian> | for informational purposes. Treating "Neutral" more harshly than |
| 23:16 | <Julian> | "None" will discourage domain owners from testing the use of SPF |
| 23:17 | <Julian> | records (see Section 9.1). |
| 23:17 | <Julian> | -- |
| 23:17 | <grumpy> | I like that |
| 23:17 | <Julian> | If we want, we could add a pointer to section 10.4. It might be of some value. |
| 23:18 | <MarkK> | yes, that is the 'cognizance', translated to plain English. :) Good and clear wording, this way. |
| 23:18 | <grumpy> | I would s/they cannot/they either cannot/ |
| 23:18 | <Julian> | This suggestion of mine also gets rid of the mindless "don't know", BTW. :-) |
| 23:18 | <MarkK> | except that domain owner is singular, and 'they', etc is plular |
| 23:19 | <MarkK> | plural, even |
| 23:19 | <Julian> | grumpy: I don't think adding "either" is necessary. Not even from a stylistic POV. Do you think otherwise? |
| 23:19 | <grumpy> | the singular "they" has a very long history. |
| 23:19 | <Julian> | MarkK: "they" is used in order not to discriminate males and females. |
| 23:19 | <MarkK> | ok; if ok in formal language, then nevermind |
| 23:20 | <Julian> | AFAIK this is common wording. |
| 23:20 | <MarkK> | Otherwise, I like the new wording |
| 23:20 | * | grumpy thinks english should bring back the gender neutral "were"... (as in weregilt and werewolf) |
| 23:20 | <Julian> | Heh. |
| 23:20 | <Julian> | grumpy: Do you think we need "either" in it? |
| 23:20 | <grumpy> | Julian: there is a lot of contention over the singular they. |
| 23:21 | <grumpy> | I think it reads better. |
| 23:21 | <grumpy> | I don't think it is critical |
| 23:21 | <MarkK> | But before we vote on this, can we have also a motion to accept my rewording for 'pass'? |
| 23:21 | <Julian> | grumpy: I know, but I tend to like singular "they". Is there an alternative solution? |
| 23:21 | <Julian> | MarkK: What wording was that again? |
| 23:21 | <grumpy> | oh, there are dozens of other alternatives, none of them as good IMHO. |
| 23:22 | <Julian> | http://en.wikipedia.org/wiki/Singular_they |
| 23:23 | <MarkK> | Julian: 'confidence in the legitimacy of the use of identity by the relay' |
| 23:23 | <MarkK> | for 'pass' |
| 23:23 | <MarkK> | so as to say: "can proceed with 'confidence in the legitimacy of the use of identity by the relay'". |
| 23:23 | <Julian> | Hmm. |
| 23:24 | <Julian> | You really want to remove the last remains of "authenticity" from the definition of Pass= |
| 23:24 | <Julian> | ? |
| 23:24 | <MarkK> | yes; 'can proceed with confidence in the identity' suggest authenticity. |
| 23:25 | <MarkK> | and we really cannot back that up |
| 23:25 | <Julian> | The thing is, SPF is really a lot less useful without the concept of authenticity. |
| 23:26 | <Julian> | And the only thing that keeps SPF from being able to assert authenticity is cross-user forgery, right? |
| 23:26 | <grumpy> | From mengwong-spf-01: |
| 23:26 | <grumpy> | Pass (+): the message meets the publishing domain's definition of |
| 23:26 | <grumpy> | legitimacy. MTAs proceed to apply local policy and MAY accept or |
| 23:26 | <grumpy> | reject the message accordingly. |
| 23:26 | <MarkK> | But then we are writing checks our SPF records can't cash |
| 23:26 | <MarkK> | yes, the 'cross-domain/user' ambiguity |
| 23:27 | <Julian> | grumpy: Yes, and I think this old definition of Pass very well implies authenticity. It puts the burden of responsibility on the domain owner. If a domain owner doesn't want to accept responsibility, he shouldn't authorize. |
| 23:27 | <Julian> | ...an insecure MTA. |
| 23:28 | <MarkK> | SPF, as far as I see it -- though meng had a sudden change of heart -- is the most useful at detecting FAIL, not PASS, IMHO. |
| 23:28 | <Julian> | If we define SPF not to assert authenticity of some sort, we can kiss this whole reputation thing good bye. |
| 23:28 | <Julian> | ...and I would really be sorry for that. |
| 23:29 | <grumpy> | I think that SPF is useful for both Pass and Fail, and we are stuck having Neutral/SoftFail due to real world constraints. |
| 23:29 | <grumpy> | Should we go back and finish up Neutral before we continue with Pass? |
| 23:30 | <MarkK> | But can we honestly claim authenticity? My server alone carries around 20 or so domains I host, all using my relay, with my SPF records; I can guarentee authorization, not authenticity per se |
| 23:30 | <MarkK> | Imagine what a big ISP has |
| 23:30 | <Julian> | If the cross-user forgery thing is the only issue that keeps us from asserting authenticity, we should instead find a way to make it clear to publishers that they must assume responsibility if they authorize an MTA. |
| 23:31 | <Julian> | grumpy: Yes, let's go back and finish Neutral. |
| 23:32 | <grumpy> | ok |
| 23:32 | <Julian> | Motion: Section 2.5.2, "Neutral" =~ s/don't know/cannot or do not want to assert/. |
| 23:33 | <grumpy> | 2332u seconded |
| 23:33 | <Julian> | Votes? |
| 23:33 | <grumpy> | 2332u yea |
| 23:33 | <Julian> | 2332u: yes |
| 23:33 | <MarkK> | 2332u: yes |
| 23:33 | <Julian> | So ordered. |
| 23:33 | <grumpy> | ok, back to Pass. |
| 23:33 | <Julian> | Ok. |
| 23:33 | <Julian> | I'll repeat my last statement: |
| 23:33 | <Julian> | If the cross-user forgery thing is the only issue that keeps us from asserting authenticity, we should instead find a way to make it clear to publishers that they must assume responsibility if they authorize an MTA. |
| 23:34 | <Julian> | I know this is difficult with shared MTAs. But it's the only way we can base reputation on SPF Pass. |
| 23:35 | * | grumpy researches |
| 23:35 | <Julian> | For one thing, if people are patching their MTAs to get SPF functionality, they can patch them with cross-user forgery prevention, too. |
| 23:36 | <MarkK> | I do not see how the publisher can; only the MTA (in fact, I do, as I have ppl use SMTP AUTH, and rewrite identities to conform if need be; but not every MTA does that, and certainly the publisher has no handle on that). |
| 23:37 | <Julian> | I agree that it is difficult. But consider this: it's the only way we can base reputation on SPF Pass. Are we really willing to lose this? |
| 23:38 | <MarkK> | If I am to be completely honest, with SPF as it stands now, we cannot guarantee authenticity (yet). |
| 23:39 | <MarkK> | unless we made cross-user forgery prevention part of the spec |
| 23:39 | <grumpy> | I agree with MarkK |
| 23:39 | <Julian> | MarkK: No, I dont' think this is the case. |
| 23:39 | <Julian> | ... |
| 23:40 | <Julian> | What we really need to do in the spec is to require domain owners to accept responsibility for the use of their identity by the MTAs they authorize. It is _their_ choice which MTAs to authorize. |
| 23:40 | <MarkK> | Julian: an MTA may well be patched; but there is no real way for the receiver to know such a cross-user anti-forgery is in place. |
| 23:41 | <Julian> | It may be necessary to point out the cross-user forgery problem in the definition of "Pass", but in the end, it is their choice. |
| 23:41 | <MarkK> | But it is the receiver who must make the determination on whether the identity is authentic; and he can't. |
| 23:42 | <grumpy> | I think William suggested we just delete the second sentence out of the defintion of Pass. |
| 23:42 | <Julian> | If the domain owner asserts authenticity, the receiver _can_. |
| 23:42 | <Julian> | grumpy: But that would just be political correctness through making the meaning of "Pass" fuzzy. |
| 23:42 | <Julian> | s/fuzzy/unclear/ |
| 23:43 | <Julian> | Bluntly, I am not willing to give up the reputation feature. I'd really _hate_ to do that. |
| 23:43 | <MarkK> | Bluntly: I want us to be completely honest :) |
| 23:44 | <Julian> | Besides, mengwong-spf-* already implied authenticity for Pass. |
| 23:44 | <grumpy> | I'm not sure I agree with that |
| 23:44 | <Julian> | MarkK: I want to be honest, too. |
| 23:44 | <MarkK> | julian; I know; that is why we cannot claim authenticity |
| 23:45 | <Julian> | MarkK: We can, if the domain owner accepts responsibility. |
| 23:45 | <Julian> | MarkK: After all, define "authenticity". |
| 23:45 | <MarkK> | 'authentic |
| 23:47 | <MarkK> | 'authentic', in this context, means: 'confidence in the identity', as opposed to 'confidence in the ligitimacy of the relay to use the identity'. We cannot claim the former, but we can the latter. |
| 23:47 | <Julian> | The domain owner can "claim" (assert) the former. |
| 23:48 | <Julian> | grumpy: William's "can now use the identity" is just politically correct for "authentic", too. |
| 23:48 | <Julian> | It means the same. |
| 23:48 | <grumpy> | I don't agree. |
| 23:49 | <MarkK> | no, william's wording is awefully close to mine: 'can proceed with confidence in the legitimacy of the use of identity by the relay'. |
| 23:49 | <Julian> | So you are saying the SPF spec should suggest the use of an identity for reputation purposes even though it can NOT be considered authentic? |
| 23:49 | <grumpy> | Authentic means that it isn't forged. We can't say that. We can say that the probability of it being forged is low enough to be acceptable to the domain owner to allow authorization. |
| 23:50 | <grumpy> | Julian: yes. |
| 23:50 | <MarkK> | I agree |
| 23:50 | <Julian> | grumpy: Only the identity owner can define "forged". |
| 23:50 | <MarkK> | Ok, I do not think it will be carried yet, but let me make a formal motion of it anyway, to have it on record. Motion: s/can proceed with confidence in the identity/can proceed with confidence in the legitimacy of the use of identity by the relay/. |
| 23:50 | <grumpy> | MarkK: I dislike the "by the relay" part. |
| 23:50 | <grumpy> | it may not be a relay |
| 23:51 | <MarkK> | then we can drop it |
| 23:51 | <grumpy> | ok |
| 23:51 | <MarkK> | New Motion: s/can proceed with confidence in the identity/can proceed with confidence in the legitimacy of the use of identity/. |
| 23:51 | <grumpy> | I would support MarkK's motion. |
| 23:51 | <Julian> | *sigh* |
| 23:51 | <grumpy> | s/legitimacy/legitimate/ |
| 23:52 | <Julian> | I don't think it would be representative for the SPF community if we adopted this motion. |
| 23:52 | <Julian> | (Besides, I would word it differently.) |
| 23:53 | <Julian> | ("can proceed with confidence in the legitimate use of the identity") |
| 23:53 | <grumpy> | Julian: I think this was discussed quite a bit, and I don't think the "accepts responsibility" version of Pass was well accepted either... |
| 23:53 | <MarkK> | julian: I like that wording too |
| 23:53 | <grumpy> | Yeah, I like Julian's wording slightly better. |
| 23:53 | <Julian> | So, am I now supposed to filibuster this motion? |
| 23:53 | <grumpy> | heh |
| 23:54 | <grumpy> | Julian: what do you think the SPF communities consensus thinking on this issue is? |
| 23:54 | <MarkK> | I do not want to put you on the spot, julian; but I want it on record, as I feel strongly about it |
| 23:54 | <Julian> | (BTW, I think Meng would be frustrated if we discarded the concept of authenticity. Not that this was a good argument for anything.) |
| 23:54 | <grumpy> | I think if Meng cared, he would be here right now. |
| 23:55 | <Julian> | grumpy: I'm not sure what the consensus is, but I think the consequences aren't understood nearly well enough.) |
| 23:55 | <MarkK> | I do not think mengwong-spf* ever really included authenticity |
| 23:55 | * | grumpy agrees with MarkK |
| 23:55 | <Julian> | I'm not sure what the consensus is, but I think the consequences aren't understood nearly well enough. |
| 23:55 | <grumpy> | Actually, mengwong-spf used authentic instead of authorized almost everywhere. |
| 23:56 | <grumpy> | Well, can we throw this back to spf-discuss and agree to meet again before Monday? |
| 23:56 | <MarkK> | Well, then he was wrong. :) |
| 23:56 | <Julian> | Personally, I must say that if SPF can't provide authenticity (by requiring the identity owner to assert it), most of my interest in SPF will be gone. |
| 23:56 | <MarkK> | Yikes |
| 23:56 | <Julian> | grumpy: Yes, I'd be content with moving this issue back to spf-discuss. |
| 23:56 | <grumpy> | The two week pseudo-last-call is over this Friday, but I don't want to submit anything to the IETF until Monday. |
| 23:57 | <grumpy> | When should we meet? |
| 23:57 | <grumpy> | and is this ok with MarkK? |
| 23:57 | <Julian> | MarkK: I'm not saying this to change your opinions. I'm saing it because it is the truth. A significant part of my interest in SPF always was due to the reputation thing. |
| 23:57 | <MarkK> | then we should probably adjourn now soon |
| 23:58 | * | Julian looks up his calendar. |
| 23:58 | <grumpy> | I think that the motion is worded in a way that I like, but I'm not 100% confident that it represents the SPF community. |
| 23:58 | <MarkK> | Julian: I understand; but, truth be told, I have always felt uncomfortable with SPF claiming authenticity. |
| 23:59 | <grumpy> | (it is what, 1AM for you two?) |
| 23:59 | <MarkK> | 2 AM |
| 23:59 | <Julian> | 2am |
| 23:59 | <grumpy> | me too! |
| 23:59 | <grumpy> | Ugh, it is *really* late for you... |
| 23:59 | <Julian> | grumpy: Are you in Europe? |
| 23:59 | <grumpy> | no |
| 23:59 | <grumpy> | central US. The sun is still (barely) up. |
| 23:59 | <Julian> | grumpy: So, your "me too" applied to something else, I guess... ;-) |
| --- Thu Jun 2 00:00:01 UTC 2005 --- |
| 00:00 | <MarkK> | I think the 'me too' was in agreement with me, right? |
| 00:00 | <MarkK> | (or so I hope; lol) |
| 00:00 | <grumpy> | Oh, the "me too!" was in reference to MarkK being unconfrotable with SPF claiming authenticity |
| 00:00 | <grumpy> | yes. |
| 00:00 | <Julian> | I can see your reasons. But I think we should try to find a way to make authenticity work, or at least be very, very, *very* sure about the consequences. |
| 00:01 | <grumpy> | Ok, so do we want to bounce it back to spf-discuss? |
| 00:01 | <Julian> | Many people may lose interest if SPF can't support reputation. |
| 00:01 | <Julian> | Yes. |
| 00:01 | <grumpy> | oh, meeting time. |
| 00:01 | <MarkK> | yes, lets bounce it back |
| 00:01 | <grumpy> | I'm able to do just about any time, except for Friday. |
| 00:01 | <Julian> | Motion: Move discussion about asserting authenticity back to spf-discuss. |
| 00:02 | <MarkK> | wait |
| 00:02 | <Julian> | grumpy: The same goes for me, anything except Friday is ok. |
| 00:03 | <MarkK> | perhaps we should make it a 'call to arms' or something, I mean, so as to alert ppl to the issue, can solicit their (quick) feedback (quick, if we want to have it resolved before monday). |
| 00:03 | <grumpy> | MarkK: I agree |
| 00:03 | <Julian> | Ok. |
| 00:03 | <Julian> | Feel free to modify my motion. :) |
| 00:04 | <grumpy> | So, should I second 0001u? |
| 00:04 | <MarkK> | Motion: invite ppl on discuss to speak out, with some degree of urgency, on the matter of authentication. |
| 00:04 | <grumpy> | 0004u seconded |
| 00:04 | <Julian> | Votes? |
| 00:04 | <Julian> | 0004u: yes |
| 00:04 | <grumpy> | 0004u yea |
| 00:05 | <MarkK> | 0004u: yes |
| 00:05 | <grumpy> | Ok, meeting time? |
| 00:05 | <grumpy> | Sunday? |
| 00:05 | <Julian> | One of us should write a "call to arms" message introducing the issue with a neutral POV. |
| 00:05 | <grumpy> | it can be something reasonable for you guys... |
| 00:05 | <Julian> | 21:00 UTC is fine for me. |
| 00:05 | <grumpy> | Julian: a neutral point of view? that would be unamerican. |
| 00:05 | <MarkK> | I can write that call, julian |
| 00:06 | <MarkK> | I will run it by you on our private list first |
| 00:06 | <Julian> | MarkK: Ok. We can add our subjective opinions in separate messages as replies to the introductory message. |
| 00:06 | <grumpy> | MarkK: is 2100UTC Sunday ok with you? |
| 00:06 | <MarkK> | yes, that would be fine |
| 00:06 | <grumpy> | ok |
| 00:07 | <Julian> | Motion: Next meeting shall be on Sunday, 2005-06-05, at 21:00 UTC. |
| 00:07 | <grumpy> | 0007u seconded |
| 00:07 | <Julian> | Votes? |
| 00:07 | <MarkK> | wayne: if the irc log is available soon, I could refer to it also |
| 00:07 | <grumpy> | 0007u yea |
| 00:07 | <Julian> | 0007u: yes |
| 00:07 | <MarkK> | 0007u: yes |
| 00:07 | <Julian> | So ordered. |
| 00:07 | <Julian> | Motion: Adjourn. |
| 00:07 | <grumpy> | Hmmm... the IRC log *should* have been sent to the list 7 minutes ago. |
| 00:07 | <grumpy> | 0008u seconded |
| 00:08 | <MarkK> | 0008u: yes |
| 00:08 | <grumpy> | 0008u yes |
| 00:08 | <Julian> | 0008u: yes |
| 00:08 | <grumpy> | Thanks much guys. |
| 00:08 | <grumpy> | very productive. |
| 00:08 | <Julian> | So ordered. We're adjourned. |
| 00:08 | <MarkK> | wayne: must be that ECN thingy :) |
| 00:08 | <grumpy> | :-) |
| 00:08 | <Julian> | What was that "ECN" again? |
| 00:08 | <grumpy> | Well, I messed around with the script a little bit to try and avoid publishing those blank logs. |
| 00:08 | <grumpy> | ECN == Explicit Congestion Notification. |
| 00:09 | <grumpy> | Something that Linux uses by default now, but some old OSes/routers/etc barf on. |
| 00:09 | <Julian> | I see. |
| 00:09 | <MarkK> | On that note, I will adjourn to bed; as it is really late here |
| 00:09 | <grumpy> | talk to ya later. |
| 00:10 | <MarkK> | thanks, guys. |
| 00:10 | <MarkK> | goodnight |
| 00:10 | <Julian> | CU later, indeed. I will tend to the outstanding minutes soon. |