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.
| --- Thu Jan 13 00:24:14 UTC 2005 --- |
| 00:24 | <Julian> | freeside: You wanted to send some sort of "we're back" message to spf-announce, and then let my press release message through. Are you going to do that anytime soon? |
| 04:45 | <freeside> | oh yeah. |
| 04:45 | <freeside> | i forgot. |
| 04:45 | <freeside> | i thought i sent one. |
| 04:45 | <freeside> | i'll try again. |
| --- Sat Jan 15 02:21:21 UTC 2005 --- |
| 02:21 | <Julian> | Do we have a meeting tomorrow? |
| 02:27 | <grumpy> | My guess: no, there will not be a meeting tomorrow. I'll show up anyway, just like on Wed. |
| 02:27 | <Julian> | What is going on with all the council members?? |
| 03:24 | <csm> | as far as I know there will be a meeting tomorrow |
| 03:24 | <csm> | and I am working on the agenda now |
| 04:12 | <freeside> | honk |
| 04:16 | <csm> | b0rk! |
| 13:26 | <Julian> | csm: Huh? 16 Jan 2005? That's Sunday. |
| 16:42 | * | Julian will be there at 19:00 UTC. |
| 18:44 | <Julian> | Anyone there? |
| 18:56 | <csm> | yes |
| 18:56 | <csm> | I am here |
| 18:56 | <csm> | hopefully this doesn't get fscked up... |
| 18:56 | <csm> | I put the wrong dat on the damned thing |
| 18:56 | <csm> | though it will work for me I was really hoping to get this done today |
| 18:56 | <Julian> | T -4min |
| 18:58 | <grumpy> | here! |
| 18:58 | <grumpy> | sorry I'm late, just got back from seeing my kids |
| 18:58 | <Julian> | grumpy: You're not late. |
| 18:59 | <grumpy> | huh... ok. "I cut it too close" then... ;-) |
| 18:59 | <grumpy> | any word from freeside or MarkK? (I saw that MarkK said he would be here on spf-council) |
| 19:00 | <Julian> | Weee! |
| 19:00 | <grumpy> | He Mark! |
| 19:00 | <MarkK> | hey wayne; good to be back :) |
| 19:01 | <grumpy> | freeside? |
| 19:02 | <grumpy> | Well, the council meeting is on freeside's calendar... |
| 19:02 | <grumpy> | wait, no, I was looking at Dec. :-< |
| 19:02 | <Julian> | I think that's a recurring calendar item. |
| 19:02 | <Julian> | Nothing on his calendar for today? |
| 19:03 | <grumpy> | nope |
| 19:03 | <MarkK> | at least we have quorum again |
| 19:03 | <grumpy> | all the meetings are listed as Wed for January |
| 19:03 | <Julian> | Hmm |
| 19:03 | <grumpy> | anyone going to the MIT spam conference next week? |
| 19:03 | <Julian> | I'd like to have Meng present. |
| 19:04 | <MarkK> | so would I, Julian |
| 19:05 | <grumpy> | ME TOO!!! </aol> |
| 19:05 | <Julian> | We haven't had an ED's report for ages. |
| 19:05 | <grumpy> | Well, on #spf, Meng said that he didn't have anything to report |
| 19:06 | <Julian> | LOL, I doubt it. |
| 19:08 | <Julian> | Last call, Mr. Freeside, please come to the reception. |
| 19:10 | <grumpy> | csm: you still around? |
| 19:11 | * | grumpy sighs |
| 19:11 | <Julian> | :-) |
| 19:12 | <grumpy> | s/)/|/ or s/)/(/ .... |
| 19:12 | <csm> | hey |
| 19:12 | <grumpy> | ? |
| 19:12 | <grumpy> | time to get the show on the road? |
| 19:13 | <grumpy> | it doesn't look like freeside is going to show up |
| 19:13 | <Julian> | Let's defer the ED's report until the end of the meeting. |
| 19:13 | <csm> | okay... well we have a quorom |
| 19:13 | <MarkK> | you mean s/\)/|/ or s/\)/(/, right? :) |
| 19:13 | <csm> | so we can meet |
| 19:13 | <grumpy> | MarkK: :-P |
| 19:13 | <MarkK> | ok, let's meet |
| 19:14 | <grumpy> | yeah |
| 19:14 | <csm> | the meeting is called to order |
| 19:14 | <csm> | approval of the minutes |
| 19:14 | <csm> | Julian: URL? |
| 19:14 | <Julian> | http://spf.mehnle.net/Council_Meeting/2004-12-29 |
| 19:14 | <grumpy> | I have read the minutes and I approve them. |
| 19:15 | <Julian> | I posted them a while ago to spf-discuss. |
| 19:15 | <grumpy> | yep |
| 19:15 | <MarkK> | read them and approve them |
| 19:15 | <csm> | ditto |
| 19:15 | <csm> | motion? |
| 19:15 | <Julian> | Please approve the 2004-12-29 minutes. |
| 19:15 | <grumpy> | seconded |
| 19:15 | <csm> | second? |
| 19:15 | <csm> | okay votes |
| 19:16 | <Julian> | 1915u: yes |
| 19:16 | <grumpy> | 19:15u yes |
| 19:16 | <MarkK> | 1915u: yes |
| 19:16 | <csm> | so ordered |
| 19:16 | <csm> | Chairman's report (1 minute or less as I have little to say) |
| 19:17 | <csm> | the chair is working on the spf position vis-a-vis Sender-ID |
| 19:17 | <csm> | I had hoped to finish it this week |
| 19:17 | <csm> | *BUT* I have been in hell, of a sort |
| 19:17 | <csm> | soooo it is delayed but still in progress |
| 19:17 | <csm> | the chair is also working on an AMSG proposal which should go out to the AMSG list by monday |
| 19:18 | <csm> | and that's it from here |
| 19:18 | <Julian> | csm: How's the press release draft going? |
| 19:18 | <csm> | oye... |
| 19:18 | <Julian> | I mean the PR re: the IETF submission of the SPF spec. |
| 19:18 | * | csm feels as though he may have forgotten something... (as I said... I have been in hell) |
| 19:18 | <csm> | ah yes |
| 19:18 | <csm> | forgot... |
| 19:18 | <Julian> | No problem, I'm just asking. |
| 19:18 | <csm> | sorry |
| 19:18 | <MarkK> | csm: will the sender0id draft contain a discussion about PRA? |
| 19:18 | <csm> | will work on it... |
| 19:18 | <csm> | MarkK |
| 19:19 | <csm> | yes but am trying to handle it gently |
| 19:19 | <MarkK> | thank you :) |
| 19:19 | <csm> | a clear statement that does not engender a fight is not so easy to accomplish |
| 19:19 | <csm> | we are not ready for fights yet... |
| 19:19 | <Julian> | I can imagine. |
| 19:19 | <MarkK> | csm: exactly; it is difficult |
| 19:19 | <csm> | much as I would like to think we are... we are not |
| 19:20 | <csm> | anyway... that' |
| 19:20 | <csm> | s it from me... |
| 19:20 | <Julian> | We need to get ready for fights ASAP, see agenda item #6. |
| 19:20 | <csm> | yeah yeah |
| 19:20 | <csm> | okay so the ED is not here... |
| 19:20 | <csm> | the next item is 4 |
| 19:20 | <csm> | ublish statistics for the spf-private list |
| 19:20 | <csm> | P |
| 19:20 | <csm> | I have no objection |
| 19:20 | <Julian> | The point for that is to show that not much secret stuff is going on. |
| 19:20 | <csm> | and I think it will actually be quite revealing... |
| 19:21 | <csm> | yes |
| 19:21 | <Julian> | Yep. |
| 19:21 | <csm> | no problem here |
| 19:21 | <Julian> | Motion: $item |
| 19:21 | <csm> | Julian: do you accept responsibility for this action? |
| 19:21 | <Julian> | csm: Yes. |
| 19:21 | <grumpy> | the script I used to use to post stats on spf-discuss could be used for spf-private |
| 19:21 | <Julian> | grumpy: Oh, ok. |
| 19:21 | <grumpy> | it doesn't do subjects though. |
| 19:21 | <grumpy> | just number of posts and by whom |
| 19:21 | <csm> | good... subjects are out of bounds |
| 19:21 | <Julian> | The subjects should remain secret, but the number of distinct subjects should be public. |
| 19:22 | <grumpy> | So, should I start running it? |
| 19:22 | <csm> | yes that's fine |
| 19:22 | <Julian> | grumpy: Can I see a sample output? |
| 19:22 | <csm> | okay so Julian made a motion... the rest is technical details and I don;t care |
| 19:23 | <csm> | votes? |
| 19:23 | <grumpy> | (wayne@footbone) $ SPF_post_stats -mtime -7 | head |
| 19:23 | <grumpy> | Total Posts: 157 Individuals Posting: 38 |
| 19:23 | <grumpy> | 29 Julian Mehnle <bulk@mehnle.net> |
| 19:23 | <grumpy> | 14 william(at)elan.net <william@elan.net> |
| 19:23 | <grumpy> | 14 Hannah Schroeter <hannah@schlund.de> |
| 19:23 | <Julian> | (that would be 1921u) |
| 19:23 | <grumpy> | 1921u yes |
| 19:23 | <MarkK> | 1921u: yes |
| 19:23 | <Julian> | 1921: yes |
| 19:23 | <csm> | so ordered |
| 19:23 | <grumpy> | ok, they will start running every monday |
| 19:23 | <csm> | next is item 5 |
| 19:23 | <csm> | The SPF specification |
| 19:24 | * | grumpy hides |
| 19:24 | <csm> | discusssion? |
| 19:24 | <Julian> | grumpy: Very good. Will you post them to spf-discuss or to spf-council? |
| 19:24 | <csm> | is this a progress report... what? |
| 19:24 | <grumpy> | spf-council... |
| 19:24 | <Julian> | grumpy: Ok. |
| 19:24 | <grumpy> | I think Julian put that stuff on the agenda |
| 19:24 | <Julian> | csm: It's sort of status report, yes. |
| 19:24 | <csm> | right he did... |
| 19:24 | <csm> | okay so lets here the "report" ;-) |
| 19:24 | <grumpy> | do you want me to address it? |
| 19:25 | <Julian> | a. IANA allocation of a new SPF DNS RR type. |
| 19:25 | <csm> | yes please |
| 19:25 | <Julian> | Uhm, ok. |
| 19:25 | <MarkK> | yes, please |
| 19:25 | <Julian> | General status report first. |
| 19:25 | <grumpy> | ok, there has been no real work on the IANA allocation of either a new RR type nor the Received-SPF header. |
| 19:25 | <Julian> | grumpy: Go on. |
| 19:25 | <Julian> | What needs to be done? Do we need to write to IANA? |
| 19:25 | <grumpy> | It is my understanding that both of those will happen as part of the I-D becoming an RFC |
| 19:26 | <grumpy> | once IANA allocates a new RR, I have no idea how to get the NS vendors to create on, but I'll investigate when the time comes |
| 19:26 | <grumpy> | I'm not sure what the question on HELO checking was |
| 19:26 | <Julian> | Well, once it is officially allocated, we can just send messages to the individual vendors and ask them to implement it. |
| 19:27 | <grumpy> | as far as the Authentication-Results header, I'm inclinded to not do anything with it. |
| 19:27 | <Julian> | _I_ am _very_ inclined to make use of it, though. |
| 19:27 | <MarkK> | with MS software, you can wait a blue stread until they support a new RR; but hey, that's their problem :) |
| 19:27 | <Julian> | MarkK: Yes. |
| 19:28 | <MarkK> | s/stread/streak/ even |
| 19:28 | <grumpy> | Julian: go on... |
| 19:28 | <Julian> | I don't think the Authentication-Results header is beyond rescuem, and I really think there should not be several distinct records with distinct formats. |
| 19:28 | <Julian> | s/rescuem/rescue/ |
| 19:28 | <Julian> | I think we should at least _try_ to get its designers to make it suitable for SPF use. |
| 19:29 | <grumpy> | Have you contacted the author at all? |
| 19:29 | <Julian> | If they don't want to cooperate, well, ok. But I don't think they're going to be that stubborn. |
| 19:29 | <Julian> | Not yet, I first wanted to hear your opinions. |
| 19:29 | <grumpy> | Well, my opinion is that I have higher priority things to worry about |
| 19:30 | <grumpy> | and it doesn't look like that draft is going anywhere |
| 19:30 | <MarkK> | grumpy: agreed |
| 19:30 | <Julian> | Well, we were sitting on spf-draft-200406 for a _long_ time, too. |
| 19:31 | <Julian> | Ok, I'm going to contact their authors and request their cooperation. |
| 19:31 | <grumpy> | Now, if someone wants to take on the job of doing the leg work to see if you can get the author of the auth-result header to become active and for the DK/IIM/SES folks to join in, then I think we would have something. |
| 19:31 | <Julian> | But for that, please tell me what problems you have with the current Auth-Results spec. |
| 19:31 | <grumpy> | Julian: spf-draft-200406 sat largely because of MARID. |
| 19:32 | <Julian> | grumpy: I know. I mean, we don't know what problems _they_ are having currently. |
| 19:32 | <grumpy> | Hmmm... Ok, I'll have to dig up a complete list |
| 19:32 | <Julian> | Ok. |
| 19:32 | <grumpy> | I'll send you a list Real Soon Now. |
| 19:32 | <Julian> | b. The role of HELO checking. |
| 19:32 | * | grumpy sighs |
| 19:33 | <grumpy> | (is that for me, or Julian?) |
| 19:33 | <Julian> | Wait. |
| 19:33 | <Julian> | As I wrote to spf-discuss a week or so ago, I'd like HELO checking to be given a clearer vision in the SPF spec. |
| 19:33 | <csm> | a quick comment about helo checking |
| 19:34 | * | csm wonders why we are worried about it so much |
| 19:34 | * | Julian is finished for now. :) |
| 19:35 | <grumpy> | Ok.... Uh, I forget, what exactly did you think needed to be clearer about it? |
| 19:35 | <MarkK> | julian: even more clear than now in wayne's draft? |
| 19:35 | <Julian> | MarkK: Yes, I think so. |
| 19:35 | <Julian> | Just a moment, I'll try to find my posting. |
| 19:36 | <grumpy> | While Julian is finding the post, I'll give a general status report |
| 19:36 | <grumpy> | The draft has been sent off to the "dea" directorate of the IETF |
| 19:36 | <grumpy> | as per standard policy (according to my dad), the directorate mailing list is private. |
| 19:37 | <grumpy> | as is the list of people on it. |
| 19:37 | <grumpy> | they will contact Meng and me when they have questions/comments |
| 19:37 | <grumpy> | I have also, according to standard procedure, informed all relevant IETF working groups about the draft and solicited comments. |
| 19:37 | <grumpy> | the 821/822 groups haven't said boo, but the DNS folks have |
| 19:38 | <grumpy> | lots of comments about the zone cut stuff and how they don't like it. |
| 19:38 | <MarkK> | yes, I saw that |
| 19:38 | <grumpy> | there is some on-going discussions and proposals, in particular by William, about how this may be solved with a new wildcard type in DNS |
| 19:39 | <grumpy> | the DNS folks *haven't* complained loudly about other things, such as the use of TXT RRs and putting the TXT RR in the domain, rather than something like _spf.example.com |
| 19:39 | <MarkK> | I am not too fond of wildcard DNS |
| 19:41 | <Julian> | grumpy: This is not conflicting with 2821! |
| 19:41 | <Julian> | Please read my proposal thoroughly. :-) |
| 19:41 | <MarkK> | julian: I do not get it; it seems to be conflicting with 2821, doesn't it? |
| 19:41 | <Julian> | What would the conflict be? |
| 19:42 | <Julian> | For example, take mehnle.net. It's a FQDN. 2821 satisfied, qed. |
| 19:43 | <MarkK> | Is not the purpose of HELO to identify the machine who is sending? I know checks on that are lax, generally, but why 'break' things on purpose? |
| 19:43 | <Julian> | I'm not saying that an FQDN should not be used in HELO. |
| 19:43 | <Julian> | mehnle.net _does_ identify the machine properly. |
| 19:45 | <grumpy> | ok, and if I recall, you just want some wording added to suggest this case? |
| 19:45 | <MarkK> | as long as it is a FQDN, I suppose you're in the clear; but do I get you right that when your sending host is 'mx.mehnle.net', that you want to use HELO mehnle.net? |
| 19:45 | <Julian> | I just want the SPF spec to suggest that, for small sites where "domain" already is a FQDN (or can be made so easily(!!!)), the MTA might want to say "HELO domain" instead of "HELO mx.domain" if domain == mx.domain. |
| 19:45 | <Julian> | grumpy: Yes. |
| 19:45 | <Julian> | That way, an additional SPF record does not need to be published. |
| 19:46 | <Julian> | MarkK: mx.mehnle.net == mail.mehnle.net == mehnle.net |
| 19:46 | <Julian> | MarkK: Yes. |
| 19:46 | <MarkK> | Ok, then it makes sense :) |
| 19:46 | <grumpy> | Well, I'll look for a place to add a comment or something, but I don't see it as a big deal |
| 19:47 | <Julian> | grumpy: Me neither. I originally just wanted to discuss "2." from that posting of mine. :-) |
| 19:47 | <grumpy> | maybe something along the lines of, when talking about publishing for the HELO domain, a comment that says "if different from the email domain" |
| 19:47 | <grumpy> | ok... sorry for the tangent ;-) |
| 19:48 | <grumpy> | right now, the draft says that MAIL FROM is manditory, but HELO is optional. |
| 19:48 | <Julian> | Re 2. HELO checking and MAIL FROM checking --- or: --- The role of HELO checking |
| 19:48 | <grumpy> | you *can* always check it if you want to |
| 19:48 | <Julian> | My point is that RFC 2821 already requires HELO to be a valid FQDN. |
| 19:49 | <Julian> | My second point is that people who insist on ignoring RFC 2821 (out of inertia or whatever) can very well also ignore the relevant part of the SPF spec. |
| 19:49 | <MarkK> | grumpy: and I always do, already; it just does not need to be a part of SPF per se (or it it does, in the cheesplate model, it would integrate nicely with reputation services checks, etc). |
| 19:49 | <Julian> | I know that a lot of receivers do not enforce HELO to be a valid FQDN. Those receivers can ignore the relevant part of the SPF spec, too. |
| 19:50 | <MarkK> | julian: yes, I always check for FQDN, and reject mail on it, too |
| 19:50 | <Julian> | Conclusion: if RFC 2821 requires HELO to be a valid domain, and the SPF spec builds upon that assumption, we can at least clearly recommend HELO checking. |
| 19:50 | <grumpy> | 2821 says that the HELO domain must be a FQDN, not that SMTP servers have to validate that. |
| 19:51 | <MarkK> | grumpy: true, but I do it nonetheless ;) |
| 19:51 | <Julian> | grumpy: No, of course not. But if RFC 2821 requires HELO to be a valid FQDN, I can check it based on RFC 2821. :-) |
| 19:51 | <grumpy> | Julian: so you are saying I should s/MAY/SHOULD/ in the part where the draft talks about HELO checking? |
| 19:51 | <Julian> | Let me take a quick look into the spec. |
| 19:52 | <Julian> | 2.1 The HELO Identity |
| 19:52 | <Julian> | [...] |
| 19:52 | <Julian> | SPF clients MAY check the "HELO" identity by calling the check_host() |
| 19:52 | <Julian> | function (Section 4) with the "HELO" identity as the <sender>. [...] |
| 19:52 | <Julian> | s/MAY/SHOULD/ |
| 19:52 | <grumpy> | ok |
| 19:53 | <grumpy> | I can live with that |
| 19:53 | <Julian> | Or something like that. |
| 19:53 | <Julian> | I'd have to examine the spec a bit closer. |
| 19:53 | <grumpy> | I can't see doing a MUST 'cause spf-draft-200406 didn't say must. (and ditto for all prev specs) |
| 19:53 | <Julian> | I can submit a precise diff to you then. |
| 19:53 | <grumpy> | ok |
| 19:54 | <grumpy> | I know that James once said that it should be a MUST, but I disagree |
| 19:54 | <Julian> | Well, if it was just me, I'd say MUST, but I can see that many people would be offended by that. ;-) |
| 19:54 | <grumpy> | personally, I would be very tempted to say MUST also, but... |
| 19:55 | <Julian> | "SHOULD" allows the inert to ignore the recommendation. |
| 19:55 | <grumpy> | In reality, MAY and SHOULD both mean that the implementor and user is free to do whatever the heck they want |
| 19:55 | <Julian> | But "MAY" gives them a clear conscience. ;-) |
| 19:55 | * | csm just wonders why it needs to be in the SPF spec |
| 19:55 | <MarkK> | in the case of MAIL FROM: <>, a MUST is not unreasonable |
| 19:56 | * | csm does helo checking already... incependent of SPF |
| 19:56 | <Julian> | grumpy: Ok, I'll work on a diff. |
| 19:56 | <grumpy> | csm? why HELO checking needs to be in the spec? |
| 19:56 | <grumpy> | s/csm?/csm:/ |
| 19:57 | <Julian> | "MAIL FROM: <>" should have been "MAIL FROM: <postmaster@domain>" or "MAIL FROM: <@domain>" from the beginning! |
| 19:57 | <MarkK> | in the case of MAIL FROM: <>, a MUST is not only not unreasonable, but, without it, creates a loophole |
| 19:57 | <Julian> | MarkK: Exactly. |
| 19:57 | <grumpy> | agreed |
| 19:57 | <grumpy> | ok, what else? |
| 19:57 | <Julian> | csm: Next item. |
| 19:58 | <csm> | Countering FUD and misinformation by Yahoo. |
| 19:58 | <grumpy> | that PDF is from Oct.... I presume for the FTC conf |
| 19:58 | <Julian> | Have you read the slides? |
| 19:58 | <Julian> | It's hilarious. |
| 19:58 | <grumpy> | yeah, pretty tacky, if you ask me |
| 19:58 | <grumpy> | their example of SPF spoofing is completely bogus, as far as I can tell |
| 19:59 | <Julian> | "CipherTrust: Spam currently 34% more |
| 19:59 | <Julian> | likely to be SPF verified than legit mail" |
| 19:59 | <grumpy> | But, hey, if you are out in front, everyone will be taking pot shots at you. |
| 19:59 | <MarkK> | grrr; FUD indeed |
| 19:59 | <Julian> | That can only mean that we have to build a domain-based blacklist, so all the SPF-compliant spammers can be caught. |
| 19:59 | <grumpy> | Julian: yeah, and the correct response is "great! we can easily blacklist them now!" |
| 20:00 | <Julian> | grumpy: Heh. :-)) |
| 20:00 | <grumpy> | :-) |
| 20:00 | <grumpy> | Ok, my opinion: If we see that Yahoo is continuing to spread that kind of fud, we should contact them. |
| 20:00 | <grumpy> | otherwise, we should ignore them. |
| 20:00 | <grumpy> | and work on advancing SPF |
| 20:00 | <MarkK> | yes, idiots; that is the WHOLE point of SPF; you forced spammers to use their own domains, so the world can reintroduce domain-named blacklisting! (which is a whole lot better than IP based, really) |
| 20:01 | <Julian> | grumpy: Hmm, contacting them might actually be a good idea. |
| 20:01 | <Julian> | But I doubt they're going to listen to us. |
| 20:01 | <grumpy> | Miles Libby posts to the MASS list fairly often |
| 20:01 | <grumpy> | he hasn't been spreading as much FUD there as David Woodhouse or John Levine. |
| 20:02 | <MarkK> | I tyhink they were just being disengenious, really; they're not that stupid; |
| 20:02 | <grumpy> | MarkK: I think there is also a good chance that they don't understand SPF |
| 20:02 | <grumpy> | and they want to push DK |
| 20:02 | <MarkK> | grumpy: especially the latter, I think |
| 20:03 | <MarkK> | SPF is not higher math :) |
| 20:03 | * | grumpy likes higher math... ;-) |
| 20:03 | <grumpy> | Ok, so, what are we going to do about the fud? |
| 20:04 | <grumpy> | as I said, I think we should ignore that particular PDF... |
| 20:04 | <grumpy> | it is too old |
| 20:04 | <Julian> | Nonetheless... |
| 20:04 | <Julian> | Motion: A counterstatement to frequent FUD regarding SPF should be created. The community shall make suggestions for the document, and someone from the council shall compile it. |
| 20:04 | <Julian> | It should later go onto the SPF project website. |
| 20:04 | <grumpy> | isn't there already something like that on spf.pobox.com? |
| 20:05 | <Julian> | It's outdated and doesn't handle some newer FUD. |
| 20:05 | <grumpy> | true... |
| 20:05 | <MarkK> | that is why I was (and am) so adamant about pushing for a "Deployement recommendations Draft", so we can explain to the world where we see the problems in today's market, and how we plan to solve them. |
| 20:05 | <grumpy> | speaking of which, weren't you going to look into doing a new SPF website? |
| 20:06 | <grumpy> | ping? |
| 20:06 | <Julian> | MarkK: Well, an "anti-FUD" paper could concentrate on countering FUD. A "deployment recommendations" paper couldn't. |
| 20:06 | <Julian> | grumpy: Yes, I am. |
| 20:07 | <Julian> | grumpy: I do have a plan, I just need to push it to spf-discuss now. |
| 20:07 | <grumpy> | ok |
| 20:07 | <Julian> | grumpy: I am going to do that during the next week, I promise. |
| 20:07 | <MarkK> | Julian: it depends on how deep we want to explain current practices and our objections against it |
| 20:08 | <MarkK> | julian: but I am all for a single 'Anti-FUD' paper too |
| 20:08 | <Julian> | MarkK: Such an anti-FUD document wouldn't necessarily list objections to current practices, just explain the wrongness of various FUD. |
| 20:09 | <Julian> | That doc should be relatively short, so we can refer to it easily whenever FUD comes up during discussions. |
| 20:09 | <csm> | I think that that doc needs to be fairly detailed |
| 20:09 | <csm> | comprehensive |
| 20:09 | <Julian> | It can refer to other docs, such as a "deployment recommendations" paper. |
| 20:10 | <csm> | and address the FUD point by point following a full, accurate statement of what SPf is and what i's supposed to do |
| 20:10 | <grumpy> | for what it is worth, I'm not sure we have to worry *that* much about fud. there are a lot of folks that already understand SPF and can recgonize BS when they see it. |
| 20:10 | <grumpy> | For example, Dean Anderson posted a bunch of FUD to the BBLISA list, and someone else did a fine job of countering it. |
| 20:11 | <Julian> | I'm not saying we have to worry a lot about FUD, but countering it with eloquence would be good marketing-wise. |
| 20:11 | <grumpy> | widespread understanding of SPF would be better. |
| 20:11 | <Julian> | What's the difference? |
| 20:11 | <grumpy> | one is proactive, the other is reactive |
| 20:12 | <Julian> | Why can't we do both? |
| 20:12 | <grumpy> | we can, but I think we should do more proactive education |
| 20:12 | <Julian> | Agreed. |
| 20:12 | <MarkK> | In my understanding, ppl tend to gobble up what large companies say, without thinking too much for themselves; a voice from our community, countering a few things, would probably be helpful |
| 20:12 | <grumpy> | if people are using SPF and deploying it, then they will ignore the FUD |
| 20:12 | <Julian> | MarkK: Yes. |
| 20:13 | <Julian> | grumpy: But a lot of people won't bother in the first place because they have heard that SPF eats their hamster and molests children. |
| 20:13 | <grumpy> | I thought it molests their hamsters and eats their children, but... |
| 20:13 | <Julian> | You know what I mean... ;-) |
| 20:14 | <grumpy> | anyway, I've said my two cents on the subject |
| 20:14 | <Julian> | "SPF rejects legitimate mail, don't use it." |
| 20:14 | <grumpy> | ok, anything else on item 6? |
| 20:14 | <Julian> | Motion: A counterstatement to frequent FUD regarding SPF should be created. The community shall make suggestions for the document, and someone from the council shall compile it. It should later go onto the SPF project website. |
| 20:15 | <MarkK> | seconded |
| 20:15 | <Julian> | (with council approval) |
| 20:15 | <Julian> | csm? |
| 20:16 | <grumpy> | csm? |
| 20:16 | * | grumpy wonders if we just lost our quorum... |
| 20:16 | <csm> | votes |
| 20:16 | <MarkK> | 2114: yes |
| 20:16 | <Julian> | 2014u: yes |
| 20:16 | <grumpy> | 2114: yes |
| 20:16 | <csm> | so ordered |
| 20:16 | <MarkK> | err, 2014: yes |
| 20:16 | <Julian> | Great, thank you. |
| 20:17 | <csm> | The SPF reference implementation and the test suite should be |
| 20:17 | <csm> | updated. Who can do it? |
| 20:17 | <Julian> | SPF reference implementation == Mail::SPF::Query |
| 20:17 | <grumpy> | Well, so says spf.pobox.com.... |
| 20:17 | <Julian> | Do you agree that it should be a priority? |
| 20:18 | <grumpy> | I don't think it makes a particularly good reference implementation. I'm not sure that any of the implementations do. |
| 20:18 | <MarkK> | I do not feel comfortable enough in IPv6 to do it |
| 20:18 | <grumpy> | do we need a reference implementation? |
| 20:18 | <Julian> | I guess I could do it, but I have too many other things on my SPF TODO list. |
| 20:18 | <MarkK> | yes, we need a reference implementation |
| 20:18 | <grumpy> | isn't it time to move to a spec-based reference? |
| 20:19 | <grumpy> | MarkK: why? What's the reference implementation for SMTP? |
| 20:19 | <Julian> | grumpy: Maybe, but a stable and mostly bug-free reference implementation would indeed very good to have. |
| 20:19 | <MarkK> | I really think ppl need a piece of software to model their implementation-behavior agyer |
| 20:19 | <Julian> | Existing code is one of SPF's assets. |
| 20:19 | <MarkK> | after, even |
| 20:19 | <grumpy> | So, if the "reference" implementation and the spec disagree, which is right? |
| 20:20 | <Julian> | grumpy: The spec. |
| 20:20 | <MarkK> | grumpy: because new coders want to test their software input/output against reference code; |
| 20:20 | <grumpy> | I think they should test it against a test suite |
| 20:20 | <grumpy> | if anything. |
| 20:20 | <Julian> | grumpy: But just like we have to take care that the spec doesn't contradict itself, we can take care that the reference implementation doesn't contradict the spec. |
| 20:21 | <Julian> | grumpy: A test suite would be good, yes. We could test the ref. impl. against it. |
| 20:21 | <grumpy> | shouldn't all implementations conform to the spec? |
| 20:21 | <Julian> | grumpy: Sure. |
| 20:21 | <grumpy> | why do we need a single reference implementation? |
| 20:21 | <MarkK> | grumpy: sure; but when I write code, I always like to find a reference implementation too, just to make just my code behaves as expected; that is not always clear from a spect alone |
| 20:21 | <grumpy> | and if the reference implementation has features that aren't in the spec, does that mean everyone else needs to have that feature? |
| 20:22 | <Julian> | grumpy: We can have many if we want. But there should at least be an official one that can be studied by authors of other implementations. |
| 20:22 | <Julian> | grumpy: The ref. impl. should not have features that are not in the spec. |
| 20:22 | <grumpy> | Well, a *good* reference implementation has few, if any, additional features and everything is written to be clear and correct, rather than fast |
| 20:22 | <MarkK> | julian: agreed; it is also politically sound, as it lowers the threshold for new coders (and thus promotes SPF adoption) |
| 20:22 | <grumpy> | none of the SPF implementations come close to that. |
| 20:23 | <Julian> | At least, additional features should be modular and one should be able to disable them easily. |
| 20:23 | <grumpy> | I think a good test suite is more important |
| 20:23 | <Julian> | grumpy: Ok, I won't object. |
| 20:24 | <Julian> | But a good ref. impl. is not unimportant. |
| 20:24 | <MarkK> | I do not think it needs to be either/or; a good test-suite is very important too |
| 20:24 | <Julian> | Alright, I can do a new reference implementation, but it will take a while (~2 months or so). |
| 20:25 | <grumpy> | Well, I think the priorities should be: 1) a spec 2) a test suite 3) practical implementations that pass the spec and test suite 4) ref impl |
| 20:25 | <MarkK> | julian: that would be more than adequate time; it has no hurry, but should, at some point, really be done |
| 20:25 | <Julian> | We could solicit someone from the community, too. |
| 20:26 | <MarkK> | grumpy: agreed on that priority |
| 20:26 | <Julian> | grumpy: Swap 3 and 4 and I can agree. :-) |
| 20:26 | <Julian> | If we have 4, we probably don't need 3 anymore. But having 3 makes getting 4 easier. |
| 20:26 | <grumpy> | Anyway, I *don't* think that M:S:Q makes a good reference implementation |
| 20:26 | <MarkK> | both 3 and 4 can be 3, really, ihmo (as having more or less the same importance to me) |
| 20:27 | <Julian> | Ok, what about 2? |
| 20:27 | <Julian> | Who can make the test suite? |
| 20:27 | <grumpy> | Well, I did the last one |
| 20:27 | <csm> | if anyone fixes anything I hope that we can get the perl stuff for postfix fixed and get it all tohgether in one place like I have done at http://moongroup.com/downloads/ |
| 20:27 | <Julian> | Is it up to date? |
| 20:27 | <grumpy> | I can continue to work on it, but I think that needs to wait until we have a final spec |
| 20:27 | <grumpy> | it is pretty close to 200406 |
| 20:28 | <grumpy> | it tests things like unknown mechanisms, which have changed since 200406 though |
| 20:29 | <grumpy> | The real problem is I was the only one that really ended up using it. |
| 20:29 | <grumpy> | So, what's the point? |
| 20:29 | <Julian> | It's a chicken/egg problem. |
| 20:29 | <grumpy> | (Ok, the point for me was to test my implementation, but...) |
| 20:29 | <Julian> | If you think a test suite is important, then we should do one. |
| 20:30 | <grumpy> | Ok, when I get done with the spec and update my implementation to conform to the lastest spec, I'll update the test suite. |
| 20:30 | <Julian> | Ok, motion 1: Wayne shall take care of making a good test suite, calling in the community for help if necessary. |
| 20:30 | <Julian> | Motion 2: Julian shall take care of making a good reference implementation, calling in the community for help if necessary. |
| 20:31 | <Julian> | (No time frames.) |
| 20:31 | <grumpy> | seconded |
| 20:31 | <csm> | votes |
| 20:31 | <Julian> | 2031u: yes |
| 20:31 | <grumpy> | 2031: yes |
| 20:31 | <grumpy> | MarkK? |
| 20:31 | <grumpy> | Hmmmm... |
| 20:31 | <MarkK> | 2031u: yes |
| 20:32 | <csm> | so ordered |
| 20:32 | <csm> | one addendum |
| 20:32 | <Julian> | Now, that's some real progress! |
| 20:32 | <csm> | this needs to be top to bottom |
| 20:32 | <csm> | all required modules in one place |
| 20:32 | <MarkK> | I see 2030u too |
| 20:32 | <csm> | including distribution packaging as well |
| 20:33 | <Julian> | csm: Can you please rephrase that? |
| 20:33 | <csm> | if we're going to get into software implementations |
| 20:33 | <grumpy> | csm: does it actually need to be put into MTAs, or just something like the spfquery command? |
| 20:33 | <csm> | we go all the way |
| 20:34 | <grumpy> | define "all the way"? |
| 20:34 | <csm> | all required modules in one place, including distribution packaging as well |
| 20:35 | <grumpy> | for both unix and windows and vms? |
| 20:35 | <csm> | http://moongroup.com/downloads/ for example |
| 20:35 | <grumpy> | is the MTA interface a "required module"? |
| 20:35 | <csm> | I can't speak for windows... but all unixes |
| 20:35 | <Julian> | csm: That's where the new SPF website should come in. |
| 20:35 | <Julian> | Or what are you trying to say? |
| 20:36 | <csm> | grumpy: if you mean things like the perl policy module yes |
| 20:36 | <grumpy> | hmmm... |
| 20:36 | <csm> | and also... |
| 20:36 | <MarkK> | we should get them on CPAN too, of course |
| 20:36 | <csm> | since the existing postfix patch breaks TLS we should not recommend it IMHO |
| 20:36 | <grumpy> | that isn't sounding like a reference implementation, that is sounding like an official SPF implementation. |
| 20:38 | * | Julian is confused. |
| 20:38 | * | grumpy is confused also |
| 20:39 | * | MarkK is confused now too |
| 20:39 | <Julian> | Now that we have a clear majority, can we vote on that? ;-) |
| 20:39 | <grumpy> | heh |
| 20:39 | <grumpy> | motion: we are all confused |
| 20:40 | <grumpy> | apparently, csm isn't confused, but he may be lost |
| 20:41 | <Julian> | csm: Can you please make a complete sentence saying whatever you want it to say? |
| 20:41 | <Julian> | I understood the "we should not recommend it IMHO" thing, though. |
| 20:41 | <csm> | is this reference implementation to be software or documentation? |
| 20:42 | <Julian> | Both. |
| 20:42 | <csm> | if it's actual software then we do it all in one place... a one stop shop... |
| 20:42 | <Julian> | I think. |
| 20:42 | <grumpy> | uh, more of documentation that practical software |
| 20:42 | <csm> | come here and get what you need to make it happen |
| 20:42 | <Julian> | Sure, we do need that, too. |
| 20:42 | <grumpy> | that sounds like an official implementation, rather than a reference implementation |
| 20:43 | <Julian> | The reference implementation is supposed to facilitate the writing of real software. |
| 20:43 | <grumpy> | yeah |
| 20:43 | <grumpy> | by *not* having lots of extra bells and whistles |
| 20:43 | <Julian> | ...to let implementors learn. |
| 20:43 | <Julian> | Yes. |
| 20:43 | <grumpy> | by being easy to read, rather than fast |
| 20:44 | <grumpy> | to be easy to test against, rather than use on a production system. |
| 20:44 | <grumpy> | not that it can't be fast and useful, but those are secondary goals of a reference implementation |
| 20:44 | <Julian> | Exactly. |
| 20:44 | <MarkK> | grumpy: the reference implemtation should have not bells and whistles |
| 20:44 | <grumpy> | Julian: ok, sounds like *we* are on the same wavelength. |
| 20:45 | <grumpy> | MarkK: well, that depends... For example, an extra feature to do detailed debugging and tracing would be good |
| 20:46 | <grumpy> | something that intefaces with 10 different databases to do per-user whitelisting would be bad |
| 20:46 | <grumpy> | neither are in the spec |
| 20:46 | <MarkK> | lol, yes, it would be |
| 20:46 | <Julian> | *gg* |
| 20:47 | <grumpy> | csm: thoughts? |
| 20:47 | <csm> | whatever |
| 20:47 | <grumpy> | hmmm... ok |
| 20:47 | <MarkK> | 'ok' |
| 20:47 | <Julian> | Right. |
| 20:47 | <csm> | alol i want is a simple ackknowledgement that is we do actual software... we do it right |
| 20:48 | <grumpy> | ok |
| 20:48 | <grumpy> | next item? |
| 20:48 | <Julian> | csm: You mean that the reference implementation should be "actual software"? Or that we should make "actual software" in addition to the ref. impl.? |
| 20:48 | <Julian> | Or that we should _only_ do "actual software"? |
| 20:49 | <MarkK> | I do not think a reference implementation means 'lets write and bundle all software for all MTA |
| 20:50 | <Julian> | We don't have the necessary resources to do that. |
| 20:50 | <grumpy> | for all OSes, with all features that people might want |
| 20:50 | <Julian> | Perhaps if the HSARPA proposal is accepted. |
| 20:50 | <grumpy> | yeah |
| 20:50 | <csm> | god damn guys... |
| 20:50 | <csm> | sheesh |
| 20:50 | <grumpy> | to be quite honest, I think the closest to a reference implementation is the python one |
| 20:50 | <MarkK> | I do not think a reference implementation means 'lets write and bundle all software for all MTA's on the SPF site'; though that would be nice; but a reference implementation should just be that: a working piece of code to reference implementations to |
| 20:50 | <csm> | do I need to invent a new language here? |
| 20:50 | <grumpy> | no, you just need to speak english |
| 20:51 | <csm> | all i want is a simple acknowledgement that if we do actual software... we do it right and package it up all together so it's a "one stop shop" |
| 20:51 | <Julian> | Hmm, ok, if we can do that. |
| 20:51 | <Julian> | I agree that we shouldn't be handing out "tool boxes". |
| 20:51 | <Julian> | But usable packages instead. |
| 20:51 | <csm> | yes |
| 20:52 | <Julian> | But who here has suggested anything different? |
| 20:52 | <csm> | if you go here: http://www.moongroup.com/downloads/postfix+spf/ you will see what I mean |
| 20:52 | <Julian> | I see. |
| 20:53 | * | grumpy doesn't see any .dpkg |
| 20:53 | <grumpy> | ;-) |
| 20:53 | <Julian> | It's .deb. ;-) |
| 20:53 | <grumpy> | oh |
| 20:53 | <grumpy> | yeah |
| 20:53 | <csm> | I don;t do debian |
| 20:53 | <Julian> | Also, where's .msi? |
| 20:53 | * | Julian ducks. |
| 20:53 | <csm> | what I am saying is that we have to put it all together |
| 20:54 | <grumpy> | for redhat. |
| 20:54 | <csm> | mine is not a one stop shop unless you run rhel3 |
| 20:54 | <grumpy> | ok |
| 20:54 | <Julian> | Ok. |
| 20:54 | <csm> | but I can do the RH packaging |
| 20:54 | <csm> | and will |
| 20:54 | <csm> | but we need the sources to be fixed |
| 20:54 | <csm> | they are old now |
| 20:54 | <Julian> | More important would be that we get SPF support into the official sources and distros. |
| 20:54 | <grumpy> | yes |
| 20:54 | <grumpy> | anyway |
| 20:54 | <Julian> | s/^M/Even m/ |
| 20:55 | <csm> | the first step to getting into RH is Fedora Extras... |
| 20:55 | <csm> | once we're updated we can do that |
| 20:56 | <Julian> | Ok. Can we proceed now? |
| 20:56 | <MarkK> | yes, lets |
| 20:56 | <Julian> | Or do you want to make a motion? |
| 20:56 | * | grumpy wants to go back to seeing his kids |
| 20:56 | <csm> | not me... unless somebody wants to add to this |
| 20:57 | <Julian> | I think it's uncontroversial. |
| 20:57 | <grumpy> | Uh, so we are on to item 8, new business? |
| 20:57 | <csm> | any? |
| 20:57 | <grumpy> | not from me |
| 20:57 | <Julian> | Uhm. |
| 20:58 | <Julian> | I'd like to note that I plan on doing a test vote using the CIVS. |
| 20:58 | <Julian> | To, sort of, evaluate it. |
| 20:58 | <Julian> | Any comments? |
| 20:58 | <grumpy> | CIVS is what? |
| 20:59 | <grumpy> | is it voting software, or voting methodology? |
| 20:59 | <Julian> | http://www5.cs.cornell.edu/~andru/civs/ |
| 20:59 | <Julian> | Condorcet Internet Voting Service. It's a reliable voting service. |
| 20:59 | <grumpy> | ok |
| 21:00 | <Julian> | Nothing else from me. |
| 21:00 | <grumpy> | MarkK? |
| 21:00 | <grumpy> | csm? |
| 21:00 | <Julian> | Oh, one addendum. |
| 21:00 | <grumpy> | new business? |
| 21:01 | <MarkK> | nothing new here, so far |
| 21:01 | <Julian> | I have been thinking that we might want to use John Pinkerton's approval voting system in parallel to the CIVS, to see if it makes a difference. |
| 21:01 | <MarkK> | I think I'd like to hear from Meng, as he may have a lot of news to tell us |
| 21:01 | <Julian> | MarkK: Agreed. |
| 21:02 | <grumpy> | MarkK: agreed |
| 21:02 | <csm> | well I may have confused him with my stupid date |
| 21:02 | <csm> | I will try to be around tomorrow at 1900utc to see if he shows up |
| 21:02 | <Julian> | csm: Include the weekday from now on. |
| 21:03 | <grumpy> | ok, motion to ajourn? |
| 21:03 | <Julian> | 2103u: seconded. |
| 21:03 | <MarkK> | seconded |
| 21:04 | <csm> | votes? |
| 21:04 | <Julian> | 2103u: yes |
| 21:04 | <grumpy> | 2103u yes |
| 21:04 | <MarkK> | 2103u: yes |
| 21:04 | <csm> | so ordered |
| 21:04 | <Julian> | Thank you! |
| 21:04 | <grumpy> | 2 minutes until transcripts get posted |
| 21:04 | <grumpy> | thanks much guys! |
| 21:04 | <MarkK> | thanks all |
| 21:05 | <csm> | The council is a "d" journed |
| 21:05 | <MarkK> | whatever :) |
| 21:06 | <MarkK> | goodnight! |