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.

If you do not have access to IRC, you may view the recent traffic at: http://www.schlitt.net/spf/spf-council/now/irc_log.html.

This log can be can be viewed at: http://www.schlitt.net/spf/spf-council/2005/02/09_irc_log.html.

IRC nicknames:
csmChuck Mead
freesideMeng Weng Wong
grumpyWayne Schlitt
JulianJulian Mehnle
MarkKMark Kramer (asarian-host.net)

--- Tue Feb 8 20:02:08 UTC 2005 ---
20:02<Julian>csm-laptop: Could you please send an announcement for tomorrow's meeting?
20:07<csm-laptop>yes... I will
20:23<Julian>Thanks.
20:53<csm-laptop>it will go out from home this evening
20:56<Julian>np
--- Wed Feb 9 18:58:16 UTC 2005 ---
18:58<Julian>bbl
21:35<grumpy>ok, I've heard from chuck... has anyone heard from meng?
21:44<Julian>No.
21:48<Julian>He hasn't been in #spf-council for quite a while.
21:48<Julian>At least not when I have been here.
21:51*Julian gets a snack before the show begins.
22:01*grumpy looks around
22:04<csm>heyas
22:04<Julian>I'm here.
22:04<csm>krist
22:04<csm>we're missing 4
22:04<csm>dammit
22:04<Julian>Let's wait a few minutes.
22:05<grumpy>well, we know the drill.
22:05<csm>okay... it's not a biggee to me...
22:06<csm>we can reschedule if need be
22:06<csm>we *REALLY* need Meng though
22:06<grumpy>without a quorum we can: 1) schedule the next meeting, 2) wait, or 3) try and round up a quorum
22:06<Julian>True.
22:08<Julian>Let's do 2, 3, and 1, in that order.
22:11<csm>I am doing 2
22:11<csm>and if somebody wants to try to reach one of the other two please do...
22:11*Julian sends an e-mail to Meng and Mark.
22:15<Julian>*sent*
22:16<csm>didn't Meng *ASK* for Wednesdays?
22:16<Julian>Thought so.
22:16<grumpy>yes, it was Meng...
22:16*grumpy checks Meng's calendar
22:17<grumpy>Meng's calendar is pretty empty... he still has council meetings scheduled for Wednesdays, "9:00 AM" (no TZ mentioned)
22:19<freeside>moo.
22:19<grumpy>Ya!
22:19<grumpy>hi meng!
22:19<freeside>hi
22:19<grumpy>ok, how much longer should we wait for MarkK?
22:20<Julian>2min.
22:20<Julian>So he has a chance to react to my mail.
22:21<grumpy>sounds reasonable
22:21<grumpy>csm: you still around?
22:21<freeside>hey, this is an excellent time for me.
22:21<Julian>freeside: Nice to see you on #spf-council again. :-)
22:21<freeside>word.
22:22*freeside puts it in his .ircrc.
22:22<grumpy>csm?
22:22<csm>yeah hey guys... gimme 30 seconds
22:22<grumpy>freeside: have you heard anything from the IETF about the SPF I-D?
22:22<freeside>well, i have some news to report
22:23<grumpy>cool!
22:23<freeside>i got a phone call from our friends at Microsoft asking for clarification re which draft the directorate should be looking at
22:23<freeside>they're not happy about a few things
22:23<freeside>1) the zone cut
22:23<freeside>2) the fact that HELO is back in there
22:23<freeside>3) the language that's very specific about mail-from
22:23<freeside>so they wanted to know if the directorate should be examining your draft or lentczner's draft.
22:24<freeside>personally, i think the best draft for IETF purposes would
22:24<freeside>1) not talk about the zone cut
22:24<grumpy>well, to the best of my (limited) knowledge, the IETF is considering my draft.
22:24<freeside>2) mention applicability to HELO
22:24<grumpy>as per all the email I've cc:'ed to spf-council
22:24<freeside>3) not use language specific to mail-from.
22:24<freeside>so.
22:24<Julian>Huh? Guys from _Microsoft_ are asking for clarification re which draft the directorate (IETF I suppose) shoud be looking at???
22:25<freeside>well, they're asking me to make a comment to the directorate about whether the directorate should be looking at the lentczner or the schlitt draft.
22:25<freeside>they would prefer the lentczner draft.
22:25<freeside>i was sad to see the HELO not be present in Lentczner.
22:25<MarkK>finally; :) sorry for my absence; cable just came online again :(
22:25<Julian>I thought the MarkL draft had been obsoleted by Wayne submitting his latest.
22:25<grumpy>should we put this under "new business" and start the meeting?
22:25<freeside>so now i'm thinking it might be a good idea to just let the lentczner draft proceed, and then submit a separate draft talking about applicability to helo scope.
22:26<freeside>yeah, let's go ahead.
22:26<grumpy>csm?
22:27<grumpy>ugh...
22:27<csm>okay
22:27<grumpy>ya!
22:27<csm>so the meeting will come to order
22:27<Julian>22:22 UTC <csm> yeah hey guys... gimme 30 seconds
22:27<Julian>Oh, ok. Chuck is back.
22:27<grumpy>wow, not just a quorum, but a full meeting!
22:28<Julian>That's great indeed!
22:28<csm>so the meeting will come to order
22:28<csm>1st item of business... approval of the minutes
22:28<freeside>can i get fries with that?
22:29<grumpy>I have read the minutes, and I approve of them.
22:29<grumpy>motion: approve the minutes
22:29<MarkK>seconded
22:29<Julian>BTW, the minutes are here: http://spf.mehnle.net/Council_Meeting/2005-01-15
22:29<Julian>(Just for the record.)
22:29<csm>votes on 2229U
22:30<grumpy>2229u: yes
22:30<Julian>2229u: yes
22:30<freeside>2229u: yes
22:30<MarkK>2229U: yes
22:30<csm>so ordered
22:30<csm>next item is my report
22:30<csm>okay...
22:30<csm>two things...
22:30<csm>AMSG and the PR I owe the group
22:30<csm>both are going to be summed up
22:30<csm>this way
22:30<csm>I have been undergoing some significant changes in my personal life
22:31<csm>I will detail them here
22:31<csm>this has been going on for several weeks
22:31<csm>all has settled down now...
22:31<csm>I will have a routine again
22:31<csm>so
22:31<csm>here is what I ask re: AMSG
22:31<csm>give us a 30 day extension...
22:31<csm>not counting this month
22:31<Julian>Ok with me.
22:31<csm>so say March 31st
22:32<MarkK>no problem here
22:32<Julian>Is that a motion?
22:32<csm>I move that the AMSG be given an extension through March 31st 2005 (inclusive)
22:32<grumpy>no problems here either...
22:32<grumpy>seconded
22:32<Julian>2232u: seconded
22:32<freeside>2232u: ok
22:32<grumpy>2232: yes
22:32<csm>votes on 2232u?
22:33<Julian>2232u: yes
22:33<MarkK>2232u: yes
22:33<Julian>I think freeside's was a yes.
22:33<csm><csm> I will *NOT* detail them here :-)
22:33<csm>I realized I made a mistake in that sentence... sorry
22:33<freeside>motion to approve csm's correction of his mistake
22:33<csm>he-he
22:33<csm>not really related... smart ass
22:34<grumpy>ok, the PR?
22:34<csm>okay... on the PR
22:34<Julian>Is 2232u concluded?
22:34<csm>same problem was holding it up...
22:34<csm>so ordered on 2232u
22:34<csm>same problem was holding up the PR
22:34<grumpy>I think we can skip the PR, it is way too late
22:34<csm>in fact until this week I haven't been near my home systems for 3 weeks
22:34<Julian>I tend to agree with grumpy.
22:35<csm>well... I think there is still a need to clarify our position with repsect to SID
22:35<MarkK>csm: yes
22:35<Julian>csm: True.
22:35<grumpy>ok
22:35<csm>and that was a part of my objective
22:35<csm>so I plan to get going on it again
22:35<Julian>I had planned to take some initiative in that, but haven't found the time.
22:35<csm>so look for something before mid-week next week
22:36<MarkK>:)
22:36<csm>okay so that's it from me...
22:37<csm>I've been so jammed up with personal stuff I've not undertaken much
22:37<csm>I am going to be in DC area for two weeks the end of the month and have reached out to Yakov to see if we can meet for dinner
22:37<Julian>Interesting!
22:37<csm>indeed
22:38<csm>we shall see...
22:38<csm>he recently reached out to me... so I have reached back
22:38*freeside stifles comment
22:38<csm>and that concludes my report...
22:38*csm smacks freeside
22:38<csm>what?
22:39<grumpy>*snicker*
22:39<grumpy>ok, Meng's report?
22:39<freeside>i'm waiting with bated breath to hear what HSARPA will say .... they're supposed to make a decision sometime in feb.
22:40<freeside>i just submitted a proposal in collaboration with p. oscar boykin to the NSF, for basically the same thing --- cheeseplate and karma.
22:40<grumpy>which decade?
22:40<Julian>NSF = ?
22:40<freeside>the NSF response will occur in august, and i suspect that events will have overtaken it by then, but hey, free money.
22:40<grumpy>National Science Foundation?
22:40<csm>National Science Foundation
22:40<Julian>Oh, I see.
22:40<MarkK>freeside: yes, I was wondering about HSARPA
22:40<grumpy>(the NSF used to fund the Internet)
22:41<freeside>i have continued to work on hammering out an architecture for karma and a revenue model. i've been making phone calls around the industry and so far the response has been vaguely affirming.
22:41<grumpy>(post arpa/darpa/arpa, pre dot-com bubble)
22:41<freeside>but nothing has really moved on that front.
22:41<freeside>next item to report: i did a bit of research over the weekend
22:41<freeside>i went through a day's worth of logs and pulled out all the return-paths from mail that came in to pobox.
22:42*Julian knows what freeside is about to tell.
22:42<freeside>i counted senders:
22:42<freeside>20050209-17:39:40 mengwong@emerald:~/karma% head -4 20050203.nopobox.txt
22:42<freeside>338330 hotmail.com
22:42<freeside>220420 yahoo.com
22:42<freeside>81692 returns.groups.yahoo.com
22:42<freeside>65708 aol.com
22:42<freeside>there were about 168,000 unique domains total.
22:42<freeside>20050209-17:39:43 mengwong@emerald:~/karma% wc -l 20050203.nopobox.txt
22:42<freeside>168756 20050203.nopobox.txt
22:42<freeside>i then wrote a perl one-liner to do a dns query for each domain in the list.
22:43<freeside>20050209-17:40:45 mengwong@emerald:~/karma% grep spf 20050203.nopobox.output.txt | head -4 | cut -c-60
22:43<freeside>65708 aol.com spf2.0/pra ip4:152.163.225.0/24 ip4:205.1
22:43<freeside>12352 dartmail.net v=spf1 ip4:146.82.220.0/23 ip4:198.3
22:43<freeside>9779 gmail.com v=spf1 a:mproxy.gmail.com a:rproxy.gmai
22:43<freeside>8750 earthlink.net v=spf1 ip4:207.217.120.0/23 ip4:207
22:43<freeside>20050209-17:40:50 mengwong@emerald:~/karma% grep -c spf 20050203.nopobox.output.txt
22:43<freeside>20619
22:43<freeside>20,000 domains out of 168,000 had spf records.
22:43<Julian>Uhm, but doesn't aol.com have a spf1 record, too?
22:44<freeside>sure.
22:44<freeside>the one-liner was really crude.
22:44<freeside>purl, 20619 / 168000
22:44<freeside>ugh
22:44<freeside>purl, 20619 / 168000
22:44<purl>0.122732142857143
22:44<freeside>so that's about 12% of domains
22:44<freeside>that send mail to pobox
22:45<freeside>looking at the number of messages, i found 26% of message delivery attempts had return-paths that had spf records
22:45<Julian>What's that 20,000 figure again?
22:45<grumpy>how is that as far as overall email?
22:45<Julian>Oh.
22:45<Julian><freeside> 20,000 domains out of 168,000 had spf records.
22:45<grumpy>I'm receiving around 10% of my email with SPF records, but it has been that way for months
22:45<freeside>so, 26% of all the messages that come into pobox can be tested with SPF.
22:45<freeside>thanks, purl!
22:45<purl>pas de quoi freeside
22:45<grumpy>cool!
22:45<freeside>purl, leave #spf-council
22:45<purl>goodbye, freeside.
22:45<Julian>That's pretty good!
22:45<freeside>i'll present those results at the maawg meeting in march.
22:46<freeside>last item to report.
22:46<grumpy>on a slightly related subject, I'm currently running another survey of .com/.net/.org domains to see how many have SPF records.
22:46<Julian>freeside: Be careful not to mix up spf1 and spf2.
22:46<csm>i like purl
22:46<grumpy>Due to bandwidth problems, the survey still isn't finished
22:46<grumpy>should be done in the next couple of days.
22:46<freeside>maybe we can ask our friends at verisign to run that script :)
22:46<Julian>grumpy: Perhaps domain testing can be distributed.
22:47<grumpy>I have a python script that certainly could be passed around.
22:47<grumpy>for this survey though, it is probably notworth it.
22:48<Julian>freeside: Ok, go on.
22:48<freeside>so, they are unhappy about three things
22:48<freeside>1) the draft mentions HELO checking
22:48<Julian>"they" = Microsoft?
22:48<freeside>2) the draft has a pretty strong mail-from bias and explicitly deprecates or at least denigrates use in other contexts
22:49<freeside>3) zone cuts
22:49<freeside>
22:49<csm>who is *THEY*?
22:50*grumpy suspects one of Meng's messages got dropped.
22:50<freeside>microsoft!
22:50<freeside>now, i personally would be happy with a draft that used neutral language regarding application to different contexts.
22:50<freeside>i think helo checking is a good idea.
22:50<freeside>PEBCAK
22:50<freeside>i think we should take out zone cuts.
22:50<freeside>i think we should not denigrate use in other contexts if we want this thing to ever become an RFC.
22:50<MarkK>26% is pretty high; I have not checked the totals; but, roughly, my graphdefang output tells me that out of 300,000 emails. 58,000 passed SPF check. :)
22:50<grumpy>no matter who "they" is, the I-D is supposed to be a spec about *spf-classic*, which is unrelated to anyone else
22:50<Julian>Can I talk for a minute?
22:51<freeside>ok, let me get that straight -- is the schlitt draft meant to document spf-classic?
22:51<grumpy>that was my goal....
22:51<grumpy>e.g., draft-schlitt-spf-classic-00.txt
22:51<csm>and was what I thought it's purpose was as well
22:51<MarkK>freeside: yes
22:51<Julian>freeside: I thought it was meant to be the final SPFv1 spec.
22:51<freeside>the directorate still wants a draft on spf to form part of the sender id ball of wax.
22:51<grumpy>but then, MarkL said his was supposed to document spf-classic also...
22:52<grumpy>(Or, at least, that's what MarkL said.)
22:52<grumpy>freeside: have you heard from the directorate?
22:52<grumpy>I haven't.
22:52<freeside>the directorate is going to review a set of drafts that will constitute sender id. MS isn't happy with the Schlitt draft being considered for that purpose. However, MS are satisfied with the Lentczner draft.
22:52<Julian>There is little point in _documenting_ SPFv1. We need to _specify_ it.
22:52<MarkK>I think we collectively voted to go with, and mandated, wayne to do this, right?
22:52<Julian>MarkK: Absolutely.
22:52<grumpy>MarkK: yes, but the IETF has no reason to listen to us
22:52<freeside>so, that's my report.
22:53<grumpy>freeside: have you heard from the directorate?
22:53<freeside>no.
22:53<grumpy>ok, so how do you know what they want?
22:53<Julian>Re (3) (zone cut), I have already declared that I'd be ok with dropping it and declaring that DNS server admins should use macro tools or something like that.
22:54<grumpy>I've been saying that I would consider dropping it since last Dec.
22:54<freeside>okie doke
22:54<grumpy>It appears to be the most controversial part of the draft.
22:54<freeside>how would you feel about dropping it, and the acrimonious language, from the draft?
22:54<Julian>Re (2) (bias to MAIL FROM), I think we could make it generic, but then it could NOT refer to v=spf1 records.
22:54<grumpy>zone cuts solve some problems, and causes others.
22:55<grumpy>Well, what exactly is the language that "they" don't like?
22:55<grumpy>("they" == MS?)
22:55<Julian>grumpy: they = Microsoft.
22:56<Julian>I think if they want us to change our draft, they should first undo their repurposing of v=spf1 records.
22:56<freeside>that's not going to happen.
22:56<Julian>Well, then...
22:56<Julian>...then I'm not going to listen to them.
22:56<Julian>(just speaking for me, personally.)
22:57<grumpy>they want to remove all references to the mail-from identity?
22:57<grumpy>e.g., make it completely generic?
22:57<freeside>wayne, do you have a 01 in the works or is 00 current?
22:57<csm>the area I *hear* about... that concerns me most... is the zone cuts
22:57<grumpy>Ihave a -01 in the works
22:57<csm>it seems to me that causes problems for more than Mickey from Redmond
22:57<grumpy>ok, is there anyone who is going to complain if I remove zone cuts?
22:58<csm>not me
22:58<Julian>Guys, think a moment about _why_ they want us to change our draft. I don't really get it yet, but it might have something to do with that they recognize that we have a more prominent voice than they do. I'm not sure.
22:58<freeside>which section of your draft talks about spf records not being used for other purposes?
22:58<grumpy>ok, they will be gone in the next release.
22:58<grumpy>freeside: in my opinion, or MS's opinion?
22:59<grumpy>Checking other identities against SPF records is
22:59<grumpy>NOT RECOMMENDED because there are cases that are known to
22:59<grumpy>give incorrect results.
22:59<Julian>grumpy: Wait. Can we have a formal resolution for that? Just so that there are no complaints afterwards?
22:59<grumpy>I do have that sentence in it.
22:59<Julian>(that = dropping the zone cut)
22:59<grumpy>motion: drop zone cut language from the spf-classic I-D
22:59<grumpy>seconds?
22:59<csm>second
23:00<grumpy>22:59u: yes
23:00<Julian>2259u: yes
23:00<MarkK>2259u: yes
23:00<freeside>2259u: yes
23:00<MarkK>Personally, I think we are way past dancing to MS's tune
23:01<csm>so ordered
23:01<Julian>MarkK: How do you mean that?
23:01<csm>now... on the repurposing of spfv1
23:01<freeside>dance! http://media.ebaumsworld.com/kittycatdance.wmv
23:01*Julian can't play .wmv.
23:01<csm>the repurposing is wrong IMO
23:01<csm>bu
23:02<freeside>bu bu
23:03<csm>*BUT*
23:03<csm>if they wanna make that a part of their SID thing... there is little we can do about it
23:03<csm>what we're doing is open...
23:03<csm>what they're doing is not
23:03<csm>I don't see why we even need to talk to them about it
23:03<Julian>I agree.
23:03<grumpy>Note that the sentence doesn't say you *can't* use it for other purposes, just that it is NOT RECOMMENDED
23:03<Julian>csm: I agree even more.
23:03<Julian>grumpy: "it" = ?
23:03<grumpy>SPF records
23:03<csm>right... and I think it ought to say...
23:03<Julian>v=spf1 records, I suppose.
23:04<csm>we cannot be held responsible for repurposing of something that was designed to be a part of our spec
23:04<MarkKr>darn this ISP *^&**%^ :(
23:04<grumpy>There certainly are known cases that simply will not work with the SPF records
23:04<Julian>csm: Absolutely.
23:04<csm>so I think the warning language should stay
23:04<csm>else we might get blamed for it when things start going hay wire
23:05<csm>and I fully believe they will for some
23:05<Julian>If you asked me, I'd say it should say MUST NOT instead of NOT RECOMMENDED.
23:05<grumpy>for what it is worth, "NOT RECOMMENDED" == "SHOULD NOT", according to IETF language
23:05<MarkKr>csm: so do I (and I hope to see part of that language in the sender-id postion letter, too)
23:05<csm>MarkKr: yup
23:05<csm>I wanna include that sort of language
23:05<grumpy>freeside: you said that MS also didn't like all the mail-from specific language?
23:06<csm>we *CANNOT* get ourselves into a fight with Mickey... but there's no reason to openly support them either
23:06<grumpy>is there something other than that line?
23:06<grumpy>freeside?
23:07<freeside>i suggest we take out the line
23:07<Julian>Motion: The SPF spec shall explicitly prohibit (MUST NOT) the use of v=spf1 records for anything else than checking of RFC 2821 identities.
23:07<freeside>Checking other identities against SPF records is NOT
23:07<freeside>RECOMMENDED because there are cases that are known to give incorrect
23:07<freeside>results.
23:07<csm>what line?
23:07<csm>I vehemently oppose that
23:07<Julian>Go on, turn my motion down. :)
23:08<csm>removing it is tantamount to supporting M$ on their complete bastardization of an open spec and I do not want to be a party to it
23:08<grumpy>freeside: I think we need to hear from MS? the IETF? as to what *exactly* they don't like
23:08<grumpy>there is no reason to guess
23:08<freeside>well, they want to use spf for PRA, and i don't think the technical specification is the right place to weigh against that. an applicability statement, maybe.
23:08<grumpy>if removing that line doesn't make them happy, then we are wasting our time.
23:09<freeside>but i really don't think that our argument against PRA, on a technical level, really stands, because the problems due to forwarding are just as big as the problems due to PRA.
23:09<freeside>if we're arguing that PRA doesn't work in some cases, then anyone can say that SPF doesn't work in forwarding cases.
23:09<grumpy>and we talk about the problems with forwarding and mailing lists in the spf-classic I-D
23:10<freeside>the real argument against PRA is that people can trick it, but MS have a response to that.
23:10<MarkK>I think 'NOT RECOMMENDED' should definitely stay; and I'm willing to go for 'MUST NOT' even; but certainly not striking this line altogether; athough there is something to be said for reserving this language for a positional paper
23:10<Julian>freeside: The current SPFv1 spec talks about v=spf1 records. Those can't be used for non-RFC2821 identities.
23:10*csm believes it should stay in the spec and *ALSO* go in a positional paper
23:11<csm>SPF is *NOT* SID
23:11<freeside>microsoft's smartscreen is an existence proof that they can, in fact, be used for non-rfc2821 identities :)
23:11<grumpy>"smartscreen"?
23:11<Julian>"the real argument against PRA is that people can trick it" -- I am not convinced that this is "the real argument".
23:11<freeside>they have some antispam software that uses SPF1 records today.
23:11<csm>second clunk
23:11<csm>sorry... wrong screen
23:12<csm>bah
23:12<Julian>freeside: I meant, _logically_ v=spf1 records can't be used for non-RFC2821 identities. Of course they can abuse them.
23:12<csm>honestly Meng...
23:13<MarkK>Julian: the real argument, imho, is that RFC 2821 AND RFC 2822 entities really cover different 'layers' of the communication
23:13<Julian>MarkK: That's one argument, right.
23:13<csm>I don't care if their thing succeeds or not... and they certainly don't care if ours does... why do you want to kow-tow to them this way?
23:13<grumpy>in RFC2821, it says that you shouldn't reject bogus HELO domains. the SPF I-D says, yeah, you can. Surely MS's I-Ds can say "please ignore the fact that there are known problems with applying SPF records to other contects"
23:13<csm>Lucas is whistling
23:14<csm>shit
23:14<grumpy>wrong screen?
23:14<MarkK>?
23:14<Julian>As long as we don't define RFC 2821 identities and RFC 2822 identities to be of identical meaning, we can't use v=spf1 records for RFC 2822 identities.
23:14<csm>yes
23:15<Julian>grumpy: Nowadays everyone is using EHLO (not HELO) anyway. And you can reject EHLO.
23:15<MarkK>Julian: exactly; also, RFC 28211 entities can be used for special inter-MTA communication (such as SRS), and should not be mixed with, and considered ientical, with RFC 2822 entities.
23:15<csm>freeside?
23:15<csm>you are being asked some questions?
23:16<freeside>ask again?
23:17<grumpy>I just can't see ignoring the fact that there are known cases that SPF records will fail when applied to other identities.
23:17<freeside>there are known cases that SPF records will fail when applied to mail-from, too.
23:17<csm>I don't care if their thing succeeds or not... and they certainly don't care if ours does... why do you want to kow-tow to them this way?
23:17<freeside>we have an answer for the forwarding situation.
23:18<freeside>microsoft has an answer for PRA.
23:18<freeside>it seems pretty analogous.
23:18<grumpy>I could see moving the sentence out of the normative "checking authorization" section and into the information part, where we discuss problems with mailing lists, greeting card sites, forwarders, etc.
23:18<Julian>No.
23:18<csm>No.
23:19<Julian>As long as draft-schlitt-spf-classic talks of v=spf1 records, this has to be normative.
23:19<grumpy>it would mean changing a sentence into a complete section with more explanation though.
23:19<csm>the thing is... this draft is to define spf
23:19<grumpy>freeside: is this draft supposed to be about SPF-classic?
23:19<Julian>By this, MS is asking us to acknowledge their repurposing of v=spf1 records. Only over my dead body. :)
23:19<csm>I fail to see any reason why we need to consider SID needs in it
23:20<freeside>the directorate wants a bundle of drafts that define sender id. maybe the ietf can approve an independent spf-classic draft.
23:20<Julian>freeside: Has the IETF directorate told you this?
23:20<grumpy>how do you know what the directorate wants?
23:20<freeside>that was my impression from the rounds and rounds of meetings we had.
23:20<Julian>Why can't draft-schlitt-spf-classic be independant?
23:20<freeside>if we decide we want to go a dual route, where the ietf puts up a set of drafts that define sender id, and a draft that defines spf classic, would that be okay with you guys?
23:21<grumpy>and have two, conflicting definitions of what the SPF record is supposed to mean?
23:21<csm>freeside: it's fine with me... I don't think I'm interested in dealing with SID at all
23:21<Julian>I want to finish the SPFv1 draft first, then we can talk about SPFv2/Sender-ID.
23:21<grumpy>do you think the IETF would allow that?
23:21<freeside>hey, they're experimentals :)
23:21<Julian>grumpy: Speculation is useless.
23:21<csm>a word from the CHAIR!
23:22<csm>this council... voted... and approved an spf spec
23:22<csm>no where in that vote was there any consideration of what Mickey from Redmond might or might not want and I am wholly opposed to thinking of it as an issue we need to consider
23:23<Julian>At least not without good reasons. Which I have not seen.
23:23<csm>this council... voted... and approved *CREATION* *OF* an spf spec
23:23<MarkK>csm: agreed; I am all for sticking with that, and not re-negotioating deal with MS midway, now
23:23<csm>there is no deal with Mickey
23:23<csm>and there is no way to deal with Mickey
23:23<grumpy>a possible good reason: the IETF may let MS define the SPF spec if we don't do what the IETF wants
23:23<Julian>csm: Well, maybe there is a deal between Meng and Microsoft. We don't know.
23:23<csm>they do what they want... let them... lets focus on what *OUR* purposes are
23:24<grumpy>Julian: don't be paranoid
23:24<grumpy>Julian: meng has said there isn't before, and I see no reason to doubt that answer
23:24<csm>grumpy: if they do that then the AMSG becomes even more important
23:24<grumpy>csm: very true
23:25<freeside>i've been wanting to cooperate with ms mostly because of the argument that disagreement hinders adoption.
23:25<Julian>grumpy: The IETF would ridicule themselves untrustworthy if they allowed Microsoft to define SPF.
23:25<MarkK>I mean 'deal' not as a formal deal, but 'deal' with them, as in allowing them to (re)write our draft/agenda; like I said earlier, I think we are way past that stage
23:25<freeside>adoption is the main goal...
23:25<Julian>(Big time. So they are not going to do that.)
23:25<grumpy>and I want cooperation with MS, Y!, ELNK, the IETF, SpamAssassin, and many others.
23:25*grumpy agrees with freeside about adoption
23:26<Julian>I'm not being paranoid, but Meng keeps insisting on doing what MS wants, and I am not convinced of the reasons he is giving.
23:26<grumpy>The problem is that in the spf spec, we spell out the problems with using SPF checks on forwarded email, mailing lists that don't follow RFC2822, etc. I think we *must* also warn against using SPF records for other identities as we *know* of problems when you do that.
23:27<grumpy>Julian: well, that makes no difference then. I can be a stubborn asshole at times, whether I'm being paid to be an asshole or not is irrelevant.
23:27<freeside>man, wouldn't it awesome if we could get paid to be an asshole?
23:28<grumpy>sure would.
23:28<MarkK>lol
23:28<Julian>I guess you can. Join the pro software patents lobby.
23:28<grumpy>Julian: true
23:29<Julian>Somebody please make a motion, or let's move on.
23:29<grumpy>ok, back to the point. 1) we need to know *exactly* what is being objected to. 2) whether the IETF cares 3) How we can justify not putting a warning about using other identities in the draft.
23:29<grumpy>ok
23:29<csm>well I have seen no motion to allow or suggest modification of the spec
23:30<grumpy>I move that we: 1) find out *exactly* what is being objected to. 2) whether the IETF cares 3) How we can justify not putting a warning about using other identities in the draft.
23:30<Julian>3 is going to be interesting.
23:30<csm>okay
23:30<csm>who is going to be charged with doing this?
23:30<Julian>I was going to ask the same thing.
23:31<grumpy>Well, if no one contacts us, then it is irrelevant and we move forward.
23:31<grumpy>until I hear from the IETF that they care, I'm going to assume that they don't.
23:31<csm>so I guess we consider it if and when they do
23:31<MarkK>csm; it would seem freeside has the most immediate access to those answers
23:31<grumpy>true
23:31<Julian>The IETF has said they'd contact Wayne or Meng. Wayne and Meng shall forward their inquiries and comments to spf-discuss.
23:31<grumpy>have MS send an email to spf-council and/or spf-discuss.
23:31<freeside>how would wayne feel about moving the NOT RECOMMENDED sentence from 2.4 to a longer explanation at the end?
23:31<grumpy>or, at very worst, the MARID list.
23:32<Julian>(or spf-council)
23:32<Julian>I am against moving it into a non-normative section.
23:33<grumpy>freeside: if that would make MS happen and let the draft go through, I could live with that. Otherwise, I've been fighting very hard to keep the size of the draft from growing and I don't want to replace one sentence with one section.
23:33<grumpy>s/MS happen/MS happy/
23:33<grumpy>but, I have yet to see any indication that the draft won't go through
23:33<Julian>"make MS happy and let the draft go through" -- Those are two separate things.
23:33<grumpy>Julian: right
23:34<Julian>I really don't care whether MS is happy. I just care about whether the draft goes through.
23:34<grumpy>I guess I'm being paranoid and assuming that MS may have some control with the IETF about what goes thorugh.
23:34*MarkK first wants to know whether freeside received official word from MS to have that language (re)moved; besides, unless MS has IETF in their pocket, since when does MS decide the draft goes through or not?
23:34<Julian>If MS was trustworthy, I might care about them being happy. But...
23:35<grumpy>Ok, besides that one line, there is also the HELO issue.
23:35<grumpy>again, we voted to have the HELO checking put back into the draft.
23:35<Julian>Exactly. Guess who made the motion.
23:36<Julian>http://spf.mehnle.net/Council_Resolution/11
23:36<grumpy>HELO checking has been in the spf-classic specs for as long as I've been around SPF. Making it optional w/o a null MAIL FROM has been around for about a year.
23:36<freeside>yes. i think HELO should be back in the draft.
23:36<grumpy>Julian: w/o checking, I think it was Meng who asked for it.
23:36<freeside>yep.
23:36<freeside>so, anyway, how about this.
23:37<freeside>i suggest the directorate go ahead and examine whatever they want to examine. MS would prefer that the directorate examine the Lentczner draft.
23:37<freeside>i suggest Wayne do another rev anyway and keep submitting that to the directorate.
23:37<freeside>when's the next IETF meeting, anyway?
23:37<freeside>and i suggest we leave the decision up to the IETF.
23:37<Julian>Does the IETF care which draft outside people want them to review?
23:37<grumpy>it is miniapolis(sp) and it is coming up soon.
23:37<freeside>yes, the IETF does care.
23:37<Julian>I mean, does it make sense to lobby the IETF with regard to such things?
23:38<csm>then I suggest we press the IETF to take Waynes draft
23:38<Julian>csm: Agreed.
23:38<MarkK>csm; agreed
23:38<grumpy>I have a lot of problems with the lentczner draft. It changes things in the way spf-classic works.
23:38<grumpy>csm: agreed.
23:39<freeside>i will tell the directorate that if they want to consider sender id, they should use the lentczner draft as part of that kit. i will also tell the directorate they should also consider the schlitt draft, or the next rev of it, at any rate.
23:39<freeside>and the final decision can be with them.
23:39<freeside>how does that sound?
23:39<grumpy>I don't like it.
23:39<freeside>because they can't really consider sender id using the ssssschlitt draft.
23:39<freeside>wow, my keyboard isss spazzing.
23:39<grumpy>draft-lentczner and draft-schlitt conflict on a lot of things.
23:40<MarkK>wayne, we are past that already: we alreasy agreed and voted on to do your draft; I feel no need for us, whatsoever, to retalk about rewriting your draft to accomodate the lentczner draft
23:40<MarkK>I say we oush to the wayne draft with the IETF
23:40<MarkK>push, even
23:40<Julian>No, the MarkL draft talks about v=spf1 records. It cannot seriously be considered if this legitimizes the use of v=spf1 records for RFC 2822 identities any more than draft-schlitt-spf-classic does.
23:41<csm>motion: promote waynes draft (series?) with the IETF
23:41<grumpy>freeside: I suggest we tell the directorate to use the MARID drafts that specify SPF2/[scope...] I-Ds
23:41<Julian>MarkK: Agreed. We voted to make Wayne the editor for a reason.
23:41<Julian>2341u: seconded
23:41<csm>votes?
23:41<Julian>2341u: yes
23:41<grumpy>2341u: yes
23:41<MarkK>2341u: yes
23:42<csm>2341u: yes
23:42<Julian>Hey, csm didn't abstain.
23:42<grumpy>heh
23:42<csm>I don't have to abstain
23:42<grumpy>freeside? votes?
23:42<Julian>csm: I know. It is still noteworthy. :)
23:43<csm>freeside?
23:43<freeside>sorry, my keyboard is misbehaving
23:43<freeside>2341u: abstain
23:43<grumpy>thoughts on telling the IETF to use the MARID SPF2.0/[scope] drafts?
23:43<csm>motion is carried
23:43<freeside>woot
23:43<csm>grumpy: hold on a damned minute... :-)
23:43<grumpy>NO
23:44<MarkK>maybe it's my paranoiy, I just get the nagging suspicion we may be submitting wayne's draft and that the IETF is just going to ignore it as irrelevant and go with the letnczner draft; THAT I would hate.
23:44<grumpy>I wanna be an asshole!
23:44*grumpy is grumpy
23:44<Julian>grumpy: I think we'd have to rework any SPFv2 drafts before pushing those.
23:44<csm>freeside: you are the ED. this is one of those times when the will of the council has over ridden your judgement. you must uphold the council's will on this okay?
23:45<Julian>MarkK: Then IETF would make itself irrelevant. We (the SPF project) do have a strong voice in the sender authentication world, I think.
23:45<grumpy>Julian: I agree that there still needs to be work on an SPFv2...
23:45<grumpy>It would also cause a huge stink
23:45<grumpy>which is what the IETF is trying to avoid
23:45<freeside>when you submit the new draft, wayne, i will do my best to ensure the directorate considers it.
23:45<csm>freeside: thank you
23:45<csm>now...
23:45<Julian>freeside: Will you also not promote the MarkL draft?
23:45<grumpy>freeside: thanks
23:45<csm>about the SID thing...
23:46<csm>one of the things that has been suggested is an SPFv2 spec right?
23:46<csm>hello?
23:47<Julian>freeside: Will you also not promote the MarkL draft?
23:47<grumpy>well, that was proposed in the MARID group
23:47<grumpy>I don't like the draft that they came up with, it was very much a rush job
23:47<MarkK>julian: I would like to see an answer to that question, too
23:47<csm>I am trying to suggest a way that M$ can get what they need
23:47<grumpy>s/M\$/MS/
23:47<freeside>how exactly do you want me to not promote the MarkL draft?
23:48<Julian>freeside: I'd like you not to actively promote it. That simple.
23:48<freeside>if i have to read your mind to do something, it's not very simple.
23:48<csm>he-he
23:49<Julian>If the IETF or MS decide they like the MarkL draft more than Wayne's, there's nothing we can do about it. But there is certainly no reason we (you) need to promote that.
23:49<csm>well presume for a moment that there are two drafts
23:49<csm>the one wayne is doing and the old one from MarkL
23:49<csm>we want waynes promoted... and nothing to be said about MarkL's
23:49<csm>simple enough?
23:50<Julian>Yes.
23:50<grumpy>I think it would be bad to have MarkL's draft, in its current state, be promoted by anyone.
23:50<grumpy>I think it is bad to have two standards for one thing.
23:50<csm>so now Meng doesn't have to read anybody's mind
23:50*MarkK suggest for this reason alone a PR would still be useful, so as also to officially declare we back a new draft (that of wayne); may give the IETF the push they need.
23:50<Julian>freeside: Of course you can personally promote MarkL's draft, but not as the ED.
23:51<csm>I also have a suggestion about how to help M$ with adoption of their spec
23:51<Julian>MarkK: True. A PR might be good for that.
23:51<freeside>ok, from now on, if the directorate asks me what draft they think should go in, then i will tell them the SPF Council wants the schlitt draft.
23:51<freeside>how does that sound.
23:51<Julian>freeside: ACK
23:51<MarkK>freside: I appreciate that
23:51<grumpy>freeside: sounds good to me
23:51<grumpy>thanks
23:51<Julian>freeside: Thank you.
23:52<csm>freeside: whether they asl you or not perhaps?
23:52<csm>that's promotion...
23:52<csm>I also have a suggestion about how to help M$ with adoption of their spec
23:52<Julian>asl?
23:52<grumpy>"asl"? as in a/s/l?
23:52<freeside><IETF_Director8> freeside: a/s/l?
23:52<csm>s/asl/ask/
23:52<grumpy>or "ask"
23:52<grumpy>hehh
23:52<MarkK>in thatshort of 'asshole'? :)
23:52<csm>I also have a suggestion about how to help M$ with adoption of their spec
23:52<csm>I also have a suggestion about how to help M$ with adoption of their spec
23:52<csm>I also have a suggestion about how to help M$ with adoption of their spec
23:52<csm>I also have a suggestion about how to help M$ with adoption of their spec
23:52<freeside><IETF_Director8> im in mineapolis, pay $500 and u can have me as long as u want
23:53<Julian>csm: Go on. :)
23:53<csm>SPFv2
23:53<Julian>(Man, these will be the hardest minutes ever.)
23:53<csm>we could easily do SPFv2 as a collaborative effort
23:53<csm>and I would have no problem with it
23:53<grumpy>(fyi; ietf-62: Mnneapolis, MN, USA Mar 6-11)
23:53<csm>simply because we would have a clean and green spfv1 classic spec!
23:54<grumpy>csm: agreed
23:54<MarkK>csm: agreed
23:54<Julian>I might have a problem with cooperating with MS on SPFv2 if they continue to insist on walking technically unsound paths.
23:54<csm>this council is obligated to get spfv1 done...
23:54<csm>it's a part of our mission
23:54<grumpy>one of the problems I have with the MARID SPFv2 spec is it doesn't allow easy re-use of SPFv1 records.
23:55<grumpy>domain owners *should* be able to easily say "yeah, for the PRA, use <this> SPFv1 record"
23:55<grumpy>domain owners should be able to say what they want
23:55<grumpy>the MARID SPFv2 specs have no way to say that.
23:55<csm>grumpy: I don't wanna do the SPFv2 spec in the meeting okay
23:55<grumpy>csm: agreed, but that was just an example.
23:55<Julian>csm: Agreed.
23:56<csm>but I think we could easily work with M$ and anybody else to get an SPFv2 spec done...
23:56<Julian>Yes.
23:56<grumpy>yes
23:56<csm>so if M$ wants a way to play with SPF that's it
23:56<MarkK>yes
23:56<grumpy>csm: please stop using M$...
23:56<csm>but spfv1 is not for them... never has been... never will be
23:56<Julian>Right.
23:56<MarkK>hear, hear
23:57<Julian>It could have been, if they hadn't been so stubborn on certain things.
23:57<grumpy>well, SPFv1 *is* for MS, if they use it in the ways that the domain owners intended.
23:57<csm>yes... it is
23:57<Julian>grumpy: But the world will know it is wrong.
23:57<csm>but they cannot be allowed to coopt it
23:57<Julian>I am personally going to make sure the world will know.
23:58<Julian>Oops. Forget that, I misread grumpy's statement.
23:58<csm>Julian: if they use it the way the spec if written they can use it just like anybody else can
23:58<grumpy>Ok, we are going on 2hrs now... where were we?
23:58<MarkK>I suggest we move on to the next item, btw; we seem stuck on this subject
23:59<grumpy>heh
23:59*grumpy points @ MarkK
23:59<Julian>(I read "if they use it on ways that the domain owners had not intended".)
23:59<csm>Julian: what's aggenda item #3?
23:59<MarkK>:)
23:59<Julian>csm: "ED's report". You mean #5?
23:59<csm>okay... yeah...
23:59<csm>whatever is next
--- Thu Feb 10 00:00:00 UTC 2005 ---
00:00<Julian>5. IIM and Domainkeys. Discussion.
00:00<grumpy>IIM/DK

This report was generated at Wed Feb 9 23:59:59 UTC 2005.