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.
| 20:56 | <freeside> | thanks |
| 20:58 | <grumpy> | yes, thanks Julian... |
| 20:58 | * | grumpy should still have that message in a buffer somewhere, but... |
| 21:00 | <MarkK> | good evening |
| 21:00 | <grumpy> | Hey MarkK! |
| 21:00 | <grumpy> | ok, so we are all here right on time? |
| 21:00 | <freeside> | moo |
| 21:00 | <grumpy> | csm? |
| 21:01 | <MarkK> | julian? |
| 21:01 | <Julian> | I'm here. |
| 21:01 | <csm-laptop> | the meeting will comew to order |
| 21:01 | <MarkK> | goodie :) we're fill house again |
| 21:01 | <csm-laptop> | we have no minuted right? |
| 21:01 | <Julian> | Just sent off a final message before the meeting. |
| 21:01 | <csm-laptop> | minutes |
| 21:01 | <MarkK> | full, even |
| 21:01 | <Julian> | csm: No, sorry. |
| 21:01 | <csm-laptop> | no worries |
| 21:01 | <csm-laptop> | okay |
| 21:01 | <Julian> | I have been busy working on the spec. |
| 21:01 | <csm-laptop> | the Chair has only one item... |
| 21:02 | <csm-laptop> | freeside: you got my email today? |
| 21:02 | <freeside> | yes |
| 21:02 | <csm-laptop> | good... |
| 21:02 | <csm-laptop> | that's it... next item is the ED's report |
| 21:02 | <freeside> | ok |
| 21:03 | <freeside> | let's see, so i'm back from presenting at an antispam conference in tokyo from a couple weeks ago |
| 21:03 | <freeside> | did i talk about that yet already? |
| 21:03 | <csm-laptop> | I don't think so |
| 21:03 | <Julian> | I don't know about the outcomings. |
| 21:03 | <grumpy> | I don't think you did |
| 21:03 | <freeside> | there were a lot of japanese ISPs represented, and i got to meet a number of them, including Nifty and IIJ. they seemed keen to roll out SPF and DK and so on. |
| 21:03 | <csm-laptop> | we're eager to hear though |
| 21:04 | <csm-laptop> | good |
| 21:04 | <freeside> | IIJ did some studies and found that adoption was, predictably, a little lower than in the US :) |
| 21:04 | <Julian> | Are they eager to roll out Sender-ID, too? |
| 21:04 | <freeside> | so i hit them with the keynote, which was basically "look, here's SPF, here's DK, this is what sender authentication is about, and we need reputation, and btw, if all the stuff we're trying doesn't work, think about rss/email" |
| 21:05 | <freeside> | i didn't hear about PRA checking, i think their attitude is that they'll just do whatever works. but that's just my guess. |
| 21:05 | <freeside> | the architect perspective is "is this the best thing for everyone?" the implementor perspective is "ok, how much work and how well will it work for me?" |
| 21:05 | <freeside> | most of the people i've talked to have been more concerned about the implementor perspective. |
| 21:05 | <freeside> | so anyway, next week is Inbox, in San Jose. If anybody from the SPF community wants to go, I have one (1) free ticket |
| 21:06 | <freeside> | (i'll be there) |
| 21:06 | <Julian> | freeside: Why don't you offer it on spf-discuss? |
| 21:06 | <freeside> | and next month in Dusseldorf is MAAWG |
| 21:06 | <freeside> | i will, i just got the free ticket offer. |
| 21:06 | <freeside> | waiting to hear what promo code to use, etc. |
| 21:06 | <freeside> | mmm |
| 21:07 | <Julian> | Re MAAWG: ... |
| 21:07 | <freeside> | from observations of antispam vendors, most people have already implemented SPF for Mail From, and are using it as a selling feature. |
| 21:07 | <freeside> | http://www.maawg.org/ june 21 to 23 in dusseldorf |
| 21:08 | <freeside> | that's my report for now, though i reserve the right to say "oh wait, sorry, BLURT" later |
| 21:08 | <Julian> | I heard from Wayne that they're seeking for speakers on SPF. |
| 21:08 | * | grumpy heard it from Andy, who heard it from ... ;-) |
| 21:08 | <freeside> | i'll check with them. |
| 21:08 | <MarkK> | I have a conference in the States, actuall, from June 12th to 'unknown' yet (aroumd the 20th). I hope I can make it back in time. |
| 21:08 | <Julian> | grumpy: They still haven't contacted me (and neither Mark, probably). |
| 21:08 | <csm-laptop> | okay... before we move on I believe there were a couple of IETF related questions for freeside? |
| 21:09 | <freeside> | just caught up on the ted hardie thread, btw |
| 21:09 | <grumpy> | Well, I have one.... |
| 21:09 | <MarkK> | csm: can I have the fllor for one question? |
| 21:09 | <csm-laptop> | MarkK: go |
| 21:09 | * | Julian has a question, too. |
| 21:09 | * | Julian will wait, though. |
| 21:09 | <grumpy> | freeside: do you know who authorized the RFC note about removing the "NOT RECOMMENDED" sentence? |
| 21:09 | <MarkK> | For the record, Meng, I want to ask you: were you the one who added -- or caused to be added -- the infamous "RFC Editor Note"? There is some confusion on whether members of the IESG added it (like Ted Hardie), or whether it was one us 'us' (read: wayne, or you, or even, indirectly, MarkL). |
| 21:09 | <freeside> | what RFC note? |
| 21:10 | <freeside> | i haven't written to any of the IETF guys in the last few weeks, so i doubt it was me |
| 21:18 | <freeside> | so, let's talk about the next-gen server, with usemod wiki. |
| 21:18 | <Julian> | I'm willing to do the work, however: 1. do you want me to take on the job of finding and setting up a non-pobox staging server, too? |
| 21:18 | <freeside> | debian system with ip and root should be easy. |
| 21:18 | <freeside> | we can rent a box like that at a colo place, can't we? |
| 21:19 | <freeside> | i'll pay for it, you can run it, and i can point spf.pobox.com to it. |
| 21:19 | <Julian> | 2. Would you want to provide a server, chroot, virtual machine, whatever (with separate IP address and root access) for the permanent site? |
| 21:19 | <Julian> | you = at pobox |
| 21:19 | <MarkK> | I thought csm have some machines to offer? |
| 21:19 | <freeside> | subject to not breaking existing urls, like spf.pobox.com/whitepaper.pdf, etc. |
| 21:19 | * | grumpy agrees about not breaking urls |
| 21:19 | <Julian> | freeside: We do have non-pobox offers. I just thought you wanted to host it at pobox. |
| 21:19 | * | grumpy likes mod_rewrite |
| 21:20 | <Julian> | Not breaking URLs is easy. |
| 21:20 | <freeside> | oh, "host". the box can live anywhere. i am happy to host the url spf.pobox.com, in that i can point it anywhere you'd like ... |
| 21:20 | <freeside> | i'd rather the box not live at pobox, physically. |
| 21:20 | <grumpy> | Ah. |
| 21:20 | <freeside> | so we should take people up on whatever offers were made. |
| 21:21 | <Julian> | freeside: Ok. Then what was it about when you said you wanted to "host" the site? Do you just care about the URL(s) staying constant? |
| 21:21 | <freeside> | yes, that's what i meant. |
| 21:21 | <grumpy> | btw, I got an offer from JohnP today to do hosting. I think we are up to a dozen offers now. ;-) |
| 21:21 | <Julian> | "i'd rather the box not live at pobox, physically." --- Ohhh, now I see what you meant. |
| 21:21 | <Julian> | Ok, issue cleared. I'll solicit hosting offers then. |
| 21:22 | <Julian> | Great, I'm finished. |
| 21:22 | <grumpy> | ok, next up? |
| 21:22 | <Julian> | (grumpy: We can use some mirrors.) |
| 21:22 | <csm-laptop> | next issue is...Estabilish a short-term "committee" to rule in the SPF I-D issues? |
| 21:22 | <freeside> | right, sorry, "host" is complex. i believe Paris Hilton threw a New Years Eve party last year, but was unable to actually attend it herself. she still hosted it, though! :) |
| 21:23 | <grumpy> | In light of upcoming vacations and such, and with the draft being *almost* done, what do you guys think of creating a short term committee to rule on these issues? |
| 21:23 | <csm-laptop> | I like the idea |
| 21:24 | <csm-laptop> | put Frank on it! |
| 21:24 | <csm-laptop> | ;-) |
| 21:24 | <freeside> | can't we just submit it in a way that the IESG will approve? |
| 21:24 | <Julian> | I think it is sub-optimal, but I guess it's the best we can do to get the spec done ASAP. |
| 21:24 | <freeside> | sorry, i'm just thinking it's time to make some compromises. |
| 21:24 | <Julian> | freeside: There are still some issues to be decided by the council, and we might not have quorum during the next 20-30 days. |
| 21:25 | <Julian> | I want to make another proposal |
| 21:25 | <grumpy> | shoot |
| 21:25 | <Julian> | We could lower the quorum to 3 for SPF I-D related issues. |
| 21:25 | <MarkK> | I thought grumpt meant a sub-section of the council |
| 21:25 | <grumpy> | I was think of that also. |
| 21:25 | <freeside> | sounds good to me. |
| 21:26 | <MarkK> | yep |
| 21:26 | <Julian> | It's not that I don't trust the guys outside the council, but for a committe we would probably have to select the people to be on it, and then vote to approve the selection. |
| 21:26 | <grumpy> | yeah, it needs to be done *quick* |
| 21:27 | <Julian> | That would take another 2-3 days, so... dang! |
| 21:27 | <grumpy> | that is why I suggested just using the list of candidates |
| 21:27 | <MarkK> | the process would probably take longer than the vacation time |
| 21:27 | <grumpy> | it isn't a perfect way of selecting people, but it is already done. ;-) |
| 21:28 | <Julian> | Any preferences wrt the 2 proposals (Wayne's and mine)? |
| 21:28 | <grumpy> | motion: for SPF I-D related items, the quorum will be lowered to three until the end of June. |
| 21:28 | <MarkK> | 2128u: seconded |
| 21:28 | <freeside> | 2128u: yes |
| 21:28 | <csm-laptop> | votes? |
| 21:28 | <grumpy> | 2128u yes |
| 21:28 | <Julian> | 2128u: yes |
| 21:28 | <MarkK> | 2128u: yes |
| 21:28 | <grumpy> | ok |
| 21:28 | <csm-laptop> | motion carried |
| 21:28 | <csm-laptop> | so ordered |
| 21:28 | <Julian> | As always, the council will be guided by the input from the community. |
| 21:29 | <grumpy> | right |
| 21:29 | <csm-laptop> | next item is The SPF specification draft and the IETF: |
| 21:29 | <csm-laptop> | grumpy? |
| 21:29 | <grumpy> | ok, first up |
| 21:29 | <grumpy> | ... |
| 21:30 | <grumpy> | >> For SPF council review: Syntax error = Perm error = Message should be rejected? |
| 21:30 | <grumpy> | >> Scott Kitterman (Sat Apr 30 2005 - 16:54:21 EDT) |
| 21:31 | <MarkK> | which is 'none' |
| 21:31 | <grumpy> | Ok, in draft-mengwong-spf-0[01], it says that PermError MUST be treated as None |
| 21:31 | <grumpy> | the draft-schlitt-spf-classic-00 (and draft-lentczner-) said it should be rejected |
| 21:31 | <freeside> | what did 00 say? |
| 21:32 | <grumpy> | in -01pre6, I changed things to say that it should be treated "similar" to softfail. |
| 21:32 | <grumpy> | which 00? |
| 21:32 | <Julian> | Wayne said: "My opinion: I think it is *critical* that we maintain compatiblity with previous drafts and existing implementations." --- The thing is, SPF implementations don't implement reactions to result codes, so we can't violate existing behavior to that extent. |
| 21:32 | <freeside> | i mean, mengwong-spf-00 |
| 21:32 | <grumpy> | oh, "MUST be treated as None" |
| 21:33 | <freeside> | you know, if i were to do all this over again, i'd focus on the pass cases and lump all the fail/neutral/permerror type things into "did not pass, do what you think is best" >-) |
| 21:33 | <grumpy> | yeah, but we have to document what exists.... |
| 21:33 | <freeside> | just a comment, please go on |
| 21:33 | <freeside> | i know, we're documenting what exists |
| 21:33 | * | grumpy wishes he had a time machine. |
| 21:33 | <Julian> | Also, we're almost certainly not going to mandate ("MUST") receiver policy, are we? So this is not a matter of backwards compatibility. With regard to receiver policy (how to treat "PermError"), we _can_ choose the "best" thing instead of what "exists". |
| 21:33 | <freeside> | i believe that what exists is "people are doing what they think is best" :) |
| 21:33 | <MarkK> | My view is that I still like PermError; I know people fear adoption; but allowing configuration errors in the SPF records to go unchecked, is not actually doing adopters a favor, really. |
| 21:34 | <freeside> | i think this is a really minor point and we should resolve it in whatever way is more likely to gain RFC status. |
| 21:34 | <freeside> | also, see fredkin's paradox |
| 21:34 | <grumpy> | Well, ScottK has pretty strong opinions that most MTAs are not rejecting on permerror right now. |
| 21:34 | <Julian> | grumpy: Also, I object strongly to keep the current wording of section 2.5.7, "PermError". I don't like "[PermError] SHOULD be treated similar to SoftFail". |
| 21:35 | <MarkK> | I do not like that either |
| 21:35 | <freeside> | me neither |
| 21:35 | <grumpy> | Well, the idea of "like softfail" was to suggest gentle ways of informing the domain owner about the errors w/o rejecting. |
| 21:35 | <Julian> | I suggest taking that sentence out, if we don't want to suggest a 5xx rejection. |
| 21:35 | <freeside> | let's say PermError SHOULD be treated as None |
| 21:36 | <freeside> | hey, good idea |
| 21:36 | <freeside> | let's not say what they should do. take the sentence out. julian is right |
| 21:36 | <MarkK> | PermError = 5.x.x != TempError = 4.x.x |
| 21:36 | <freeside> | Design by Committee, blog at 6 |
| 21:36 | <grumpy> | yeah, but we are an intelllligant comity |
| 21:36 | <freeside> | lol |
| 21:37 | <grumpy> | ok, so, is just removing the sentence good enough? |
| 21:37 | <Julian> | Re taking the sentence out: we then should insert another sentence explaining what "Perm[anent ]Err[or]" means, i.e. that it is an error that needs manual intervention for correction, as opposed to TempErr. |
| 21:37 | <freeside> | yes, take it out, i think we're splitting hairs and any implementation is doing what they think is best anyway |
| 21:37 | <grumpy> | Ok, I like julian's suggestion |
| 21:38 | <freeside> | also, i frankly don't think anyone's going to really recode their implementation. when they hear the RFC is granted, they'll just say "great, good to know" and not touch the code at all anyway |
| 21:38 | <Julian> | Shall I phrase a motion? |
| 21:38 | <Julian> | ... |
| 21:38 | <MarkK> | grumpy: 'softfail' gives the domain owner the wrong message; it says: "Don't worry, you did nothing wrong; yours was just a transient error, it will blow over all by itself." Except, it won't, of course. |
| 21:38 | <grumpy> | freeside: that is even more reason why we need to keep things consistent with draft-mengwong-spf-* |
| 21:39 | * | grumpy waits for Julian to finish the motion |
| 21:40 | <MarkK> | I can agree to the rationale of 'none', as a syntax error would be like their is no SPF record at all; but I am mordicus against 'softfail' for this case |
| 21:40 | <Julian> | Motion: In section 2.5.7, "PermError", the second sentence, "Checking software SHOULD treat this result similar to the SoftFail result", shall be replaced by: "This signals an error condition that requires manual intervention to be resolved, as opposed to the TempErr result." (or semantically equivalent wording). |
| 21:40 | <csm-laptop> | second? |
| 21:40 | <grumpy> | 2140u seconded |
| 21:40 | <csm-laptop> | votes? |
| 21:40 | <freeside> | 2140: yes |
| 21:40 | <grumpy> | 2140u yes |
| 21:40 | <Julian> | 2140u: yes |
| 21:40 | <MarkK> | 2140u: yes |
| 21:41 | <csm-laptop> | motion carried |
| 21:41 | <csm-laptop> | so ordered |
| 21:41 | <csm-laptop> | next |
| 21:41 | <grumpy> | Ok, next up |
| 21:41 | <Julian> | Great. |
| 21:41 | <grumpy> | >> For SPF council review: MUST accept source routes |
| 21:41 | <grumpy> | >> Frank Ellermann (Fri May 06 2005 - 02:10:28 EDT) |
| 21:52 | <csm-laptop> | frame it plz |
| 21:52 | <grumpy> | Oh, this is the whole "authorized" vs "authentic" thing |
| 21:52 | <Julian> | I need to think about it for a minute. |
| 21:52 | <grumpy> | Uh, there was a bunch more discussion on this. |
| 21:53 | <Julian> | I know. |
| 21:53 | <Julian> | I need to recall it. |
| 21:53 | <csm-laptop> | iirc this thread went on forever |
| 21:53 | <csm-laptop> | and might still be going on |
| 21:53 | <Julian> | grumpy: I think there was yet _another_ wording variant out there wrt this, wasn't there? |
| 21:53 | <grumpy> | yes, but Ithink we kind of resolved it |
| 21:54 | <grumpy> | Julian: yea |
| 21:54 | <Julian> | One that Scott suggested and that I backed. |
| 21:54 | <freeside> | i think we should translate it into chinese and back, then use that version. |
| 21:54 | <MarkK> | we did? |
| 21:54 | <Julian> | ...with the word "trusted" in it. |
| 21:54 | <freeside> | we should also add "e-" prefixes to random words. |
| 21:54 | <grumpy> | heh |
| 21:55 | * | Julian tries to find the posting... dang! |
| 21:55 | <grumpy> | Uh, oh, right, there was the thing about "accepting responsibility for the email" |
| 21:55 | <grumpy> | but I really didn't like that. |
| 21:55 | <MarkK> | I remember being opposed to saying 'the message may be treated as authentic'. That determination cannot be made from 'pass' |
| 21:55 | <Julian> | | 2.5.3. Pass |
| 21:55 | <Julian> | | |
| 21:55 | <Julian> | | A "Pass" result means that the client is authorized to inject mail |
| 21:55 | <Julian> | | with the given identity. The domain used in the given identity |
| 21:55 | <Julian> | | accepts responsibility for messages from the client. Further |
| 21:55 | <Julian> | | identity base policy checks, such as reputation, or black and/or |
| 21:55 | <Julian> | | white listing, can now proceed with confidence in the identity. |
| 21:55 | <Julian> | s/trust/responsibility/ |
| 21:55 | <MarkK> | Plus, I was also very much against 'accepts responsibility for the message' |
| 21:56 | <Julian> | I agree that the wording is problematic, but the idea I just love! |
| 21:56 | <freeside> | A "pass" result means that the client is recognized by the sender of the message. Further identity-based policy checks, such as reputation, can proceed. |
| 21:56 | <grumpy> | it isn't what draft-mengwong-spf-* said |
| 21:56 | <MarkK> | I stil like the original 2.5.3 wording best, actually |
| 21:57 | <Julian> | Provided that I can find an alternative wording for "accepts responsibility" right now, we have three proposals, right? How do we proceed then? |
| 21:57 | <grumpy> | MarkK: that's what I have come to believe also. |
| 21:57 | <Julian> | Let me re-read the original one. |
| 21:57 | <freeside> | what was the original wording? |
| 21:58 | <freeside> | i gotta run soon, guys |
| 21:58 | <grumpy> | I don't want to get into the authorized vs authentic issue, and I don't want to say they must "accept responsibility" |
| 21:58 | <Julian> | 2.5.3. Pass |
| 21:58 | <Julian> | A "Pass" result means that the client is authorized to inject mail |
| 21:58 | <Julian> | with the given identity. Further policy checks, such as reputation, |
| 21:58 | <Julian> | or black and/or white listing, can now proceed with confidence in the |
| 21:58 | <Julian> | identity. |
| 21:58 | <MarkK> | the one julian qwuoted |
| 21:58 | <Julian> | MarkK: No, I haven't quoted the original before. |
| 21:58 | <csm-laptop> | I have to go in a couple of minutes also |
| 21:58 | <Julian> | Damn. |
| 21:58 | <freeside> | let's go with the original wording as pasted by julian. |
| 21:59 | <MarkK> | Oh, yes, I see, you had your 'accepts responsibility' thing in there |
| 21:59 | <Julian> | No, IMO this issue needs more discussion. The definition of "Pass" is essential. |
| 21:59 | <MarkK> | no, lets take that responsibility wording out |
| 21:59 | <freeside> | i think this is a really minor point and we should resolve it in whatever way is more likely to gain RFC status. |
| 21:59 | <Julian> | Let's not vote on this issue today. |
| 21:59 | * | grumpy would like to vote on it today |
| 21:59 | * | MarkK too |
| 21:59 | * | grumpy thinks the current wording is fine |
| 22:00 | * | Julian is going to vote against any motion wrt this issue. |
| 22:00 | <freeside> | let's vote on whether we should vote on it today today |
| 22:00 | * | MarkK agrees with grumpy |
| 22:00 | * | grumpy agrees with freeside |
| 22:00 | <csm-laptop> | somebody make a motion then |
| 22:00 | <Julian> | Somebody make a motion, otherwise let's move on. |
| 22:00 | <grumpy> | motion: The current text is acceptable |
| 22:00 | <csm-laptop> | second? |
| 22:00 | <MarkK> | 2200u: seconded |
| 22:00 | <csm-laptop> | votes? |
| 22:00 | <Julian> | 2200u: no |
| 22:00 | <grumpy> | 2200u yes |
| 22:01 | <MarkK> | 2200u: yes |
| 22:01 | <grumpy> | freeside? |
| 22:01 | <grumpy> | csm? |
| 22:01 | <csm-laptop> | freeside? |
| 22:01 | <freeside> | 2200u: yes |
| 22:01 | <freeside> | gtg |
| 22:01 | <grumpy> | ok |
| 22:01 | <csm-laptop> | motion carries |
| 22:01 | <csm-laptop> | so ordered... |
| 22:01 | <grumpy> | two items left |
| 22:01 | <Julian> | Damn it. |
| 22:01 | <csm-laptop> | I make a motion to adjourn |
| 22:02 | <Julian> | I'm going to bring the issue again up none the less. |
| 22:02 | <Julian> | I'm going to bring the issue up again none the less. |
| 22:02 | <MarkK> | See, grumpy, I posted about it; and the more I reworded the responsibulty thing, the closer I came to the original wording; hence, I think we should just keep it. :) |
| 22:02 | <csm-laptop> | motion: adjourn this meeting |
| 22:02 | <csm-laptop> | second? |
| 22:02 | <Julian> | 2202u: seconded |
| 22:02 | <csm-laptop> | votes? |
| 22:02 | <Julian> | 2202u: yes |
| 22:02 | <csm-laptop> | 2202u: yes |
| 22:02 | <grumpy> | 2202u yes |
| 22:02 | <MarkK> | I though we were only half-way done; lol :) |
| 22:02 | <freeside> | 2202u: yes, bye, sorry |
| 22:02 | <csm-laptop> | I only had an hour |
| 22:03 | <grumpy> | two items left |
| 22:03 | <Julian> | MarkK: We were aware that Chuck had to go after ~1h. |
| 22:03 | <grumpy> | yes |
| 22:03 | <MarkK> | 2202u: yes |
| 22:03 | <grumpy> | (or, at least, I was aware) |
| 22:03 | <csm-laptop> | talk to you guys in a few weeks... |
| 22:03 | <grumpy> | hvae fun! |
| 22:03 | <MarkK> | yes, but time really flies |
| 22:03 | <Julian> | csm-laptop: Yeah, have a good trip! |
| 22:03 | <csm-laptop> | I may be around in the channel some but I have no time for meetings until the 22nd I think |
| 22:03 | <grumpy> | yeah, but we got the website thing resolved, and we resolved a few draft issues |
| 22:03 | <Julian> | grumpy, MarkK: Can we discuss the "Pass" thing for a few minutes? |
| 22:04 | <MarkK> | yes, please |
| 22:04 | <grumpy> | sure |
| 22:04 | * | grumpy will be here for hours... |
| 22:04 | <Julian> | Good. ... |
| 22:04 | <Julian> | So, just to rehash, the current wording is: |
| 22:04 | <Julian> | 2.5.3. Pass |
| 22:04 | <Julian> | A "Pass" result means that the client is authorized to inject mail |
| 22:04 | <Julian> | with the given identity. Further policy checks, such as reputation, |
| 22:04 | <Julian> | or black and/or white listing, can now proceed with confidence in the |
| 22:04 | <Julian> | identity. |
| 22:04 | <Julian> | -- |
| 22:04 | <grumpy> | right |
| 22:04 | <Julian> | ... |
| 22:05 | <MarkK> | yes |
| 22:05 | * | grumpy forgot to give a report on how the reviews on the IETF mailing lists are going. |
| 22:05 | <grumpy> | they are going pretty well |
| 22:05 | <Julian> | What the other proposals have in common is that they suggest that there is more about "Pass" than simply the authorization to use the identity. |
| 22:05 | <Julian> | I especially like Scott's "b" suggestion: ... |
| 22:06 | <Julian> | 2.5.3. Pass |
| 22:06 | <Julian> | A "Pass" result means that the client is authorized to inject mail |
| 22:06 | <Julian> | with the given identity and that the message may be treated as |
| 22:06 | <Julian> | authentic. Further policy checks, such as reputation, or black |
| 22:06 | <Julian> | and/or white listing, can now proceed with confidence in the |
| 22:06 | <Julian> | identity. |
| 22:06 | <Julian> | -- |
| 22:06 | <grumpy> | I don't want to get into authorized vs authentic |
| 22:06 | <grumpy> | and no, I don't think it means it is authentic. |
| 22:06 | <Julian> | The implication of that is that identities can actually be considered _authenticated_ by receivers, not just _authorized_. |
| 22:06 | <MarkK> | grumpy: that is why I _dislike_ b |
| 22:07 | <Julian> | I think this is an important advantage of b. |
| 22:07 | <Julian> | Why don't you like this implication? |
| 22:07 | <grumpy> | you can use PGP or S/MIME to authenticate the message. |
| 22:07 | <grumpy> | all SPF can do is confirm authorization of the source. |
| 22:07 | <MarkK> | because the message is not at all authenticated; you need to sign the message for that |
| 22:08 | <MarkK> | it is entirely misleading, actually |
| 22:08 | <Julian> | MarkK: Perhaps it should be reworded that the "use of the identity is authentic", not "the message is authentic". |
| 22:08 | <grumpy> | if I'm foo@bar.com, I can still "spoof" stuff by saying I'm baz@bar.com |
| 22:08 | <MarkK> | It is really ony true that the relay is authorized do deliver the message with domain X; that's all. |
| 22:08 | <Julian> | Re "use of identity is authentic": I think that's what Scott actually meant. |
| 22:08 | <grumpy> | I'm not sure what that means |
| 22:09 | <Julian> | Just a moment, I'm gonna find the right posting to answer that question. |
| 22:09 | <MarkK> | julian: but is then not the original better? To say: "authorized to inject mail with the given identity" |
| 22:09 | <grumpy> | ok |
| 22:09 | <Julian> | (MarkK: I don't want to remove that sentence.) |
| 22:09 | <Julian> | (Neither did Scott's b.) |
| 22:10 | <MarkK> | I know; but you want to add to say it is therewith authentic too |
| 22:10 | <Julian> | Authentication is the process of determining authenticity. Authenticity |
| 22:10 | <Julian> | means the genuine use of an identity (strictly: identifier). |
| 22:10 | <grumpy> | on another review, someone suggested that I remove two lines from the intro because they were too controversial. They happen to be two lines that about a half dozen people have picked over the semantics. ;-) |
| 22:10 | <Julian> | -- |
| 22:10 | <Julian> | Again: |
| 22:10 | <Julian> | Authentication is the process of determining authenticity. Authenticity |
| 22:10 | <Julian> | means the genuine use of an identity (strictly: identifier). |
| 22:10 | <Julian> | -- |
| 22:10 | <Julian> | Authentication is the process of determining authenticity. Authenticity |
| 22:10 | <Julian> | means the genuine use of an identity (strictly: identifier). |
| 22:10 | <Julian> | Ugh. |
| 22:11 | <Julian> | One more try: |
| 22:11 | <Julian> | Authentication is the process of determining authenticity. Authenticity |
| 22:11 | <Julian> | means the genuine use of an identity (strictly: identifier). |
| 22:11 | <Julian> | -- |
| 22:11 | <Julian> | Authorization is the declaration of legitimacy by some authority. |
| 22:11 | <Julian> | Authorization is strictly dependent on authentication, that is, without |
| 22:11 | <Julian> | authenticity, authorization is inapplicable. |
| 22:11 | <Julian> | -- |
| 22:11 | <grumpy> | Yes, but what we (assume) is authentic is the IP address |
| 22:11 | <Julian> | So, the identity being authenticated is really what we mean, isn't it? |
| 22:11 | <grumpy> | and the stuff returned by the DNS |
| 22:11 | <Julian> | The IP address is authentic, anyway. By definition of TCP. |
| 22:12 | <grumpy> | those are our two authenticated sources upon which we authorize the use of the domain. |
| 22:12 | <MarkK> | the use of the identity is authentic, yes |
| 22:12 | <Julian> | So why can we not say this in the definition of "Pass"? |
| 22:12 | <Julian> | (Yes, Scott's b is worded suboptimally.) |
| 22:13 | <MarkK> | but in that wording you propose to say the entire message may be treated as authentic |
| 22:13 | <MarkK> | (or Scott, actually) |
| 22:13 | <Julian> | I don't think that wording should be used unmodified. |
| 22:14 | <Julian> | Let me rephrase Scott's b. |
| 22:14 | <grumpy> | I don't think "use of the identity is authentic" makes sense. The identity may be authentic, but I don't think you can apply "authentic" to a use. |
| 22:15 | <Julian> | 2.5.3. Pass |
| 22:15 | <Julian> | A "Pass" result means that the client is authorized to inject mail |
| 22:15 | <Julian> | with the given identity and that the identity may be treated as |
| 22:15 | <Julian> | authentic. Further policy checks, such as reputation, or black |
| 22:15 | <Julian> | and/or white listing, can now proceed with confidence in the |
| 22:15 | <MarkK> | exactly wayne; :) because to say that is kinda silly; so that is why I keep coming back to just the original wording |
| 22:15 | <Julian> | identity. |
| 22:15 | <Julian> | -- |
| 22:15 | <grumpy> | Again, what is authentic is the IP address and the DNS info. Based on that, we authorize the use of a domain name. We do not authenticate the domain name. |
| 22:16 | <Julian> | But checking the authorization info in the SPF record against the identity in the message means authenticating the identity in the message. |
| 22:17 | <Julian> | What about the above wording? |
| 22:18 | <Julian> | I think we somehow need to have the concept of "identity is authenticated" in the definition of "Pass". |
| 22:18 | <MarkK> | Only in a very narrow sense could it be said to be authentic as a match against the IP address; but, as I posted, it is ere co-ordinately authentic; which means others domain next to it may be too; which make to sat it is authentic rather thin |
| 22:18 | <grumpy> | I don't really like it because I don't want to get into the authorized vs authentic thing and because I disagree that we have authenticated the identity. |
| 22:18 | <Julian> | grumpy: What would be the missing steps in order to actually authenticate the identity? |
| 22:18 | <MarkK> | I really am in favor of keeping 'authentic' out the wording |
| 22:19 | <Julian> | grumpy: ...and I mean just the identity, not the message. |
| 22:19 | <grumpy> | yeah, I'm thinking |
| 22:19 | <grumpy> | but I still think it would require something like PGP or S/MIME |
| 22:19 | <grumpy> | because you can authorize an MTA that may allow cross-user forgery |
| 22:20 | <grumpy> | So, an authorized MTA may still give domains that are not authentic. |
| 22:20 | <Julian> | grumpy: The updated wording says "the identity may be treated as authentic". |
| 22:20 | <grumpy> | which is ok with the domain owner |
| 22:20 | <grumpy> | yeah |
| 22:20 | <grumpy> | but I don't see the gain in that. |
| 22:21 | <grumpy> | just leave it as "the identity may be treated as authorized" |
| 22:21 | <Julian> | If we _really_ think that the identity cannot be generally considered to be authentic even though the result was "Pass", we _must_ make that clear in the spec. If this is really the case, it is a security issue. |
| 22:21 | <grumpy> | Uh, we kind of do. |
| 22:21 | <Julian> | I could live with simply adding a reference to section... |
| 22:22 | <grumpy> | that is part of what the cross-user forgery thing is about |
| 22:22 | <Julian> | ...what section was the cross-user forgery thing? |
| 22:22 | <Julian> | 10.4 |
| 22:22 | <Julian> | Don't you think an explicit reference to section 10.4 would be good, then? |
| 22:23 | <MarkK> | julian: it always is, as I pointed out; that is the co-ordinately thingy; if there were only 1 domain that could be used with the IP address, it might be said to be authentic; but since other can be used with it too, co-ordinately, all we can really say is that the relay is authorized to use the identity |
| 22:24 | <Julian> | MarkK: I can follow that. |
| 22:24 | <Julian> | So I'm now only talking about adding a reference to section 10.4 to the definition of "Pass". |
| 22:24 | <grumpy> | I don't think it is needed. |
| 22:25 | <Julian> | grumpy: Define "needed". Would you think it might be valuable? |
| 22:25 | <grumpy> | as long as we stay away from claiming authentication and go with authorization we are fine |
| 22:25 | <Julian> | grumpy: People are going to confuse those two concepts. |
| 22:25 | <grumpy> | no, I think it would be confusing without adding a much more verbage. |
| 22:26 | <grumpy> | I think making the reference would just make things worse. |
| 22:26 | <grumpy> | Hi Frank! |
| 22:26 | <MarkK> | uh? |
| 22:26 | <Julian> | We have added so much language to various sections of the spec to avoid potential confusion about difficult topics, why can't we do this to the most important part of the spec, i.e. the definitions of the result code meanings? |
| 22:27 | <Julian> | Why would it make things worse? I can't follow that at all! |
| 22:27 | <grumpy> | Hmmm.... |
| 22:27 | <grumpy> | I guess all I can say is that this is gut feel and a judgement call. |
| 22:28 | <Julian> | Pity. |
| 22:28 | <Julian> | grumpy: Ok, now at least I know where you stand. :-| |
| 22:29 | <grumpy> | I don't recall that it has been an issue that much in the past, and I think raising the "authentication" stuff is worse than just consistently using "athorization" |
| 22:29 | <grumpy> | I agree that we could explain the issue, but I suspect it would confuse more people than it would help. |
| 22:30 | <Julian> | I think this is the stuff of which FAQs are made. I can see this becoming a top FAQ. |
| 22:30 | <MarkK> | I just do not think SPF can honestly carry authentication; it looks good, but we cannot really make good on that |
| 22:30 | <grumpy> | MarkK: agreed.] |
| 22:30 | <Julian> | "Q: Why can't I assume the MAILFROM to be authentic? A: Read section 10.4." |
| 22:30 | <MarkK> | julian: I still like to write the 'how-to' doc, with pitfalls like these and such |
| 22:30 | <Julian> | MarkK: I'm not talking about authentication right now. |
| 22:31 | <Julian> | MarkK: If we're going to write a how-to doc with pitfalls and such, we can remove _lots_ of less important stuff from the spec, too. It might even shrink below 40 pages. |
| 22:31 | <grumpy> | Julian: you may be right, but my guess is that "Why the (*#&$ did my email get rejected???" will be #1 |
| 22:31 | <MarkK> | I meant authentication in 'authentic' |
| 22:32 | <Julian> | MarkK: I'm not talking about "authentic", either. I have already agreed that we cannot generally assert authenticity due to the cross-user forgery problem. Thus I am now suggesting adding a reference to section 10.4 to the definition of "Pass". |
| 22:32 | <MarkK> | As you know, I always wanted to do the delployment recommendation sort of thing; this would be like it, kinda |
| 22:32 | <MarkK> | julian: ok, I see |
| 22:33 | <Julian> | I repeat: If we're going to write a how-to doc with pitfalls and such, we can remove _lots_ of less important stuff from the spec, too. It might even shrink below 40 pages. |
| 22:33 | <grumpy> | Julian: I don't think so. |
| 22:33 | <grumpy> | One of the IESG reviewers mentioned that he liked the fact that we explay why things are the way they are. |
| 22:33 | <Julian> | grumpy: You don't think there are _less_important_ issues that could be removed? |
| 22:34 | <grumpy> | Hmmmm... |
| 22:34 | <MarkK> | yes; and I think the need for such a document exists, because not everyone is as well versed in SPF matters, as frank pointed out, I thought, as we are in the SPF community |
| 22:34 | <grumpy> | I think that I don't see this as anywhere near as important as you do. |
| 22:34 | <grumpy> | I think the defintion of Pass is clear right now, and I think adding a footnote will cause it to become more confusing. |
| 22:35 | <Julian> | My reasoning goes like this: Right after the SPF syntax, the definitions of what the result codes mean is the most important part of the spec. |
| 22:35 | <MarkK> | that it is |
| 22:35 | <Julian> | Technically, the definition of "Pass" is correct. I agree with that. |
| 22:35 | <Julian> | But I don't think it is as clear as it should be. |
| 22:36 | <grumpy> | Julian: let me think about this for a while. I've changed my mind on other things, such as I initially liked the "accepts responsiblity" wording. |
| 22:36 | <Julian> | It's not as if the reference would read "There are a number of cases where the previous sentence could be misleading, for an example see section 10.4". That would indeed confuse things. |
| 22:36 | <grumpy> | I may change my mind on this, but I don't think we are getting anywhere right now. |
| 22:37 | <Julian> | The point of a reference to section 10.4 would be solely to point out the single one case where confusing "authorization" and "authentication" is going to bite you. |
| 22:38 | <Julian> | Ok, let's conclude this for now. |
| 22:38 | <MarkK> | btw, reading back... my somewhat awkwardly worded 'co-ordinately' thing is actually better said in plain English: "cross-DOMAIN forgery" (not cross-USER forgery, as that is LHS stuff). |
| 22:39 | <grumpy> | Ok, I'm going to go hack on the draft a little bit to make sure I've caught up with all suggested changes. |
| 22:39 | <Julian> | MarkK: Did you perhaps mean "orthogonal" by "co-ordinately"? |
| 22:39 | <grumpy> | then I'm going to try and catch up on email. |
| 22:39 | <grumpy> | Julian: hmmm... that would make more sense to me. |
| 22:40 | <MarkK> | lol; yeah, I think that is more the word I was looking for :) |
| 22:40 | * | grumpy never knew dutch well enough to know how to translate either of those words |
| 22:41 | <Julian> | MarkK: So you are suggesting section-10.4 =~ s/cross-user/cross-domain/? |
| 22:41 | * | MarkK is reading it vack |
| 22:41 | <grumpy> | I would suggest cross-customer |
| 22:42 | <grumpy> | but not all users are customers. |
| 22:42 | <Julian> | I think "cross-user forgery" is best. "cross-customer" implies a service provider to customer relationship, which is not always the case. |
| 22:42 | <grumpy> | right |
| 22:42 | <MarkK> | wayne, what is that url again? |
| 22:42 | <grumpy> | which? |
| 22:42 | <MarkK> | I seem to be making a typo somewhere |
| 22:42 | <MarkK> | to your latest draft |
| 22:43 | <grumpy> | oh, that would be http://www.schlitt.net/spf/ |
| 22:43 | <grumpy> | and then click a few links. |
| 22:43 | * | grumpy stumbled when typing the URL |
| 22:43 | <MarkK> | got ot |
| 22:44 | <Julian> | Also, "cross-domain forgery" doesn't really describe the problem. A user owning two domains wouldn't really be forging a.domain.org when using either of them while SMTP-authenticated. He is, after all, the owner of both. |
| 22:45 | <Julian> | s/a.domain.org/a domain/ |
| 22:45 | <MarkK> | 'cross-user' actually may include 'cross-domain' too, and is not strictly LHS only per se, as I said before; I just really meant cross-domain though, to indicate that we can onlyt say the relay can use the domain name |
| 22:46 | <Julian> | "cross-user forgery" is what we're really concerned about: one user using the domain of another user without his consent ("forgery"). |
| 22:46 | <MarkK> | true; 'cross-domain ambiguity' or something |
| 22:46 | <MarkK> | yes, but it is the 'cross-domain ambiguity' which makes it so we cannot say the use of the domain is authentic |
| 22:47 | <Julian> | Yes, I do understand that. |
| 22:47 | <Julian> | I am just explaining why I think "cross-user forgery" is more appropriate wording than "cross-domain forgery". |
| 22:47 | <MarkK> | (it is hard to find the right words at this late an hour; lol) |
| 22:47 | <MarkK> | yes, strike 'cross-domain forgery' |
| 22:48 | <Julian> | (I know that problem. When I'm tired, my English deteriorates badly.) |
| 22:48 | <MarkK> | if anything, I meant 'cross-domain ambiguity'. |
| 22:49 | <Julian> | (But my German often also deteriorates, too, when I'm tired. Heh.) |
| 22:51 | <MarkK> | my english does not necessarily deteriorate, but it often hard, especially with this stuff, to express exactly and clear what you mean to convey; and then it tends to come out a bit crooked when you're tired. :) |
| 22:51 | <Julian> | That's what I meant. |
| 22:51 | <MarkK> | sometimes you simply really need to think of a good, usuable term |
| 22:52 | <Julian> | Ok, any other SPF related issues we could/should discuss? |
| 22:52 | <Julian> | Otherwise, we should just move to #spf |
| 22:52 | <MarkK> | funny; though we're adjourned, we still have quorum now :) |
| 22:53 | <Julian> | I don't think freeside's still here. |
| 22:53 | <MarkK> | but we just passed a resolution to say we only needed 3 people of I-D matters :) |
| 22:54 | <Julian> | Yeah. |
| 22:54 | <MarkK> | none of that is relevant, of course, as we're officially adjourned a long time ago |
| 22:58 | <MarkK> | gee, it got real silent now |
| 22:58 | <Julian> | Is there anything SPF related to discuss left? |
| 22:58 | <Julian> | Is there anything SPF related left to discuss? |
| 22:59 | <Julian> | (Oops, I did it again.) |
| 23:07 | <MarkK> | I need to go to bed; goodnight |