gmane.mail.spam.spf.council

trusted-forwarders.org (was: Obivous forged email reply with bad SPF info... Here is a header...)

Frank Ellermann — 2008-08-01T17:37:36

Oops. I propose to send that info to SPF ANNOUNCE, and put it on the main page as "news". Frank

Last erratum

Frank Ellermann — 2008-04-14T05:41:32

Please check out , the edit history claims "consensus that impossible labels are no TempError": | Be aware that if the domain owner uses macros (Section 8), it is possible | that this result is due to the checked identities having an unexpected | format. | | Please note that an unexpected can be also handled as no match, | ideally implementations document how they handle such issues. The outcome | for an unexpected before macro expansion might differ from the | outcome for an unexpected after macro expansion. Frank

Note Well

Frank Ellermann — 2008-03-20T14:31:15

For info, I've added links to and on the page next to the "SPF Discuss" entry, replacing the old "high traffic" indication. Frank

support problem

Alex van den Bogaerdt — 2007-12-15T14:26:32

Hi, Not much has happened in the past months but now a change will happen one way or the other. As you are probably well aware, the volunteer team is often not much more than just me myself and I. And I am going to quit as well. I think the council should decide how to continue with support, but of course I will not participate as a council member in that discussion. There are too much posts to the RT system which fall in one or more of the following categories: * a duplicate of a post to spf-help * a disgruntled person wishing to vent his/her anger * a lazy person which just copies the message and demands an explanation * spam Sorry, but I cannot cope with this anymore. I see three possible scenarios: 1: forget about RT (or alike) and let people post to spf-help 2: continue with RT (or alike) but with different people. If this is the way to go, ensure that a backlog of +2weeks does not occur anymore 3: let me continue but for a small fee to set my mind at ease. Let me explain #3: I think this will overcome many of the problems I encounter. For all four categories I mentioned I can live with it if they pay for the right to be annoying. Not that I expect many tickets to be opened, in fact I rely on that. Don't get me wrong: there are many questions asked which do not fall in these categories. The fee should be low enough not to be a problem for those who want to ask a question in private. Then again the fee should be high enough so that people will think twice before posting. It currently is not an option to ask Koen to change the RT setup. And since I am, most of the time, the only volunteer, I think it is okay when I come up with a completely different way of providing support, provided of course that this is the way to go. Alex P.S. I will continue as before during the remainder of 2007. ------------------------------------------- Archives: http://v2.listbox.com/member/archive/1943/=now RSS Feed: http://v2.listbox.com/member/archive/rss/1943/ Modify Your Subscription: http://v2.listbox.com/member/?member_id=6959930&id_secret=76427667-b256f9 Powered by Listbox: http://www.listbox.com

Old business

Frank Ellermann — 2007-11-15T11:28:47

Hi, I've recently forwarded the old question about the IETF list of "other lists" to the IPR WG again. See and for the results. Does that help with your concerns ? IIRC Julian was already satisfied before, if somebody else agrees and nobody disagrees I'd take it as "go". Frank ------------------------------------------- Powered by Listbox: http://www.listbox.com

spf2.0/mfrom and HELO (was: FTC Spam Summit)

Frank Ellermann — 2007-11-13T14:01:14

Jeff Macdonald wrote four months ago on the Discuss list: One of the papers was about Sender ID and states: | Sender ID acquires the sender's domain from | the SMTP "MAIL FROM" or EHLO command or from | a message header field determined by the | Purported Responsible Adress (PRA). In other words spf2.0/mfrom really is supposed to be the same as v=spf1, and it's good when the next Authentication-Results Internet Draft adds an smtp.helo row to Sender ID, it already has this for SPF. Frank References: http://ftc.gov/bcp/workshops/spamsummit/Microsoft-Sender -ID-Framework.pdf http://tools.ietf.org/html/draft-kucherawy-sender-auth-header-09 -- My reply to spf-discuss run into some mailing list problems, this attempt is a test (after *maybe* resubscribing GMane) ------------------------------------------- Powered by Listbox: http://www.listbox.com

Only Warning: Users with misbehaving auto-responders will be kicked off the SPF mailing lists

Julian Mehnle — 2007-07-27T22:36:23

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear subscribers to the SPF mailing lists, as the list moderators have been plagued for years now by automatic replies sent by the auto-responders of inconsiderate subscribers, these mailing lists' policy on the tolerance of such auto-replies is about to change, effective immediately. Auto-responders sending automatic messages (such as vacation messages) in reply to mailing list messages (be they directed to the message's author or, worse, to the entire mailing list) constitute rude and anti-social behavior, as they harass the list's subscribers, or even pollute the list, with irrelevant information. From now on, if your auto-responder gets caught sending auto-replies to postings on the SPF mailing lists, your subscription will be deactivated until it has been demonstrably fixed. This is your only warning. Such mailing list postings can be recognized from a "Precedence: bulk", "Precedence: list", or some "List-ID:" header. If you haven't already, go teach your auto-responders. The most prominent example of such misbehaving auto-responders has a "X-MimeOLE: Produced By Microsoft Exchange V6.5" header field. Be advised that Exchange's auto-responder not being easily fixable is not an accep- table excuse. Julian. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGqnNnwL7PKlBZWjsRAtY4AJ497Q1CiVLOEsyixuFQhZVyb167dgCeIrXO m4hD1eGwBNAzjoyC7/zJ3lM= =1LML -----END PGP SIGNATURE----- ------------------------------------------- Powered by Listbox: http://www.listbox.com

The next meeting after 2007-04-21

Julian Mehnle — 2007-06-22T23:21:51

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I apologize for not having managed to set up a council meeting for a while now. (I've been pretty much occupied with paid work and exams. Real life should be a bit easier on me for the next few months, though.) Let's try to get a meeting going within the coming weeks, shall we? I have yet to contact the IETF dnsop WG chairs, Paul Vixie, et al. about the "bogus TLD root server queries" issue, so there's nothing to report from that front. There are a few other things that require our attention, though (I may be missing some, so please bring up stuff I forgot): * Submit spf-discuss to the "others" list? ("note well" thread) * Status of the support team? Measures to undertake? * More potential RFC 4408 errata[1], plus the "RFC 2181 5/1" issue * The RFC 4408 compliance logo: license terms, etc. * Examine project status and update the project agenda[2] * Prospects for SPFv3? (Not all of these items need to be addressed immediately, but all of them should be sooner or later.) I could meet as soon as Sunday 2007-06-24, or the following weekend (or some other day (not ANY, though) during the week, but I assume weekends are still best for most of us). Julian. References: 1. http://www.openspf.org/RFC_4408/Errata 2. http://www.openspf.org/Project_Agenda -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGfFmQwL7PKlBZWjsRAsMeAKDVH8jtvqb4TAZOiZkcE3ODQ106PQCcDP7G dc7pWF1ocwzl/Z0iaZM5Ra0= =3KES -----END PGP SIGNATURE----- ------------------------------------------- Powered by Listbox: http://www.listbox.com

Fwd: Activity Report for spf-deployment

Julian Mehnle — 2007-06-13T17:09:08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, we just lost GMANE association of spf-deployment again. Does anyone know whether that was intentional? Julian. - ---------- Forwarded Message ---------- Subject: Activity Report for spf-deployment Date: Wednesday, 2007 June 13 15:33 From: listbox+reports< at >v2.listbox.com To: julian< at >mehnle.net In the last 7 days, New Subscribers: 0 Voluntary Unsubscriptions: 1 ngomssd-spf-deployment-1< at >m.gmane.org (Gmane Administrator) Unsubscriptions due to Bouncing: 0 Total number of subscribers: 538 To review your subscriber list, please visit http://v2.listbox.com/login/subscriber-list.html Cheers The Listbox Robot -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD4DBQFGcCS0wL7PKlBZWjsRAhaBAKCNRfUe1KZU4Jau610HrTLgfRsMhwCWPnf7 sPWwuBmH8T9FkiSYj7OYsA== =GQzT -----END PGP SIGNATURE----- ------------------------------------------- Powered by Listbox: http://www.listbox.com

Meeting 06-02

Frank Ellermann — 2007-05-20T20:32:59

Hi, how about a meeting 2007-06-02 ? Administrivia, Reply-To spf-discuss didn't work here, I've reset the old Reply-To list, sorry: xyzzy.claranet.de> Frank ------------------------------------------- Powered by Listbox: http://www.listbox.com

The next meeting after 2007-03-03

Julian Mehnle — 2007-03-31T00:57:57

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I was planning to get a meeting set up for this Saturday, but as the most pressing issues at this time are the various RFC 4408 errata, which require prior discussion on spf-discuss, it seems I failed to do so in sufficient advance. Therefore there won't be a meeting this week-end. I am going to raise the pending errata for discussion on spf-discuss in a structured way within the next few days, however, so we may be able to process the first batch of errata on the coming week-end, provided this doesn't conflict with your Easter holiday plans. Say, on Saturday 2007-04-07 at 16:00 UTC (this should be DST for all of us)? Julian. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGDbIXwL7PKlBZWjsRApuaAKCzglqTj6lj23GsZoJkp7XLa4cZGQCdEKmp YVOmFIubF/7gpDI6ekV04xU= =0VBf -----END PGP SIGNATURE----- ------------------------------------------- Powered by Listbox: http://www.listbox.com

SPF-council IRC logs for 2007-03-03

Wayne Schlitt — 2007-03-04T00:00:18

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: Julian Julian Mehnle MarkK Mark Kramer (asarian-host.net) SDGathman Stuart Gathman shew Mark Shewmaker willix William Leibzon freeside Meng Weng Wong gconnor Greg Connor grumpy Wayne Schlitt --- Sat Feb 24 13:22:14 UTC 2007 --- 13:22 ScottK: are you here? 13:41 ScottK: never mind. --- Sat Mar 3 15:50:14 UTC 2007 --- 15:50 T = -10min 15:50 If no one objects, we can just as well start now. 15:51 No objection, just give me 60 seconds to refill my coffee. 15:52 Meeting agenda: http://archives.listbox.com/spf-council/200703/0000.html 15:53 Does anyone desire changes to the agenda? 15:53 In particular, I propose that we discuss #1 before #2 (hence the order). 15:54 That sounds good. 15:54 * ScottK is reviewing the documentnow. 15:54 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 r18/19 have some information omitted (William had removed it when the page was still public). 15:57 Julian: I have a couple of editoria nits. Should I edit the page. 15:57 One s/that the fact/the fact that/ and publish 15:58 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 Is void DNS lookup a standard term? 15:58 alex_b, SDGathman: Have you reviewed r17 of the page? 15:58 Yes. 15:59 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 OK. In that case I think the definition needs to be more clearly established since we are defining a new term. 15:59 wait(alex_b); 16:00 here now 16:00 hi 16:00 Please read your scrollback buffer. 16:00 The real question is whether the _substance_ of the page is complete and correct. We can hash out the wording issues later. 16:00 The substance is correct. 16:00 Julian: OK. 16:00 maybe s/void/unsuccessful/ ? Actually I think void as explained is clearer 16:00 Agreed 16:01 The problem is not unique to SPF. 16:01 Especially the "Rebuttal to the Main Point of the Document" section. The hints sections aren't that important. 16:01 I agree it's correct, but needs a little wordsmithing IMO. 16:02 I propose that we choose one of us who wordsmithes the page later (or within the next few days). 16:03 "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 I will volunteer. 16:03 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 I think I know the least about this technically so it would make sense for me to edit it. 16:03 OK, why not. 16:03 Well, make it public then 16:04 * ScottK tried to get a hold of grumpy and failed. 16:04 ahold even 16:04 Do we need a motion? 16:04 Yes, grumpy was the one (besides William) who wanted the page to be kept private until "sensitive" information was removed. 16:05 In particular he wanted the examples to be removed. 16:05 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 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 Really, the MX record example is no zero-day exploit or something 16:06 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 Who thinks that the examples or any other _significant_ part of rev 17 should be removed? 16:06 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 Why is IN MX 0 localhost an "attack"? 16:07 Only for naive MTAs, or milters trying to send DSNs :-} 16:08 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 Not from me. 16:08 no 16:08 Motion: the analysis of Doug's paper should be published based on rev. 17, with editorial changes as needed. 16:08 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 1608u: seconded 16:09 Votes on 1608u? 16:09 1608u yes 16:09 08:yes 16:09 1608u yes 16:09 08: Yes 16:09 1608u: yes 16:09 So ordered. 16:09 ScottK: I'll revert the page. Please feel free to change/improve the page then. 16:10 SDGathman: I'd like to followup with you on your HELO/Mail From statement on #spf after the meeting. 16:10 ok 16:10 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 ScottK: Ah, don't rely on _me_ wrt that next week. ;-) 16:11 Anyone can remind me. 16:11 alex_b: I think we can edit it, but should review and agree to revisions before announcing it and declaring it final. 16:11 I don't plan anything major. 16:12 I think alex_b's comment about having an executive summary at the top is a good idea. 16:12 It doesn't need to be "final", it's a Wiki 16:12 OK. Not final then, official. 16:12 The exec summary should be added to the introduction section, which should then be renamed to "Summary" or something. 16:12 I agree. 16:13 alex_b: Don't let my volunteering to edit stop you from adding that if you want. 16:13 Anything else that should be discussed under agenda items #1 and #2? 16:14 Should we take steps to promote our analysis and counter-act DougO's FUD efforts? 16:14 Do we put the conclusion on the "errata" page as recommendation? (belongs to #1) 16:14 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 Excellent idea. 16:14 frank: You mean with the intent to add a section about this issue to RFC 4408bis? 16:15 ScottK, I agree 16:15 yes 16:15 errata should include a recommendation to limit "void" queries. 16:16 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 SDGathman: yes, another motion? 16:16 ... 16:16 (I was referring to adding a significant section to RFC 4408bis) 16:16 I think the RFC should not be so specific as to address draf-otis-etc 16:17 frank, you or I can add the "errata", and we can vote on it. 16:17 Sure, go ahead. 16:17 I think a short sentence or two on limiting void DNS lookups in section 10 would be useful. 16:17 it could (not should) contain some text about avoiding unnecessary lookups 16:17 It shouldn't mention otis. 16:17 Stuart: okay, Alex: of course 16:17 Just add that limit as a recommended extension to the general limits already mandated. 16:17 ScottK: The problem with such a limit is that it invalidates certain v=spf1 records that were valid in the past. 16:18 Julian, you wouldn't permerror, just give up and skip SPF. 16:18 Julian: That's why I wouldn't define a hard limit, just raise the concept. 16:18 What SDGathman said. 16:18 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 Julian: I don't think that policies with 2..5 void results are very useful in practice 16:19 v=spf1 ?a ?mx ?ptr ?all 16:19 SDGathman: What kind of "new" result would that be? "Abort"? 16:19 "Just pretend we aren't doing SPF for this email" 16:20 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 I.e. a Received-SPF: None would be incorrect also. 16:20 So no Received-SPF header at all. 16:20 disagree 16:20 The "SHOULD limit" is a TempError, isn't it? 16:20 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 Julian, good point. TempError would be reasonable. 16:21 I had talked to ScottK about that a few days ago, and we concluded that "PermError" would be more appropriate. 16:21 Except it's not really temporary. 16:21 "silent abortion" is fine, but nothing to be specified in 4408bis 16:21 TempError is for things that get better by themselves. 16:21 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 e.g. Received-SPF: ignored due to bad policy 16:22 Sounds like SPF should have had a "Sucks" result. 16:22 Isn't that what "PermError" is for? 16:22 alex_b: Then he should add an X-Did-not-do-spf-because header. 16:22 PermError is for syntax errors and contradictions. 16:22 whatever. the point is: don't do work and then silently ignore 16:22 Temp vs. Perm is irrelevant because it's an attack. In the spec. Perm has another meaning, IMO. 16:23 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 "Ignored" is for records that are technically valid, but you don't feel like processing for whatever reason. 16:23 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 SDGathman, like the one I showed at :19 16:24 So who's going to add this thing to the errata page? 16:24 Could we add an "Ignored" result that can only be used in Received-SPF? 16:24 We don't have to discuss this erratum now. 16:25 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 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 So who's going to add this thing to the errata page? 16:26 Stuart or me or anybody who feels like it 16:27 I will add it after more deliberation on what, if any, header field documentation there should be. 16:27 SDGathman: Good, thanks! 16:27 frank: I'd prefer someone to feel responsible for it so it doesn't get dropped. 16:27 Could always use an X-SPF-Ignored: Stupid policy header field. 16:28 Should we mention our response to draft-otis-... in our upcoming news announcement? 16:28 I feel responsible. 16:28 What upcoming news announcement? 16:28 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 (and/or to add whatever headers it likes.) 16:29 frank: The news announcement that we agreed to preprare at our last meeting. 16:29 Right. But with this limit, there is no 4408 result. 16:30 Remember that "PermError" was originally called "unknown". 16:30 That's exactly the stuff it was made for. 16:30 Oh, no, that shouldn't discuss DougO's recipes. 16:30 True, but the 4408 PermError tries to be deterministic and reproducable. 16:30 SDGathman: strong ACK 16:31 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 For an attack it should be reproducible, for a weird legit policy I'm not sure 16:31 SDGathman: "n void lookups" _is_ deterministic. 16:32 A local API could use 'unknown' to indicate that evaluation was aborted. Shoot, besides DoS limits, there could be a software error... 16:32 Maybe in another announcement, later, together with other errata issues 16:32 We cannot define new result codes in RFC 4408bis. 16:33 That's sure, no new result codes. 16:33 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 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 But for the time being, PermError would be an incorrect result. 16:34 Julian: Submit to Paul Vixie, asking him for comments, maybe? 16:34 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 Or what frank said is even better. 16:35 Why submit to PaulV _directly_? 16:35 ... and why to him only? 16:35 Maybe we need draft-ellerman-dns-void-lookup-limits to describe the generic solution to this generic problem? 16:35 LOL 16:36 Not kidding. 16:36 I know. I was just amused. 16:36 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 Good point, people might think it is an SPF problem if we are the only ones who address it. 16:37 people may think it is an SPF problem if we don't address is and DougO does 16:37 s/is/it/ 16:37 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 Frank is the only IETF draft author present... 16:38 I'd volunteer to send a notification about our conclusions to namedroppers and/or Paul Vixie. 16:38 ScottK: Anyone can be an I-D author. 16:38 IIRC the dnsext chair might be also interested (Peter Koch) that we get this right. 16:38 "we"? 16:39 Julian: Yes, but frank already knows how to do it and knows the community. 16:39 I don't know namedroppers, I only read the list (read only) 16:40 frank: I don't see Peter Koch (?) being a chair of dnsext: http://www.ietf.org/html.charters/dnsext-charter.html 16:40 frank: That puts you ahead of me. 16:40 And I also don't know PaulV or PeterK, FWIW 16:41 Sorry, I confused dnsext and dnsop 16:41 "[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 Yeah, dnsop. 16:41 http://www.ietf.org/html.charters/dnsop-charter.html 16:42 So, should I sent a notification to the dnsop list about our "draft-otis-spf-dos-exploit Analysis"? 16:43 No, send it to the Chair and Paul as PM asking them to review it. 16:43 Any comments from the others? 16:43 I'm mostly impartial. 16:43 I like what frank said. (:43) 16:43 no opinion here, too little background knowledge 16:44 SDGathman? 16:44 I don't know who to submit to. 16:45 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 Let's move on. 16:45 3. Conclusions on the project's involvement in the BITS proceedings 16:45 ... 16:46 ScottK: Did you hear anything from the BITS people, especially on the whitepaper they were planning to release? 16:46 No, I have not. 16:46 ... 16:47 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 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 OK. I will follow-up and see what I can find out. 16:47 ScottK: Weren't you going to set up a draft document specifying some kind of modifier? 16:48 Yes. 16:48 I have that on my todo list. 16:48 Don't mention this modifier idea, offer something else, a Web page making clear that FAIL should be rejected or similar. 16:48 I've started working on it. 16:49 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 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 That is an explicit statement giving the checker permission to reject fail outright. 16:49 Permission, but not an expectation. 16:49 ScootK: It does. It has a "SHOULD check at the border", and it's obvious what to if checking at the border. 16:50 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 frank: To argue the other way, SpamAssassin 3.2 will use received-spf added at the border for scoring. 16:51 ScottK, a waste of time for Fail, IMHO. 16:51 This isn't so much a BITS issue directly as that's the place where I came in contact with the issue. 16:51 Besides we have a pending erratum to introduce the lost "FAIL reject" error codes again (as per an appeal to the Council) 16:51 Yep. 16:52 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 ScottK: AFAIK SA can be used to reject if it runs as SMTP plugin, or is that nonsense? 16:53 frank: It can, but pre-queue content filtering is a fragile thing. 16:53 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 No modifier "I really mean it", this is the most harm you can do if you engage a committe chaired by Doug. 16:54 fail already gives explicit permission to reject. 16:54 frank: I'm staying away from that idea. It's more like if it fails, my preference is that you do X 16:54 ScottK: I could see having such a modifier. 16:54 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 Receiver still applies local policies which may or may not respect this preference. 16:55 frank: Comparison in what regard? 16:56 In all regards, return-path vs. PRA, what does this mean in practice. 16:56 You mean an elaborate version of http://www.openspf.org/SPF_vs_Sender_ID ? 16:56 I think it worth exploring ways that SPF can be complementary with post-envelope methods such as SID. 16:56 DKIM being another. 16:56 E.g. PRA doesn't need an arificial postmaster< at >helo. That's about the only real PRA advantage I'm aware of. 16:57 SPF is a front line defense. Can reject in SMTP envelope. 16:57 PRA isn't a bad idea 16:57 Even reject on reputation for results other than Fail. 16:57 it's just that they need to make one adjustment (read: fix a mistake) 16:57 If PRA was defined "From:/Sender:", I'd agree. But the Resent-*: stuff is idiotic. 16:58 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 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 Personally I don't see the value. The only header PRA protects is resent-sender. 16:58 ScottK is right. 16:59 OK, let's not discuss the merits of PRA right now. 16:59 But others do, so I'm willing to work on how our stuff complements theirs. 16:59 AlexB: Yes, but their SUBMIT idea won't fly, and without you're forced to check the DATA. 16:59 I think we need to get the reputation work rolling sooner rather than later. 17:00 frank, no. The idea would be to use both spf and pra. 17:00 but I agree with julian: this should not be a discussion about pra 17:01 For using both we need an analysis that routes permitted for mfrom are always a subset of routes permitted for PRA (example) 17:01 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 no comments 17:01 ok 17:01 that was meant to be (:01) = Not ascii art. 17:01 OK 17:01 4. Have a directory of commercial consulting services on the SPF website? 17:02 ... 17:02 Don't care. 17:02 I assume you all know http://www.spfconsulting.com . 17:02 We are already linking to that "website" from the SPF website. 17:03 ... from http://www.openspf.org/Support 17:03 * ScottK thinks it's better that way, but is not dis-interested. 17:03 Could be integrated if that's the point. 17:03 the problem: how broad should that list be, who decides who's on. 17:03 My suggestion is not and alex_b's problem statement is why. 17:03 The focus of http://www.spfconsulting.com is listing the volunteers of our support teams. 17:04 And I've never said no to someone that wanted to be listed. 17:04 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 Anybody who wishes to be hired and doesn't post nonsense on the discuss list. Is there a private channel somewhere? 17:04 frank: What do you mean by "private channel"? 17:04 But I think it better to leave that up to a private individual be the decider and not the council. 17:05 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 frank: The group of people that work on answering support tickets to the RT that gmc kindly provides have a mailing list. 17:06 The thing is that there seems to be a lack of such a list, despite the obvious demand. 17:06 Julian: My experience is that lots of people want help, but that very few are interested in actually paying for it. 17:07 Hmm. 17:07 ScottK: Do you think that they'd reather scrap SPF than pay someone? 17:07 rAther 17:07 I've had several contacts. 17:07 I've had several contacts too. 17:07 They were willing to pay, but each session was less than 15 minutes. 17:07 "Wow, it's that simple?" 17:08 In terms of my consulting business it's less than 1% or my work. 17:08 Questions answered in 5 minutes or less is free. 17:08 most problems aren't solved by spf alone 17:08 I had one go several hours, but that was for an ESP. 17:09 Perhaps you should institute a 5min < t < 30min => 50USD flat charge. 17:09 Or make that 25USD and a paypal donation button. 17:09 I did one where I answered for free and solicited a donation and got one. 17:09 Yes, it needs a Paypal button to be feasible for such short time intervals. 17:09 Could we use some infrastructure to that end to make life simpler for all those people giving "15min SPF consulting"? 17:10 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 I mean, you are _real_ professionals. Someone less experienced might take 2h for an equivalent consultance. 17:11 If _that_ one charged 50USD/h, he'd be much more expensive. 17:11 Well, we have https now, we can also do Paypal :-) Seriously, this part doesn't belong on openspf. 17:11 Agreed. I'm open to changing the spfconsulting site. I do not think it should be on openspf. 17:12 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 $_->fix_grammar(); 17:13 I'd rather make the separate site better than integrate it with openspf.org. I'm open to suggestions. 17:13 I have no objections not to involve openspf.org. 17:13 motion: 17:14 keep the link to volunteers also doing professional support, and keep the link to spfconsulting 17:14 do not provide more information on openspf 17:14 votes? 17:15 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 I don't think we need a motion to decide not to do anything different. 17:15 I agree with ScottK. 17:15 Julian: What can we do to make the current list more obvious? 17:16 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 agenda: 4. Have a directory of commercial consulting services on the SPF website? 17:17 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 Julian: Agreed. If people want to provide me offlist info about paypal links I'll add them. 17:18 I don't think we need a motion to do this stuff. 17:18 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 Glad we met your expectaions ;-) 17:19 expectations 17:19 FTR, does anyone know a service similar to but different from PayPal? I don't particularly like them... 17:19 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 alex_b: True. 17:19 a small precense on the openspf site is OK 17:19 Firstgate 17:19 But in the end SPF is still in their interest, even if they "have" to pay some small amount to get going. 17:20 true. 17:20 I'll have to investigate Firstgate. Thanks for the reminder. I think they're primarily EU-based. 17:20 OK, if there's nothing else to discuss, that would be about it. 17:20 _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 making the link to spfconsulting more prominent is, IMHO, not 17:21 Yes, and expensive (taking about 15% or more), and cooperating with the biggest UK provider. 17:21 frank: Do you know any others besides PayPal and Firstgate? 17:21 No. T-Com has some micropayment, but I never tested it. 17:22 Fine. 17:22 Anything else to discuss? 17:22 No. 17:22 I promise to kick off the "solicitation of news announcement items" and "project agenda rework" soon. 17:24 Motion: Adjourn the meeting. 17:24 2nd 17:24 Votes on 1724u? 17:24 :24 Yes 17:24 24 yes 17:24 1724u: yes 17:24 1724u yes 17:24 24 yes 17:25 The meeting is hereby adjourned. Thank you, gentlemen! 17:25 Bye (still pn #spf) This report was generated at Sat Mar 3 23:59:59 UTC 2007. ------------------------------------------- Powered by Listbox: http://www.listbox.com

The next meeting after 2007-02-17

Julian Mehnle — 2007-02-21T22:20:08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I don't think we urgently need to have a meeting this week, and as a matter of fact I won't be able to make a meeting on this Saturday in any case. However if you want to meet this week-end anyway, don't hesitate to go ahead. Otherwise, I'd say we meet again on 2007-03-03. For the record, these are discussion items I currently have on my list: * How public should the "draft-otis-spf-dos-exploit Analysis" page be? (Wayne/Julian) * Conclusions on the DDoS issue * Conclusions on the project's involvement in the BITS proceedings * Control over the openspf.* name service? (Wayne) * Compliance logo license terms? * Have a directory of commercial consulting services on the SPF website? * The contact form support effort * Report: status of the support team? * Change modus operandi of RT support team and/or the RT instal- lation? * Broaden scope of the contact form team/issue-tracker? * Ideas for getting better access to SPF deployment statistics in the future -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFF3MWYwL7PKlBZWjsRAhfsAKDEKC2qa6A5j0ex+GDhShXmC/GirgCfQpEH V/t0MFd4eJiQFiZAffE6aRo= =8Sqm -----END PGP SIGNATURE----- ------------------------------------------- Powered by Listbox: http://www.listbox.com

SPF-council IRC logs for 2007-02-17

Wayne Schlitt — 2007-02-18T00:00:16

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/02/17_irc_log.html. IRC nicknames: Julian Julian Mehnle MarkK Mark Kramer (asarian-host.net) SDGathman Stuart Gathman shew Mark Shewmaker willix William Leibzon freeside Meng Weng Wong gconnor Greg Connor grumpy Wayne Schlitt --- Sat Feb 17 16:06:59 UTC 2007 --- 16:06 grumpy: Are you there? 16:08 ScottK: Are you there? 16:12 Hello 16:13 hi all! 16:13 hi everybody, seems we're complete now 16:13 ScottK: ping 16:15 Crumble, I haven't done the summary yet. 16:16 SDGathman: Not a big problem. I don't think we'll be meeting every week in the future. There's just a lot of stuff to do at the term's beginning so the meetings are a bit crowded these days. It will pass. 16:17 ScottK: Can we start? 16:17 SDGathman: [[Council_Meeting/2007-02-09]] will do, maybe add some details 16:18 * alex_b sent mail to scott 16:18 Yeah 16:18 Sorry. Got held up be real life. 16:18 be/by 16:19 OK, let's start. 16:19 Meeting agenda: http://archives.listbox.com/spf-council/200702/0029.html 16:19 1. Send a news message to spf-discuss and/or spf-announce? Issue a joint SPF/Ubuntu press release? (Scott) 16:19 Should I start then? 16:19 Yeah. 16:20 As I think most of you know I've put a fair amount of effort into getting RFC 4408 compliant SPF checking into the next Ubuntu release 16:20 It's sched for April. 16:20 Their preferred MTA is Postfix and I've got both Perl and Python solutions in for that release. 16:21 AFAIK, this will be the first Linux distribution to have RFC 4408 compliant SPF checking available through their package management system. 16:22 They have a marketing group and so I think it would make sense to approach them and see if they would be interested in some kind of joint announcement or at least to make sure SPF checking gets mentioned in their release announcement. 16:22 Unless anyone has objections, I'll go work on that. 16:22 Questions? 16:22 Also, we may want to make a general news announcement to spf-announce or at least spf-discuss about any current news, our SPF packaging (Ubuntu, ...) efforts, the new council's project agenda (see meeting agenda item #2), and the council election outcome. 16:22 Sounds good. 16:23 Sort of what we did early last year... *searching in the archives* 16:23 * ScottK was thinking if we did a joint announcement with Ubuntu it would be put out on spf-announce when the distribution was released. 16:23 http://archives.listbox.com/spf-announce/200605/0001.html 16:23 or just before 16:24 (not exactly "early last year", though) 16:24 I think we should do something like that soon (and not wait until April/May) 16:25 I already told Scott: I'm not sure whether Ubuntu would want to make an announcement just about SPF. I think they probably want to announce their distro release and perhaps include a paragraph on SPF. We could do sort of the reverse. 16:25 I also think we should do a seperate announcement for Ubuntu (and FreeBSD when gmc thinks he's ready). 16:25 soon: spf expected to arrive in ubuntu 16:25 I agree about making an announcement a lot sooner than April/May. 16:25 Julian: Yes. Exactly. 16:25 april: ubuntu spf ready 16:26 announce on spf-announce and perhaps also spf-discuss 16:26 Both 16:26 and website ofcourse 16:26 Yes. 16:26 WRT Ubuntu, the current action is for me to go see what interest I can muster. Any objections? 16:26 * alex_b has no objections 16:26 So what would we have to do right now? (1) Contact Ubuntu people and learn their preferences, (2) prepare a standalone news announcement for spf-{announce,discuss}? 16:26 * frank fine 16:27 ScottK: Very good! 16:27 Julian: Yes and I will take care of #1. 16:27 OK. I'll start an initiative for collecting news items for #2 then. 16:27 Excellent. 16:28 On this note, we still need someone to work RPM packaging for Fedora (anyone?) 16:28 we're talking about two announcements, right? 16:28 frank: One now on project status one later when/near the Ubuntu release. 16:28 okay 16:29 I've published packages. 16:29 On sourceforge. 16:29 SDGathman: What packages? 16:29 Yes, but someone needs to get them submitted to Fedora. 16:29 pyspf, python-pyspf 16:29 I'm not familiar with the procedure for getting them into Fedora. 16:29 What's the relation between SF and the Python Cheeseshop? 16:29 None. 16:30 So they're redundant? 16:30 I copy to both. 16:30 OK. 16:30 Cheeseshop usually isn't much interested in RPMs or CVS. Sourceforge likes RPMS and CVS. 16:30 SDGathman: Can I talk to you about the test suite for a few minutes later? 16:30 Python Cheeseshop is important because it's a bridge for pyspf between where Terrence Way published pyspf and where Stuart publishes it since he took it over. 16:30 Both like tarballs. 16:31 I think that's all I had on that topic. 16:31 OK, anything else to discuss about news announcements or PRs? 16:31 If you have something, type "..." quickly. 16:32 ... 16:32 If there's anyway an announcement let's note the new https feature enabled by Julian 16:33 frank: Why do you think it is important? 16:33 I think that's a good point. 16:33 for anybody interested in #4 16:33 Personally, I doubt that anyone not involved in editing the site really cares. 16:33 * ScottK prefers to never submit passwords of any kind unencrypted. 16:33 s/4/5/ sorry 16:33 ScottK: That's why we're using Digest Auth on http: (not https:). 16:34 Maybe that should just get announced on webmasters (if it didn't already). 16:34 Julian: OK 16:34 frank: Let's rehash the "HTTPS announcement" issue later when we discuss #5, OK? 16:35 +1 16:35 So... 16:35 2. Refresh the project agenda. Do it right here and now? 16:35 The project agenda is here: http://www.openspf.org/Project_Agenda 16:35 I think we're now well into getting SPF into more MTAs and distros. A lot still needs to be done, but nonetheless... 16:36 We already started late, can we please set an end time for this? 16:36 * alex_b suggests 17:50 max 16:36 Well, the main question is whether we want to work on the agenda right here and now in the first place, or move the discussion on this issue to the council mailing list? 16:37 * ScottK has read it over and finds it pretty good. 16:37 * ScottK suggests council mailing list. 16:37 * alex_b agrees 16:37 SDGathman, frank? 16:37 Is anyone working on "Start a grassroots "Spread SPF!" campaign to get in touch with domain owners and ESPs/ISPs."? 16:38 list is fine 16:38 ScottK: AFAICT, not yet. But I definitely will be doing something about it this year. 16:38 Scott 16:38 OK. Sounds good. 16:38 Yes? 16:38 Of course I'd love others to join the effort. 16:38 I don't see "dealing with alleged errata". 16:39 That should be on the agenda for this year. 16:39 Why don't you add it on the wiki and then we can discuss on the list as necessary. 16:39 We talk about it where we are, ASRG, Spamcop list, EAI are my examples 16:39 "EAI"? 16:40 EAI is the IETF WG doing UTF8SMTP 16:40 Oh. 16:41 OK, so everyone please submit your thoughts about the project agenda to spf-council, CC: spf-discuss. 16:41 (under a common thread, so someone better start a thread with a good subject line) 16:41 Sounds good. 16:41 In the next days, right? 16:41 Another issue is improved instructions for forwarders. "Just do SRS" doesn't cut it. They need to protect their reputation. 16:41 SDGathman: Sounds like something to bring up on the mailing list. 16:41 Indeed 16:42 the discuss mailing list that is 16:42 BTW, I could see having distinct working groups of our own in the SPF community. 16:42 (distinct and _definite_ WGs, that is) 16:42 (i.e. each having a defined core group of workers) 16:43 Anyway... 16:43 3. How to process queued errata? 16:43 So we decided to move discussion about the project agenda to spf-{council,discuss}, so let's move on. 16:43 Right. 16:44 If anyone has a recommendation on this, please type ... so the rest of us know. 16:44 ... 16:44 * ScottK waits. 16:44 The collection isn't complete AFAIK. Let's put it into a draft 16:45 I think we should start one thread per erratum on spf-discuss and try to form a consensus on each. 16:45 Let the RFC-editor link to that draft 16:45 There is a hierarchy to the errata. 16:45 I don't think we should start a RFC 4408bis draft just yet. 16:45 The keystone is "greedy unknown-modifier". Several remaining points hinge on that decision. 16:45 There are "errata" and there are "FOObis" documents. I'm not yet convinced that we need a 4408bis document. 16:46 The errata aren't 4408bis 16:46 The key, I think is to quickly sort stuff into "erratum to go to the RFC editor" and "Good idea for next time". 16:46 Needs to be done before spec authors get run over by a bus. 16:47 Of course we need 408bis later (before 2008), but later 16:47 Ideally, any errata should have the approval of at least one spec author, plus a super majority (4+) of the council. 16:47 Sounds good. 16:47 +1 16:47 NAK, what's that 4+ ? 16:47 4 or 5 16:47 Supermajority (at least 4) 16:47 5 is too many. 16:48 4 is a rough consensus. 16:48 * alex_b means: 4 out of 5, or 5 out of 5 are both OK. 16:48 Perhaps we could say that one of those 4 could be a spec author (i.e. Wayne)? 16:48 Or won't you approve if all 5 agree? 16:48 Rough consensus is a magic word, not a number 16:49 frank: Only because you usually don't know how large your constituency is. 16:49 That's the case for the SPF Community 16:49 BTW, I think that it's not only the Council that counts for rough consensus 16:49 Absolutely. 16:50 4 of 5 votes on the council to agree that there is rough consensus in the broader community. 16:50 The thing is, some of the errata are controversial, and we need a way not to have debates going on endlessly. 16:50 * ScottK is extraordinarily unlikely to vote for something grumpy or freeside don't like, so doesn't feel a need for a special rule for them. 16:51 So we also need a 'not erratum' page. 16:51 I would like to propose a principle for judging errata... 16:51 * alex_b believes we (the council) are here to represent the community. If I notice a majority of the community agrees on something, I won't vote for the opposite... 16:51 If it's too controversial there's no rough consensus, but that's not related to majorities in the Council 16:51 _If_ we're going to do an errata document or even an RFC 4408bis one, we need to do it soon. Work on SPFv3 should start soon so it can be presented next year. 16:51 The principle of minimal changes to the spec. The more deletions/additions required for a fix, the worse the fix is. 16:52 "Not erratum" => FAQ. 16:52 OK 16:53 If the minimal fix isn't ideal - that should be improved in SPFv3 16:53 * ScottK will make a draft motion... 16:53 * Julian was going to but will now wait for ScottK's. 16:54 Draft Motion: RFC 4408 erratum will be discussed in the SPF community (spf-discuss and spf-devel) prior to council consideration. Erratum approved by at least 4 of 5 council members will be forwarded to the RFC editor via one of the RFC authors. 16:54 Comments? 16:55 valid if # of council members stays 5 16:55 Don't like it. 16:55 at least 75% 16:55 frank: What do you want? 16:55 s/of 5// 16:55 alex_b: 75% of what? 16:56 frank? 16:56 Julian: at least 75% of all council members 16:56 A simple collection of errata under our control (Our=community + council for disputes), + a link from the RFC-editor to this document 16:56 alex_b: That'll always be 4. Or what do you mean? 16:57 see :55 "valid if # of council members stays 5" 16:57 I object to _anyone_ being able to edit the list of (prospective) errata. 16:57 frank: What about the official RFC editor erratum list? 16:57 No new majority definitions please 16:58 Need 4 or 5 council member PLUS at least one spec author to approve. 16:58 RFC 2616 (HHTP) has "outsourced" errata 16:58 Because "original intent" is best judged by a spec author. 16:58 FTR: Not all errata can be judged according to "original intent". 16:59 Stuart: this can be a problem 16:59 It might require a fix, yes. 16:59 I'm fine with "at least one author", but not supermajorities 16:59 If frank objects to a supermajority rule, then I think we ought to not do that. 16:59 So I'd say council motion plus one author. 16:59 Well, I remember having had a 3:2 majority on a controversial issue in 2005, and it wasn't good... 17:00 Julian: agree 17:00 But since we have plus one author it'd really have to be 4:2. 17:00 If we can't get 4+ and spec author to agree, then we just leave it ambiguous. 17:00 And in any case supermajority requirements lead to deadlock. 17:00 And leave it out of the test suite - or allow alternative answers. 17:01 scenario: 17:01 I think 3:2 plus one mandatory spec author is OK. 17:01 wayne and meng both on the council 17:01 alex_b: They aren't on the council and any new council can have new rules. 17:02 ok. I'll shut up 17:02 Maybe Julian makes a motion this time... 17:02 ... 17:04 Draft Motion: RFC 4408 erratum will be discussed in the SPF community (spf-discuss), followed by council consideration. Any erratum approved by a majority (3+) of council members plus at least one of the RFC authors (Wayne, Meng) will be forwarded to the RFC editor. 17:04 Anyone want to change something substantial? 17:04 ... 17:04 The only question I would have would be frank's idea about outsourced errata. 17:04 What's "outsourced" errata? 17:05 See frank at :58 17:05 Yes, let's try to build our own collection, and when it's in a good state try to get a link from them to our document. 17:05 Oh, that. 17:05 Interesting concept. 17:06 Is that codified somewhere in the IETF rules? 17:06 My 2069 erratum is stil pending (about two years), the're horribly slow 17:07 No rule, the complete errata idea is an RFC-editor thing 17:07 OK. 17:07 An author (say Wayne) could ask them to set the link 17:08 * ScottK likes that better. 17:08 * ScottK types a motion. 17:08 (Real) Motion: Any RFC 4408 errata will be discussed in the SPF community (spf-discuss), followed by council consideration. Any erratum approved by a majority (3+) of council members plus at least one of the RFC authors (Wayne, Meng) will be forwarded to the RFC editor or put up as on an "outsourced" errata list for RFC 4408. 17:09 Seconded and yes 17:09 s/put up as on/put up on/ 17:09 for :08 17:09 Votes for 17:08? 17:09 :08 yes 17:09 :08 yes 17:09 1709 yes 17:09 17:08: yes 17:09 So ordered. 17:09 Second motion... 17:11 Motion: The council will ask Wayne and/or Meng to set a url on the openspf.org web site to be the official erratum list. Only council members/RFC authors will have write access to the list and none will modify the list until erratum are approved per the previous motion. 17:11 Wait. 17:11 s/set a url/use a document/ 17:11 "Only council members/RFC authors will have write access to the list" -- This may prove slightly difficult with the current website. There are others who have write access and who would be difficult to exclude, like Koen. 17:12 Perhaps this just needs to be reworded slightly. 17:12 OK. 17:12 use "are authorized" 17:12 Good! 17:12 ScottK: Can you reiterate? 17:12 ... 17:13 Motion: The council will ask Wayne and/or Meng to set a location on the openspf.org web site to be the official erratum list. Only council members/RFC authors are authorized to modify the list and none will modify the list until erratum are approved per the previous motion. 17:13 Anybody with write access can write, it's a Wiki. But the errata would reflect an SPF draft in svn/project/specs/draft 17:14 frank: That's why I said location so it can be a document/whatever we decided. 17:14 decide. 17:14 Wiki wiki whatever. It's a website, period. 17:14 Yes, it can be a Subversion resource. 17:14 :13 yes 17:14 17:13 seconded. 17:14 Votes on 17:13? 17:14 Yes 17:14 :13 yes 17:14 17:13 yes 17:15 1713 yes 17:15 So ordered. 17:15 Great, so we do have a plan! 17:15 4. How public should the "draft-otis-spf-dos-exploit Analysis" page be? (Wayne/Julian) 17:15 Let me explain briefly. 17:15 grumpy: Are you around? 17:15 ... 17:16 * ScottK doesn't think we should decide anything without grumpy as he is the one that had concerns. 17:16 But we can discuss, right? 17:16 I don't see a problem... 17:16 better data leads to better information... 17:16 * ScottK waits for Julian's ... 17:17 if we don't publish, people will read FUD instead of information 17:17 ... 17:17 Did anybody here read Doug's latest visions on the ASRG list? 17:17 The recent DNS DOS attack on root servers was via SPF, right? ;-) 17:17 SDGathman: Where did you hear that? 17:18 frank: No. Is there a url for the archive? 17:18 SDGathman is joking. 17:18 * ScottK is glad to hear that. 17:18 wait a moment 17:18 * ScottK waits for Julian and frank... 17:18 A few weeks back, I took the initiative and finished the "draft-otis-spf-dos-exploit Analysis" page that I had started several months ago. This is (essentially) how the page looked after I and Scott edited the page: http://www.openspf.org/auth?action=browse&id=draft-otis-spf-dos-exploit_Analysis&revision=17 17:19 The main point is that SPF is no worse than any other DNS RR - better, in fact, because of the MAX 10 limits. 17:19 * ScottK things frank will want https://www.openspf.org/auth?action=browse&id=draft-otis-spf-dos-exploit_Analysis&revision=17 17:19 http://permalink.gmane.org/gmane.ietf.asrg/11995 17:19 * ScottK looks. 17:19 Wayne and William then objected to listing the examples of how to reproduce a similar DoS attack with non-SPF RRs, and William edited the page as follows: http://www.openspf.org/auth?action=browse&diff=1&id=draft-otis-spf-dos-exploit_Analysis&revision=18&diffrevision=17 17:20 http://permalink.gmane.org/gmane.ietf.asrg/12003 17:20 Personally, I don't see why we should _not_ publish those examples, as they make our point much clearer, and the issue isn't really a secret anyway. 17:21 Apparently the MAAWG rejected Doug's latest SPF slides 17:21 "Apparently" -- how do you know? 17:21 And, could you please summarize "Doug's latest visions on the ASRG list"? 17:22 He said it in the thread, do you want an URL? 17:22 No. I would like a summary. 17:23 No, I'm not up to summarize Doug's reasoning, because it isn't reasonable from my POV. 17:23 URL of what? Of his slides? I can imagine what's in them. I'd prefer to know how you know that his slides were rejected by MAAWG. 17:23 Julian: I read the link that frank provided and it reads like the same old story to me. 17:24 Right. I thought that "DougO's latest visions" referred to something _new_. Maybe it didn't. 17:24 http://permalink.gmane.org/gmane.ietf.asrg/11982 started the thread, it contains the MAAWG bit. 17:24 My bottom line on the issue is that grumpy is the one that had objections and I respect his opinion enough that I'd like to hear from him that he's satisfied with the revisions or why not. 17:25 Modulo some time limit on grumpy being MIA. 17:25 Can you give a hint about what makes him doubt? 17:26 and/or: maybe start meeting agenda #5, and return here later 17:26 What Julian said at :19 captures his concern. What I don't know is if the later edits satisfied it. 17:26 There are real DNS based DOS attacks taking place. Grumpy doesn't want to provide free recipies to the bad guys. 17:27 SDGathman: But the recipies are already out in the wild. The only solution is to fix them, not desparately trying to hide them. 17:28 True. It would be convient if the latest attack was known to be an example comparable to SPF and Franks examples. 17:28 I didn't see what the source was. 17:28 alex_b: Do you have a time limit coming up soon? 17:29 ScottK: stopping at 1800Z would be nice 17:29 OK. 17:29 no true limit, if it's important, but still would like to avoid 17:29 BTW, I have recently incorporated the following limit option into Mail::SPF: http://spf.pastecode.com/14506 -- I think something similar (obviously slightly more sophisticated) might be a good BCP for all of DNS. 17:29 SDGathman: We should think about this for pyspf too. 17:31 Meta: What's that pastebin resource ? Looks good. 17:31 Julian: I don't think we are going to resolve this today. Since we are meeting weekly, I don't think pushing this off a week will hurt. 17:31 Anyway, here's my problem: Wayne has been unreachable for about two weeks now, and I don't like keeping the "draft-otis-spf-dos-exploit Analysis" page private much longer (1-2 weeks tops). I could see omitting the examples, but I don't like the idea a lot. 17:32 I'll take the action to try and hunt down grumpy in the mean time. 17:32 *sigh* OK. Anyone else have any preferences on how to proceed with that page? 17:33 If you do, please give us a ... 17:33 ... 17:33 Publish it with the examples redacted. 17:34 (frank: pastebin.com is a free service. You can pick any sub-domain. I picked spf.pastecode.com.) 17:34 And a note that the example will be published at a later date. 17:34 SDGathman: Does it hurt to wait a week? 17:34 Julian: thanks, it's nice 17:34 Vietnam was lost on the propaganda front. 17:35 FUD is dangerous. 17:35 Well, I didn't see any _general_ objections to publishing the page . 17:35 I agree with SDGathman. 17:35 Yes, but it's been sitting there for quite some time. Why will one more week will hurt. 17:35 The only contention is about whether to publish the examples. 17:35 BTW, speaking of FUD, I thought frank's rebuttal of Doug on ASRG was well done. 17:35 Haven't read it yet. 17:36 It's the :20 link above when you have time. 17:36 I think it's best to wait one more week and publish it all at once. Incremental release isn't a good idea in my book. 17:36 Well, OK, let's wait for another week. If we cannot get a hold of Wayne, we'll have to proceed on our own. 17:37 * ScottK will not strongly object to publishing without examples, however. 17:37 +1, needs no motion 17:37 or vote now for "if grumpy does not object, then ..." 17:37 can release next day 17:37 We can do that at the next meeting. 17:38 Any objections to waiting one more week? 17:38 no objections 17:38 No 17:38 * frank too 17:38 SDGathman: ? 17:39 I'm ok with waiting, but would prefer a redacted version now if available. 17:39 Maybe we can work out an intermediate version later. 17:39 Let's move on. 17:39 5. Broaden write access to the website? (Frank) 17:39 * ScottK suggests we wait, but if someone produces a redacted version we can discuss it on spf-council. 17:40 Frank, please explain your idea. 17:40 * ScottK notices we moved on... 17:41 Active folks on discuss should get write access on the Wiki as son as they want it (last example was Boyd a week ago) 17:41 Did someone say he couldn't have it? 17:41 There's one fact that you should consider: we cannot easily restrict certain pages more than others. 17:42 Therefore I do have a problem with handing out write access if it's just for one-time editing. 17:42 The procedure how to get it is completely unclear. It should be stated on the "unauthorized" page. 17:42 frank: agreed 17:42 There is the community part. Any page there can be copied/moved to the restricted part. 17:43 And restricted pages can be copied to the community wiki for editing. 17:43 Making that more convenient might be a plus. 17:43 also good. So, direct people (using an URL) to the right place for editing 17:43 So far _I_ have been setting up website accounts, but anyone with sudo access on earbone and the required knowledge can do it. Only those on the council (and Wayne) should be doing it, though. 17:43 The sandbox usage isn't too much fun 17:44 What "sandbox usage"? 17:44 The "unauthorized" page could provide a handy action link to copy the page to the Community section, and open an editor there. 17:44 the community sandbox 17:45 Well, I think we decided to set up a separate http://wiki.openspf.org sub-site a few months back. It's mostly a matter of setting it up, which I haven't found the time yet. 17:45 Then, it is just a matter of emailing the link to spf-webmasters - or maybe there could be a link to do that on pages copied from the official area. 17:45 Julian: what are the reasons for not handing out write access by default. Are you afraid it will be abused a lot ? 17:45 alex_b: Yes. Not necessarily right away. But one day, I am certain, we'd find the whole site crippled. 17:46 It could be restored, but it would probably be a lot of work. 17:46 so what would you do if you were affiliated with wikipedia? 17:46 Wikipedia has different enemies than we do. 17:46 Also, WP has a lot more active editors who are ready to undo damage. 17:47 Clearly we can't do a "recent change patrol" as on Wikipedia. Not accounts for everybody and their IP. But what about Boyd, Terry, etc. ? 17:47 Besides, we aren't a Wiki just because the site runs on a "wiki software". 17:48 I agree with Julian. There needs to be an "official" section of the site which is restricted. However, I am all for expanding use of the public section. 17:48 Well, I don't have a problem specifically with giving write access to Boyd and Terry. 17:48 But we can revert if necessary. 17:48 Revert what? 17:48 so to summarize ... 17:48 give access to good guys, revoke when they would turn bad ... 17:49 and have a more easy way for others to submit changes ... 17:49 which need to be moderated before being included in the official site 17:49 Whatever. Apparently Wayne reverted your analysis as discussed earlier today. 17:49 And for editors to accept proposed changes from community section. 17:49 Would be nice to click a button to make a proposed page in cummunity become the latest official version. 17:50 SDGathman: edit this page, select all, copy, go to new page, edit this page, paste, save isn't very hard. 17:50 Ok 17:51 There are some real world constraints: Most of the suggestions made require non-trivial changes to the software. I can do them, but it isn't likely to happen within the next two months (I'm also busy preparing for exams these days). 17:51 I'd suggest we limit our discussion today to things we can do with our existing infrastructure. 17:51 * alex_b seems to recall some talk about an already writable section? 17:51 Yes, the Community section. 17:51 alex_b: http://www.openspf.org/Community 17:51 plus http://www.openspf.org/Community/* 17:52 We can do new accounts, with a mailto-form on "unauthorized", can't we ? 17:52 (this is what's supposed to be moved to http://wiki.openspf.org eventually) 17:52 It is somewhat tricky for a non-privileged member to get a copy of an official page into the community section. 17:53 AFAICS, these are our (technical) options: Continue to hand out accounts to trustworthy folk. Direct others to use the community section. 17:53 SDGathman: They just need to ask on spf-webmasters. 17:53 http://www.openspf.org/Project_Agenda?raw=1 17:53 "?raw=1" 17:53 Ah, that answers that objection. 17:53 (I admit that isn't a well-known trick.) 17:54 Just need a note on that trick on the "unauthorized" page. That won't require any programming. 17:54 (Someone may want to add a note about it to the "Community" page.) 17:54 Tested it, it's no fun 17:54 re :52 is mail to webmasters generally answered soon? 17:54 I think the "Unauthorized" age should just direct to the "Community" page (later: http://wiki.openspf.org). 17:54 alex_b: Yes. 17:55 * ScottK needs to go in about 5 minutes. 17:56 Do we need a motion on this? 17:56 I don't think so. 17:56 frank: Are you happy? 17:56 I can edit the "Unauthorized" and "Community" pages. 17:56 Cool. 17:56 No. But I guess I'm free to improve the unauthorized page 17:57 Does that work for the moment then? 17:57 frank: Please don't make it say "anyone can get write access to the entire site" or anything to that effect. 17:57 of course not 17:58 However, "We welcome your proposed changes, here is how to make them..." would be good. 17:58 I'd suggest if anyone else has official business they type ... or we adjourn if not. 17:58 I think we're done. Any other issues? If so, type "..." quickly. 17:59 Motion: adjourn 17:59 17:59 seconded 17:59

The openspf.org certification authority

Julian Mehnle — 2007-02-11T00:55:33

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Quoting : There is an "openspf.org" OpenSSL (CA.pl-managed) certification authority in earbone:/etc/ssl/cas/openspf.org/. The CA's private key is protected with a passphrase, which is known to me. (Wayne, do you have a PGP key so I can send you the passphrase?) The CA has a public signing certificate[1]. References: 1. http://www.openspf.org/blobs/openspf.org-ca.pem -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFzmmFwL7PKlBZWjsRAporAKDWuprh2hBLmXWdwvebLm261dEXegCfb32Q /LcVJyV0d4GjevSL6fYbb3g= =0n2F -----END PGP SIGNATURE----- ------------------------------------------- Powered by Listbox: http://www.listbox.com

HTTPS + Basic Auth access to the website

Julian Mehnle — 2007-02-11T00:28:31

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Frank, I have configured the website to support HTTPS + Basic Auth access. If you go to , it will use Basic Auth instead of Digest Auth. uses an SSL certificate signed by our newly created "openspf.org" CA (see my following message to spf-council). I am having trouble accessing with Internet Explorer, however it works fine with Firefox and Opera. Scott reported that it works with Konqueror, too. I think the IE problem might have something to do with an incompatibility of the SSL certificate, however I totally lack the impetus to debug it. You're going to use some other "Mozilla 3.0" browser anyway. Let me know if you have any problems. Your password is the same as the one I had originally sent you for the Subversion repository on 2006-09-21 (ask if you don't have it anymore). You can change it by clicking on the "Change Password" link in the toolbar at the top of the website. - -- Note to self: This is a gross hack in the webserver configuration, essentially duplicating both /etc/thingy/instances/spf/httpd.conf and /etc/apache2/sites-available/spf (thus causing redundancy). The hack should eventually be undone, as soon as Frank gets a new web browser that supports HTTP Digest Auth (hint, hint). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFzmMzwL7PKlBZWjsRAlcuAJ9DzAYdm89FEDGxqcbF4PlCYXBJqACg08/B xrB+0ZfJFS2eqBtBU8wTfNE= =MnI3 -----END PGP SIGNATURE----- ------------------------------------------- Powered by Listbox: http://www.listbox.com

meeting schedule

Alex van den Bogaerdt — 2007-02-10T04:06:54

I requested to have different times during DST, so it seems only fair that I figure out how this works out. Motion: The 2007 council has a regular slot for optional meetings: on Saturdays, 16:00..18:00 UTC (15:00..17:00 UTC during DST times). USA: DST starts on Sun. March 11, 2007 at 02:00 local standard time (07:00 UTC) DST ends on Sun. November 4, 2007 at 02:00 local daylight time (06:00 UTC) EU: DST starts on Sun. March 25, 2007 at 01:00 UTC (02:00 LT for .de and .nl) DST ends on Sun. October 28, 2007 at 01:00 UTC (03:00 LT for .de and .nl) Meetings every saturday (tentative): [no meeting this saturday 10/2] 2007-02-17 16:00-18:00 UTC 2007-02-24 16:00-18:00 UTC 2007-03-03 16:00-18:00 UTC 2007-03-10 16:00-18:00 UTC 2007-03-17 15:00-17:00 UTC * DST in USA, not yet in EU 2007-03-24 17:00-17:00 UTC * DST in USA, not yet in EU 2007-03-31 15:00-17:00 UTC DST both in EU and in USA ... 2007-10-27 15:00-17:00 UTC DST both in EU and in USA 2007-11-03 15:00-17:00 UTC * DST in USA, no longer in EU 2007-11-10 16:00-18:00 UTC ... There are three dates when DST doesn't match. USA VA and MD: 11:00-13:00 LT Germany and the Netherlands: 17:00-19:00 LT except three times: Germany and the Netherlands*: 16:00-18:00 LT Alternatively we change time only when both have DST, in which case it would be: USA VA and MD*: 12:00-14:00 LT ------------------------------------------- Powered by Listbox: http://www.listbox.com