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/2007/03/03_irc_log.html.

IRC nicknames:
JulianJulian Mehnle
MarkKMark Kramer (asarian-host.net)
SDGathmanStuart Gathman
shewMark Shewmaker
willixWilliam Leibzon
 
freesideMeng Weng Wong
gconnorGreg Connor
grumpyWayne Schlitt

--- Sat Feb 24 13:22:14 UTC 2007 ---
13:22<alex_b>ScottK: are you here?
13:41<alex_b>ScottK: never mind.
--- Sat Mar 3 15:50:14 UTC 2007 ---
15:50<Julian>T = -10min
15:50<Julian>If no one objects, we can just as well start now.
15:51<ScottK>No objection, just give me 60 seconds to refill my coffee.
15:52<Julian>Meeting agenda: http://archives.listbox.com/spf-council/200703/0000.html
15:53<Julian>Does anyone desire changes to the agenda?
15:53<Julian>In particular, I propose that we discuss #1 before #2 (hence the order).
15:54<ScottK>That sounds good.
15:54*ScottK is reviewing the documentnow.
15:54<Julian>Please review rev 17: http://www.openspf.org/auth?action=browse&id=draft-otis-spf-dos-exploit_Analysis&revision=17
15:55*ScottK is looking
15:55<Julian>r18/19 have some information omitted (William had removed it when the page was still public).
15:57<ScottK>Julian: I have a couple of editoria nits. Should I edit the page.
15:57<frank>One s/that the fact/the fact that/ and publish
15:58<Julian>ScottK: Later, yes. The problem is we still don't know what revision to base future edits on (see agenda item #2 for that).
15:58<ScottK>Is void DNS lookup a standard term?
15:58<Julian>alex_b, SDGathman: Have you reviewed r17 of the page?
15:58<SDGathman>Yes.
15:59<Julian>ScottK: I don't think so. I used the term in the hope that it would be ovious after I had sort of explained it.
15:59<ScottK>OK. In that case I think the definition needs to be more clearly established since we are defining a new term.
15:59<Julian>wait(alex_b);
16:00<alex_b>here now
16:00<alex_b>hi
16:00<Julian>Please read your scrollback buffer.
16:00<Julian>The real question is whether the _substance_ of the page is complete and correct. We can hash out the wording issues later.
16:00<SDGathman>The substance is correct.
16:00<ScottK>Julian: OK.
16:00<frank>maybe s/void/unsuccessful/ ? Actually I think void as explained is clearer
16:00<ScottK>Agreed
16:01<SDGathman>The problem is not unique to SPF.
16:01<Julian>Especially the "Rebuttal to the Main Point of the Document" section. The hints sections aren't that important.
16:01<ScottK>I agree it's correct, but needs a little wordsmithing IMO.
16:02<Julian>I propose that we choose one of us who wordsmithes the page later (or within the next few days).
16:03<frank>"The problem" in DougO's strange parallel universe is MX (or NS), not SPF.
16:03*alex_b thinks the page should begin with a brief conclusion: the problem is not SPF specific, in fact SPF is designed to limit the damage
16:03<ScottK>I will volunteer.
16:03<Julian>The main issue is that I'd like to see the page being public again soon. We can always fine-tune it then.
16:03<ScottK>I think I know the least about this technically so it would make sense for me to edit it.
16:03<Julian>OK, why not.
16:03<frank>Well, make it public then
16:04*ScottK tried to get a hold of grumpy and failed.
16:04<ScottK>ahold even
16:04<frank>Do we need a motion?
16:04<Julian>Yes, grumpy was the one (besides William) who wanted the page to be kept private until "sensitive" information was removed.
16:05<Julian>In particular he wanted the examples to be removed.
16:05<ScottK>It would appear from my limited technical perspective that the document as written describes a threat concept, but that the details one would need to implement such an attack are absent.
16:05<Julian>In contrast to grumpy, I think the examples should stay because they help a lot with making it clear how this is not an issue specific to SPF.
16:05<frank>Really, the MX record example is no zero-day exploit or something
16:06<ScottK>I think DougO's paper has enough examples that ours don't matter. If you take his examples and add them to our statement that it's a gerneral problem, our examples don't tell you anything new.
16:06*frank agrees with Julian
16:06<Julian>Who thinks that the examples or any other _significant_ part of rev 17 should be removed?
16:06<SDGathman>There are already lots of MX attacks of a different nature, e.g. IN MX 0, localhost.
16:07*ScottK does not think stuff should be removed.
16:07<frank>Why is IN MX 0 localhost an "attack"?
16:07<SDGathman>Only for naive MTAs, or milters trying to send DSNs :-}
16:08<Julian>So, are there any objections to reverting to revision 17 and making the page public again, and then proceeding from there (wordsmithing, etc.)?
16:08<SDGathman>Not from me.
16:08<alex_b>no
16:08<frank>Motion: the analysis of Doug's paper should be published based on rev. 17, with editorial changes as needed.
16:08<SDGathman>DougO *has* provided a motivation to avoid checking both HELO and MFROM when possible.
16:08*ScottK is slightly nervous since willix and grumpy objected, but will defer to the assembled experience of the rest of the group.
16:08<Julian>1608u: seconded
16:09<Julian>Votes on 1608u?
16:09<frank>1608u yes
16:09<alex_b>08:yes
16:09<SDGathman>1608u yes
16:09<ScottK>08: Yes
16:09<Julian>1608u: yes
16:09<Julian>So ordered.
16:09<Julian>ScottK: I'll revert the page. Please feel free to change/improve the page then.
16:10<ScottK>SDGathman: I'd like to followup with you on your HELO/Mail From statement on #spf after the meeting.
16:10<SDGathman>ok
16:10<ScottK>Julian: Will do. If I haven't made changes by Wednesday, please poke me about it.
16:10*alex_b thinks this page is important enough to discuss changes before actually implementing them
16:10<Julian>ScottK: Ah, don't rely on _me_ wrt that next week. ;-)
16:11<ScottK>Anyone can remind me.
16:11<ScottK>alex_b: I think we can edit it, but should review and agree to revisions before announcing it and declaring it final.
16:11<ScottK>I don't plan anything major.
16:12<Julian>I think alex_b's comment about having an executive summary at the top is a good idea.
16:12<frank>It doesn't need to be "final", it's a Wiki
16:12<ScottK>OK. Not final then, official.
16:12<Julian>The exec summary should be added to the introduction section, which should then be renamed to "Summary" or something.
16:12<ScottK>I agree.
16:13<ScottK>alex_b: Don't let my volunteering to edit stop you from adding that if you want.
16:13<Julian>Anything else that should be discussed under agenda items #1 and #2?
16:14<Julian>Should we take steps to promote our analysis and counter-act DougO's FUD efforts?
16:14<frank>Do we put the conclusion on the "errata" page as recommendation? (belongs to #1)
16:14<ScottK>I'd say once we get it edited we use it as a standard answer if someone brings it up, but I don't think we ought to promote it.
16:14<SDGathman>Excellent idea.
16:14<Julian>frank: You mean with the intent to add a section about this issue to RFC 4408bis?
16:15<alex_b>ScottK, I agree
16:15<frank>yes
16:15<SDGathman>errata should include a recommendation to limit "void" queries.
16:16<Julian>I don't think this is necessary. _If_ there will be an RFC 4408bis (still v=spf1), we may want to add a small section pointing to said page, but I don't think a general discussion of the issue is warranted, given the fact that it's not an SPF-specific issue.
16:16<frank>SDGathman: yes, another motion?
16:16<alex_b>...
16:16<Julian>(I was referring to adding a significant section to RFC 4408bis)
16:16<alex_b>I think the RFC should not be so specific as to address draf-otis-etc
16:17<SDGathman>frank, you or I can add the "errata", and we can vote on it.
16:17<Julian>Sure, go ahead.
16:17<ScottK>I think a short sentence or two on limiting void DNS lookups in section 10 would be useful.
16:17<alex_b>it could (not should) contain some text about avoiding unnecessary lookups
16:17<SDGathman>It shouldn't mention otis.
16:17<frank>Stuart: okay, Alex: of course
16:17<SDGathman>Just add that limit as a recommended extension to the general limits already mandated.
16:17<Julian>ScottK: The problem with such a limit is that it invalidates certain v=spf1 records that were valid in the past.
16:18<SDGathman>Julian, you wouldn't permerror, just give up and skip SPF.
16:18<ScottK>Julian: That's why I wouldn't define a hard limit, just raise the concept.
16:18<ScottK>What SDGathman said.
16:18<Julian>Besides, it still needs to be shown that SPF is better suited as a vehicle for such a DoS attack than, say, MX or NS.
16:18<frank>Julian: I don't think that policies with 2..5 void results are very useful in practice
16:19<alex_b>v=spf1 ?a ?mx ?ptr ?all
16:19<Julian>SDGathman: What kind of "new" result would that be? "Abort"?
16:19<SDGathman>"Just pretend we aren't doing SPF for this email"
16:20<Julian>I don't think new results should be introduced. If we recommend an abortion, the result should either be "TempError" or "PermError" (preferred).
16:20<SDGathman>I.e. a Received-SPF: None would be incorrect also.
16:20<SDGathman>So no Received-SPF header at all.
16:20<alex_b>disagree
16:20<frank>The "SHOULD limit" is a TempError, isn't it?
16:20<Julian>SDGathman: This kind of silent abortion would be a completely new concept to SPF. I don't think that's a good idea.
16:20<SDGathman>Julian, good point. TempError would be reasonable.
16:21<Julian>I had talked to ScottK about that a few days ago, and we concluded that "PermError" would be more appropriate.
16:21<ScottK>Except it's not really temporary.
16:21<frank>"silent abortion" is fine, but nothing to be specified in 4408bis
16:21<ScottK>TempError is for things that get better by themselves.
16:21<alex_b>If the receiver thinks an SPF record is bogus, or stupid, but still wants to receive the message, a header should reflect this.
16:22<alex_b>e.g. Received-SPF: ignored due to bad policy
16:22<SDGathman>Sounds like SPF should have had a "Sucks" result.
16:22<Julian>Isn't that what "PermError" is for?
16:22<ScottK>alex_b: Then he should add an X-Did-not-do-spf-because header.
16:22<SDGathman>PermError is for syntax errors and contradictions.
16:22<alex_b>whatever. the point is: don't do work and then silently ignore
16:22<frank>Temp vs. Perm is irrelevant because it's an attack. In the spec. Perm has another meaning, IMO.
16:23<Julian>I mean, I agree that PermError should be more structured into error sub-codes in SPFv3, but we cannot do that in SPFv1.
16:23<SDGathman>"Ignored" is for records that are technically valid, but you don't feel like processing for whatever reason.
16:23<ScottK>I do think though that we need to be careful not to create new limits that prevent currently legitimate records from becoming permerror.
16:23<alex_b>SDGathman, like the one I showed at :19
16:24<Julian>So who's going to add this thing to the errata page?
16:24<SDGathman>Could we add an "Ignored" result that can only be used in Received-SPF?
16:24<Julian>We don't have to discuss this erratum now.
16:25<frank>ScottK, you got that backwards, if there are _legit_ policies running into an anti-attack limit they'd NEED a PermError. But I think there aren't. Can we test this somehow?
16:26<ScottK>I'm just saying that the first thing to try is to define the anti-attack limit to not affect legit policies, but if we can't do that, I agree.
16:26<Julian>So who's going to add this thing to the errata page?
16:26<frank>Stuart or me or anybody who feels like it
16:27<SDGathman>I will add it after more deliberation on what, if any, header field documentation there should be.
16:27<Julian>SDGathman: Good, thanks!
16:27<Julian>frank: I'd prefer someone to feel responsible for it so it doesn't get dropped.
16:27<SDGathman>Could always use an X-SPF-Ignored: Stupid policy header field.
16:28<Julian>Should we mention our response to draft-otis-... in our upcoming news announcement?
16:28<frank>I feel responsible.
16:28<frank>What upcoming news announcement?
16:28<Julian>SDGathman: Well, look, the caller of an SPF implementation can always inspect the policy and decide not to act on the result returned by the SPF implementation.
16:29<Julian>(and/or to add whatever headers it likes.)
16:29<Julian>frank: The news announcement that we agreed to preprare at our last meeting.
16:29<SDGathman>Right. But with this limit, there is no 4408 result.
16:30<Julian>Remember that "PermError" was originally called "unknown".
16:30<Julian>That's exactly the stuff it was made for.
16:30<frank>Oh, no, that shouldn't discuss DougO's recipes.
16:30<SDGathman>True, but the 4408 PermError tries to be deterministic and reproducable.
16:30<frank>SDGathman: strong ACK
16:31<Julian>spf-announce has quite broad an audience, so that would be a good channel to discount DougO's propaganda. However I, too, see the problem that it might confuse readers.
16:31<frank>For an attack it should be reproducible, for a weird legit policy I'm not sure
16:31<Julian>SDGathman: "n void lookups" _is_ deterministic.
16:32<SDGathman>A local API could use 'unknown' to indicate that evaluation was aborted. Shoot, besides DoS limits, there could be a software error...
16:32<frank>Maybe in another announcement, later, together with other errata issues
16:32<Julian>We cannot define new result codes in RFC 4408bis.
16:33<frank>That's sure, no new result codes.
16:33<Julian>OK... there doesn't seem to be anything near a consensus on whether/how our findings should be propagated. Should we at least publish it on the namedroppers or other IETF lists?
16:33*ScottK thinks we are probably about done with this topic in spf-council for today.
16:33<SDGathman>I would go along with adding a void lookup limit to the other DoS limits with a PermError result as part of an official errata. Provided there was plenty of research as to what legit policies would be broken.
16:34<SDGathman>But for the time being, PermError would be an incorrect result.
16:34<frank>Julian: Submit to Paul Vixie, asking him for comments, maybe?
16:34<ScottK>Julian: I think publishing on namedroppers would be appropriate to make sure they are aware of the issue and seek feedback on the void lookups concept.
16:34<ScottK>Or what frank said is even better.
16:35<Julian>Why submit to PaulV _directly_?
16:35<Julian>... and why to him only?
16:35<ScottK>Maybe we need draft-ellerman-dns-void-lookup-limits to describe the generic solution to this generic problem?
16:35<Julian>LOL
16:36<ScottK>Not kidding.
16:36<Julian>I know. I was just amused.
16:36<frank>Because on #### Grumpy already talked with Paul. I'm NOT going to post on namedroppers, never. ASRG is possible, but the thread is already dead there.
16:36<SDGathman>Good point, people might think it is an SPF problem if we are the only ones who address it.
16:37<alex_b>people may think it is an SPF problem if we don't address is and DougO does
16:37<alex_b>s/is/it/
16:37<Julian>I agree that discussing the issue with a generic (non-SPF) focus probably is the best thing to do, but personally, I don't have the time to do _that_.
16:38<ScottK>Frank is the only IETF draft author present...
16:38<Julian>I'd volunteer to send a notification about our conclusions to namedroppers and/or Paul Vixie.
16:38<Julian>ScottK: Anyone can be an I-D author.
16:38<frank>IIRC the dnsext chair might be also interested (Peter Koch) that we get this right.
16:38<Julian>"we"?
16:39<ScottK>Julian: Yes, but frank already knows how to do it and knows the community.
16:39<frank>I don't know namedroppers, I only read the list (read only)
16:40<Julian>frank: I don't see Peter Koch (?) being a chair of dnsext: http://www.ietf.org/html.charters/dnsext-charter.html
16:40<ScottK>frank: That puts you ahead of me.
16:40<frank>And I also don't know PaulV or PeterK, FWIW
16:41<frank>Sorry, I confused dnsext and dnsop
16:41<Julian>"[The dnsext] WG is focused on advancing the zone transfer, update, notify and DNSSECbis documents to Draft standard." -- Maybe dnsext isn't the right place? Wasn't there another DNS WG? dnsops?
16:41<Julian>Yeah, dnsop.
16:41<frank>http://www.ietf.org/html.charters/dnsop-charter.html
16:42<Julian>So, should I sent a notification to the dnsop list about our "draft-otis-spf-dos-exploit Analysis"?
16:43<frank>No, send it to the Chair and Paul as PM asking them to review it.
16:43<Julian>Any comments from the others?
16:43<Julian>I'm mostly impartial.
16:43<ScottK>I like what frank said. (:43)
16:43<alex_b>no opinion here, too little background knowledge
16:44<Julian>SDGathman?
16:44<SDGathman>I don't know who to submit to.
16:45<Julian>OK, I'll do as frank said. If the dnsop chair(s) and/or Paul Vixie think that making our analysis more public would be a good idea, we can still do that then.
16:45<Julian>Let's move on.
16:45<Julian>3. Conclusions on the project's involvement in the BITS proceedings
16:45<Julian>...
16:46<Julian>ScottK: Did you hear anything from the BITS people, especially on the whitepaper they were planning to release?
16:46<ScottK>No, I have not.
16:46<ScottK>...
16:47<ScottK>The only followup I've had from the meeting was on the idea of adding a modifier to SPF records to allow senders to express an intent to have Fail messages rejected.
16:47<Julian>I think we should get something out of our involvement with them. At the very least, we should stay in touch with them. If we can get said whitepaper, that would be great.
16:47<ScottK>OK. I will follow-up and see what I can find out.
16:47<Julian>ScottK: Weren't you going to set up a draft document specifying some kind of modifier?
16:48<ScottK>Yes.
16:48<ScottK>I have that on my todo list.
16:48<frank>Don't mention this modifier idea, offer something else, a Web page making clear that FAIL should be rejected or similar.
16:48<ScottK>I've started working on it.
16:49<SDGathman>4408: A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking software can choose to mark the mail based on this or to reject the mail outright.
16:49<ScottK>frank: The problem is that RFC 4408 doesn't agree with that statement.
16:49*ScottK wishes it said something different, but it says what it says.
16:49<SDGathman>That is an explicit statement giving the checker permission to reject fail outright.
16:49<ScottK>Permission, but not an expectation.
16:49<frank>ScootK: It does. It has a "SHOULD check at the border", and it's obvious what to if checking at the border.
16:50<Julian>IMO, their (BITS') problem is that they are too focused on mechanics rather than semantics. As long as it is clear that an SPF "Fail" means "forgery", it doesn't really matter what happens to the mail.
16:50<ScottK>frank: To argue the other way, SpamAssassin 3.2 will use received-spf added at the border for scoring.
16:51<SDGathman>ScottK, a waste of time for Fail, IMHO.
16:51<ScottK>This isn't so much a BITS issue directly as that's the place where I came in contact with the issue.
16:51<frank>Besides we have a pending erratum to introduce the lost "FAIL reject" error codes again (as per an appeal to the Council)
16:51<Julian>Yep.
16:52<ScottK>I think I can write a modifier that will at worst do no harm to existing records and may help with deployment. I think it's worth exploring.
16:52<frank>ScottK: AFAIK SA can be used to reject if it runs as SMTP plugin, or is that nonsense?
16:53<ScottK>frank: It can, but pre-queue content filtering is a fragile thing.
16:53<Julian>On a note related to agenda item #3, should we try to establish contact with other potential SPF "user groups" (similar in nature to BITS)? Contact MAAWG & Co. again? Perhaps in conjunction with our (hopefully soon to start) SPFv3 efforts?
16:53*ScottK is not opposed, but has neither time nor contacts.
16:53<frank>No modifier "I really mean it", this is the most harm you can do if you engage a committe chaired by Doug.
16:54<SDGathman>fail already gives explicit permission to reject.
16:54<ScottK>frank: I'm staying away from that idea. It's more like if it fails, my preference is that you do X
16:54<Julian>ScottK: I could see having such a modifier.
16:54<frank>We have nothing for MAAWG at the moment, I'm playing with the idea of a comparison of v=spf1 with spf2.0/pra.
16:55<ScottK>Receiver still applies local policies which may or may not respect this preference.
16:55<Julian>frank: Comparison in what regard?
16:56<frank>In all regards, return-path vs. PRA, what does this mean in practice.
16:56<Julian>You mean an elaborate version of http://www.openspf.org/SPF_vs_Sender_ID ?
16:56<ScottK>I think it worth exploring ways that SPF can be complementary with post-envelope methods such as SID.
16:56<ScottK>DKIM being another.
16:56<frank>E.g. PRA doesn't need an arificial postmaster@helo. That's about the only real PRA advantage I'm aware of.
16:57<SDGathman>SPF is a front line defense. Can reject in SMTP envelope.
16:57<alex_b>PRA isn't a bad idea
16:57<SDGathman>Even reject on reputation for results other than Fail.
16:57<alex_b>it's just that they need to make one adjustment (read: fix a mistake)
16:57<Julian>If PRA was defined "From:/Sender:", I'd agree. But the Resent-*: stuff is idiotic.
16:58<ScottK>I'd look at it the other way around. Some entities have, for whatever reason, decided to do PRA checking. If they do SPF first, if they get SPF Pass, but PRA Fail, they can safely bounce to Mail From...
16:58<frank>Yes, an elaborated version in IETF terms, listing the various "tags" like v=spf1 etc. Actually more in the style of the Wikipedia "principles of operation" for Sender ID.
16:58<ScottK>Personally I don't see the value. The only header PRA protects is resent-sender.
16:58<Julian>ScottK is right.
16:59<Julian>OK, let's not discuss the merits of PRA right now.
16:59<ScottK>But others do, so I'm willing to work on how our stuff complements theirs.
16:59<frank>AlexB: Yes, but their SUBMIT idea won't fly, and without you're forced to check the DATA.
16:59<Julian>I think we need to get the reputation work rolling sooner rather than later.
17:00<alex_b>frank, no. The idea would be to use both spf and pra.
17:00<alex_b>but I agree with julian: this should not be a discussion about pra
17:01<frank>For using both we need an analysis that routes permitted for mfrom are always a subset of routes permitted for PRA (example)
17:01<Julian>Unless someone has something to say related to our BITS involvement, I'd prefer to move on with our agenda.
17:01*ScottK agrees with Julian ):01)
17:01<alex_b>no comments
17:01<frank>ok
17:01<ScottK>that was meant to be (:01) = Not ascii art.
17:01<Julian>OK
17:01<Julian>4. Have a directory of commercial consulting services on the SPF website?
17:02<Julian>...
17:02<frank>Don't care.
17:02<Julian>I assume you all know http://www.spfconsulting.com .
17:02<Julian>We are already linking to that "website" from the SPF website.
17:03<Julian>... from http://www.openspf.org/Support
17:03*ScottK thinks it's better that way, but is not dis-interested.
17:03<frank>Could be integrated if that's the point.
17:03<alex_b>the problem: how broad should that list be, who decides who's on.
17:03<ScottK>My suggestion is not and alex_b's problem statement is why.
17:03<Julian>The focus of http://www.spfconsulting.com is listing the volunteers of our support teams.
17:04<ScottK>And I've never said no to someone that wanted to be listed.
17:04<Julian>However I think we may want to set up a list of professional SPF (and related technology) consultants directly on the SPF website. Any comments?
17:04<frank>Anybody who wishes to be hired and doesn't post nonsense on the discuss list. Is there a private channel somewhere?
17:04<Julian>frank: What do you mean by "private channel"?
17:04<ScottK>But I think it better to leave that up to a private individual be the decider and not the council.
17:05<Julian>I wouldn't put a list on the SPF website under council control. It could even be part of the community section (or http://wiki.openspf.org, as soon as I manage to set that up).
17:05<ScottK>frank: The group of people that work on answering support tickets to the RT that gmc kindly provides have a mailing list.
17:06<Julian>The thing is that there seems to be a lack of such a list, despite the obvious demand.
17:06<ScottK>Julian: My experience is that lots of people want help, but that very few are interested in actually paying for it.
17:07<Julian>Hmm.
17:07<Julian>ScottK: Do you think that they'd reather scrap SPF than pay someone?
17:07<Julian>rAther
17:07<SDGathman>I've had several contacts.
17:07<ScottK>I've had several contacts too.
17:07<SDGathman>They were willing to pay, but each session was less than 15 minutes.
17:07<SDGathman>"Wow, it's that simple?"
17:08<ScottK>In terms of my consulting business it's less than 1% or my work.
17:08<SDGathman>Questions answered in 5 minutes or less is free.
17:08<alex_b>most problems aren't solved by spf alone
17:08<ScottK>I had one go several hours, but that was for an ESP.
17:09<Julian>Perhaps you should institute a 5min < t < 30min => 50USD flat charge.
17:09<Julian>Or make that 25USD and a paypal donation button.
17:09<ScottK>I did one where I answered for free and solicited a donation and got one.
17:09<SDGathman>Yes, it needs a Paypal button to be feasible for such short time intervals.
17:09<Julian>Could we use some infrastructure to that end to make life simpler for all those people giving "15min SPF consulting"?
17:10<ScottK>If people have paypal buttons they want to add to the site, I'll add them to the current site, just send me the info.
17:10<Julian>I mean, you are _real_ professionals. Someone less experienced might take 2h for an equivalent consultance.
17:11<Julian>If _that_ one charged 50USD/h, he'd be much more expensive.
17:11<frank>Well, we have https now, we can also do Paypal :-) Seriously, this part doesn't belong on openspf.
17:11<ScottK>Agreed. I'm open to changing the spfconsulting site. I do not think it should be on openspf.
17:12<Julian>What I'm essentially trying to say is that some infrastructure to make it easier for consulting _consumers_ to get high quality service for some non-free price, setting that up would probably be worthwhile.
17:12<Julian>$_->fix_grammar();
17:13<ScottK>I'd rather make the separate site better than integrate it with openspf.org. I'm open to suggestions.
17:13<Julian>I have no objections not to involve openspf.org.
17:13<alex_b>motion:
17:14<alex_b>keep the link to volunteers also doing professional support, and keep the link to spfconsulting
17:14<alex_b>do not provide more information on openspf
17:14<alex_b>votes?
17:15<Julian>It's just that right now, consumers usually don't see a lot of choices: either get free service from our support teams, which I think are unnecessarily giving away their great work _completely_ for free, or seek a professional consultant and pay a lot of money -- and finding one is usually more work than most are willing to do.
17:15<ScottK>I don't think we need a motion to decide not to do anything different.
17:15<Julian>I agree with ScottK.
17:15<ScottK>Julian: What can we do to make the current list more obvious?
17:16<Julian>It's not just about making the list more obvious. It's about getting small amounts of service for non-zero amounts of money.
17:17<alex_b>agenda: 4. Have a directory of commercial consulting services on the SPF website?
17:17<Julian>Maybe we can tackle the issue like so: (1) make spfconsulting.com more obvious through links and referrals from the support team(s), (2) and add some (micro)payment infrastructure to the page.
17:17<ScottK>Julian: Agreed. If people want to provide me offlist info about paypal links I'll add them.
17:18<ScottK>I don't think we need a motion to do this stuff.
17:18<Julian>alex_b: It was just an idea of mine. I didn't expect to get a lot of traction for hosting the list on openspf.org directly.
17:18<ScottK>Glad we met your expectaions ;-)
17:19<ScottK>expectations
17:19<Julian>FTR, does anyone know a service similar to but different from PayPal? I don't particularly like them...
17:19<alex_b>the way I see it: SPF is free. People should not be lead into believing we expect them to pay us in order for them to be able to deliver mail
17:19<Julian>alex_b: True.
17:19<alex_b>a small precense on the openspf site is OK
17:19<frank>Firstgate
17:19<Julian>But in the end SPF is still in their interest, even if they "have" to pay some small amount to get going.
17:20<alex_b>true.
17:20<Julian>I'll have to investigate Firstgate. Thanks for the reminder. I think they're primarily EU-based.
17:20<Julian>OK, if there's nothing else to discuss, that would be about it.
17:20<alex_b>_how_ it is presented is not my main issue. Make it clear that support from "the incrowd" is fast thus cheap, is OK
17:21<alex_b>making the link to spfconsulting more prominent is, IMHO, not
17:21<frank>Yes, and expensive (taking about 15% or more), and cooperating with the biggest UK provider.
17:21<Julian>frank: Do you know any others besides PayPal and Firstgate?
17:21<frank>No. T-Com has some micropayment, but I never tested it.
17:22<Julian>Fine.
17:22<Julian>Anything else to discuss?
17:22<ScottK>No.
17:22<Julian>I promise to kick off the "solicitation of news announcement items" and "project agenda rework" soon.
17:24<Julian>Motion: Adjourn the meeting.
17:24<ScottK>2nd
17:24<Julian>Votes on 1724u?
17:24<ScottK>:24 Yes
17:24<frank>24 yes
17:24<Julian>1724u: yes
17:24<SDGathman>1724u yes
17:24<alex_b>24 yes
17:25<Julian>The meeting is hereby adjourned. Thank you, gentlemen!
17:25<frank>Bye (still pn #spf)

This report was generated at Sat Mar 3 23:59:59 UTC 2007.