This is the recent traffic on the #SPF-council IRC channel on
irc.pobox.com. Anyone may join the channel, but only council
members can talk.
| 20:35 | <MarkK> | *goes to read* |
| 20:35 | <Julian> | Yeah, DougO blames SPF for a lot of issues that are actually issues inherent to DNS. |
| 20:35 | <SDGathman> | It is not an SPF issue. Dougs attack works much better just using MX records without SPF. Without SPF, you don't get the 10 RR process limit. |
| 20:36 | <MarkK> | lol |
| 20:36 | <MarkK> | that's true |
| 20:36 | <MarkK> | Well, I don't think we ever claimed SPF was going to make DNS unexploitable |
| 20:37 | <Julian> | DougO keeps whining about SPF enabling additional attacks _on_top_ of the usual DNS attack vectors. |
| 20:37 | <MarkK> | and like you said, Stuart, at least SPF has *some* sanity checks (and forced limits) |
| 20:37 | <Julian> | Well, OK, I propose that: (1) we start the meeting now, (2) begin with item 2, MarkK has returned, and then proceed with (3b) a report from the BITS meeting. |
| 20:38 | <Julian> | Any objections? |
| 20:39 | <ScottK> | While you are waiting, I might suggest that anyone who hasn't read the report on the BITS meeting that I sent to spf-private. |
| 20:39 | <MarkK> | btw, I saw DougO is as relentless on the asgr list too |
| 20:39 | <Julian> | (Perhaps William is going to join us later.) |
| 20:39 | <Julian> | I read Scott's BITS report about a week ago already. |
| 20:42 | <Julian> | hi frank |
| 20:43 | <Julian> | So, I see no objections to beginning the meeting now with item 2. |
| 20:43 | <Julian> | "2. MarkK has returned" |
| 20:43 | <Julian> | Welcome back, MarkK! |
| 20:44 | <MarkK> | It's good to be back, indeed! |
| 20:44 | <Julian> | Anything you'd like to say? (I'm not expecting an excuse or anything. Just if you wish to say something...) |
| 20:45 | <MarkK> | I think I pretty much said everything in my email. But I really *would* like to apologize for my extended absence |
| 20:45 | <Julian> | OK. |
| 20:45 | <Julian> | It would have been good if you had let us know what was up. We worried about you. |
| 20:45 | <MarkK> | Yes, it would have been |
| 20:46 | <Julian> | Anyway, shit happens, so let's continue. |
| 20:46 | <Julian> | "1.b. Very brief reports from the BITS 'E-Mail Security' meeting (2006-11-09)" |
| 20:47 | <Julian> | Scott had represented the SPF project in person at the recent BITS meeting, and SDGathman participated over the phone at least part of the event. |
| 20:48 | <Julian> | Scott sent a very nice report to spf-private. We decided to keep it private because the BITS people asked him to keep things confidential for now. |
| 20:48 | <Julian> | One reason being that the financial regulators in the US tend to make anything a hard requirement right away that the institutions come up with in the public. |
| 20:49 | <ScottK> | Not that they are trying to hide anything, they just want to make a group decision on what they are going to do before they disclose it. |
| 20:49 | <Julian> | OK, I assume most of you have read the report. ScottK, can you perhaps summarize your report to spf-discuss in a way that doesn't disclose all the sensitive stuff? |
| 20:50 | <ScottK> | Yes. I'll see what I can figure out. |
| 20:50 | <Julian> | Or do you think that there wouldn't be much left of the report then? |
| 20:50 | <ScottK> | I'll write up what I can and decide if it's worth sending. |
| 20:51 | <ScottK> | There is one operational issue I'd like to discuss here briefly. |
| 20:51 | <Julian> | I'd say, at the very least send a short note about when (or that) you expect the information to become non-classified and that we will publicize your report then? |
| 20:51 | <ScottK> | OK. |
| 20:51 | <MarkK> | please, do |
| 20:51 | <Julian> | We have been doing a lot of discussion on spf-private lately, and I don't really feel comfortable with all that privacy. |
| 20:51 | <ScottK> | Understand. |
| 20:52 | <Julian> | OK. ScottK, what was that operational issue? |
| 20:52 | <ScottK> | There was a strong consensus among the large receivers in the room that just rejecting on SPF fail was to risky. |
| 20:52 | <ScottK> | I know that we would argue that, but that's their perspective. |
| 20:53 | <ScottK> | I think that this is one of those "Perception is reality" types of issues. |
| 20:53 | <ScottK> | There was also a strong consensus from all catagories of people represented there that taking the receiver policy out of the SPF drafts was a mistake. |
| 20:53 | <Julian> | I remember us talking about it (semi-)briefly on #spf a few days ago. |
| 20:53 | <ScottK> | Yes. |
| 20:53 | <SDGathman> | False rejections on SPF fail are primary a receiver configuration problem (forwarders, etc). |
| 20:54 | <Julian> | (grumpy, ScottK, and me) |
| 20:54 | <ScottK> | Agreed, but for big receivers their response is, OK, then I won't reject. |
| 20:54 | <MarkK> | (or SID abusing our records) |
| 20:54 | <SDGathman> | They might not want to reject at first until they verify their config is correct. |
| 20:54 | <Julian> | OK, may I try to summarize the issue briefly? |
| 20:54 | <ScottK> | The SID thing doesn't seem to cause a lot of actual problmes. |
| 20:55 | <ScottK> | Go ahead. |
| 20:57 | <Julian> | If I understood ScottK correctly in our recent discussion, the issue was that they wanted some indication in records that a domain owner really, REALLY meant that mail from certain sources should be rejected. I.e., that some kind of hardfail, or a "i-really-mean-it" flag, or some other kind of "receiver policy" that says "the domain owner does expect mail to get rejected" should be introduced. |
| 20:57 | <Julian> | Have I omitted any important point? |
| 20:57 | <SDGathman> | No. |
| 20:57 | <ScottK> | I think that's it. |
| 20:57 | <Julian> | OK, please go on. |
| 20:58 | <ScottK> | The push-back I gave them was that if their fear was that people published "Fail" when they didn't really mean Fail, then any kind of "I really mean it" flag would be subject to the same abuse. |
| 20:59 | <ScottK> | Part of the reason for this was that from the receiver's perspective they want a clear and unabiguous statement from the sender that rejection was the desired result. |
| 20:59 | <ScottK> | That way if mail got rejected, they could tell complainers to RTFM. |
| 21:00 | <ScottK> | They didn't want RFC lawyers telling the that Not Authorized != Reject, so you shouldn't have rejected my mail... |
| 21:00 | <SDGathman> | Of course, SPF is pretty pointless if you don't reject any mail... |
| 21:00 | <Julian> | Would it perhaps suffice if we published some add-on RFC saying that "Fail" will be rejected by very most receivers, and that's what the original intent of "Fail" was? |
| 21:01 | <ScottK> | Yes, but I would put it slightly differently. |
| 21:01 | <ScottK> | Fail == Not Authorized (per the RFC) and we really can't change that at this point. |
| 21:02 | <MarkK> | we already have the softfail for the 'undeciders'; 'fail' seems pretty unambiguous to me |
| 21:02 | <SDGathman> | Hey, I have it, instead of rejecting, just send an auto-response to inform the sender for each SPF fail! :-) |
| 21:02 | <ScottK> | OK. |
| 21:02 | <Julian> | SDGathman: We can't mandate that to receivers. (And besides, I'm not sure you're being serious. *g*) |
| 21:03 | <ScottK> | So I suggest we sort of sidestep the issue. |
| 21:03 | <ScottK> | Fail means what Fail means and receivers are free to do with that what they will. |
| 21:03 | <Julian> | Most will reject (or just delete). |
| 21:03 | <ScottK> | I think it reasonable for senders to express a preference. |
| 21:04 | <ScottK> | Receivers are free to ignore that preference. |
| 21:04 | <ScottK> | Or make what they will of the lack of a preference being expressed. |
| 21:04 | <Julian> | Would that mean that the BITS people would not reject "Fail" messages unless the domain owner has explicitly published his preference? |
| 21:04 | <MarkK> | yes; they should understand that 'my mta, my rules' just goes; the receiving mta will ultimately decide what it will do with 'fail' |
| 21:04 | <ScottK> | Dunno. |
| 21:04 | <ScottK> | to julian |
| 21:04 | <ScottK> | ... |
| 21:05 | <ScottK> | My fear is that if there is a way to express I really mean it, the absence of expressing I really mean it will come to mean I don't really mean it. |
| 21:05 | <Julian> | Well, OK, we can't expect the BITS people (in their role as receivers) to do anything. It's the receiver's decision, after all. ;-) |
| 21:05 | <SDGathman> | Senders already express a preference with fail vs softfail. |
| 21:05 | <Julian> | ScottK: Yeah, that's my main issue with it. |
| 21:06 | <Julian> | I wouldn't want "Fail" to become "SoftFail" in effect. |
| 21:06 | <ScottK> | So that solution is to offer not just a "I really mean it flag", but to offer a "My preference is" modifier. |
| 21:06 | <ScottK> | Something like "Preferred Fail Policy". |
| 21:07 | <ScottK> | It could have options for reject, filter, or maybe something else. |
| 21:07 | <SDGathman> | As I said earlier in email to Seth Goodman, there has been not enough emphasis on receiver policy in our educational efforts. A lot of emphasis on publishing records, but receivers are where most of the foul ups happen lately. |
| 21:07 | <MarkK> | maybe they worry about legal implications of 'fail'-ing? |
| 21:07 | <ScottK> | If we do it this way, then not publishing the modifier just means you haven't expressed a preference. |
| 21:08 | <Julian> | But wouldn't that cause spammers to publish a preferred fail policy of "please waste as much CPU on it as you can, and then don't reject or delete!"? |
| 21:08 | <ScottK> | The discussion in the room was mostly about the support implications, but legal issues did get mentioned. |
| 21:08 | <MarkK> | ok |
| 21:08 | <ScottK> | Sure, but recievers are still free to ignore it. |
| 21:08 | <Julian> | Right, but then where's the point? |
| 21:09 | <ScottK> | I just want to make sure that whatever gets defined, the lack of the modifier in the record can't be taken to mean anything. |
| 21:09 | <Julian> | That's going to be hard. |
| 21:09 | <ScottK> | Yeah. That's the tricky part. |
| 21:09 | <ScottK> | And the response to your #spf objections. |
| 21:09 | <Julian> | As soon as we distinguish between very-very-dark-black and very-dark-black, those two will mean different things. |
| 21:10 | <ScottK> | I'll try and avoid that. |
| 21:10 | <Julian> | OK. As I said on #spf, I am interested to see what you can up with, even though I am not convinced that this catch-22 can be solved in any good way. |
| 21:11 | <Julian> | IMO, the BITS people need to rethink their argument. Even the idiots among domain owners will start publishing "I really, really mean it, and please do reject the stuff!", even though their records aren't tested well, etc. |
| 21:12 | <ScottK> | What I want to do is come up with something that will make large receivers more likely to reject, but not hurt existing records. |
| 21:13 | <Julian> | all: Any further comments on what (if anything) we should do about the issue? |
| 21:13 | <SDGathman> | If banks are worried that customer email will get rejected because of some screw up by their ISP, then perhaps they should use their internal list of USBank domains and reject only for those domains. |
| 21:14 | <Julian> | Or perhaps they should just use "Fail" results for scoring and not reject at all. |
| 21:14 | <ScottK> | The banks seemed willing to accept whatever collateral damage was necessary to reduce forgery. |
| 21:14 | <Julian> | Then they should reject outright on "Fail", and lean back and wait for broken records to get fixed. |
| 21:14 | <SDGathman> | They are mainly worried about forgery of bank domains, not customer domains. |
| 21:15 | <ScottK> | The recievers seemed quite willing to reject if they were sure that's what the sender wanted. |
| 21:15 | <MarkK> | why can we noy suggest they do both? let them, as per Julian's suggestion, just score 'fails' for a while, and then decide whether the collateral damage is worth doing a real fail |
| 21:15 | <Julian> | The problem is, you cannot be sure. Even idiots usually mean what they say. |
| 21:16 | <MarkK> | yes, Stuart; I reckon they're most inerested in preventing phising in their name |
| 21:16 | <SDGathman> | We should make sure our wizard and tutorial pages warn newbies in big type that a FAIL policy will likely result in failing mail getting rejected. |
| 21:16 | <ScottK> | And mostly what the receivers wanted was an explicit statement of sender policy so that they could point to it and say, "See, you told me to reject it". |
| 21:16 | <Julian> | SDGathman: Very good point. |
| 21:16 | <Julian> | The old wizard doesn't even offer "-all", just "~all" and "?all". |
| 21:17 | <SDGathman> | That was sensible - a newbie needs some experience to understand the implications. |
| 21:17 | <ScottK> | So I plan on drafting up an inference free modifier proposal. I think we can leverage the communication channels opened via BITS to get it implemented in some key locations. |
| 21:17 | <SDGathman> | But perhaps offering -all (or at least mentioning it) with a big warning would be better. |
| 21:17 | <ScottK> | This would give us another avenue to push deployment. |
| 21:17 | <Julian> | I agree with SDGathman. |
| 21:18 | <Julian> | I'll start working on the new wizard shortly (see later). |
| 21:18 | <MarkK> | In the past, I've notice we've kinda been discourageing the use of 'fail'. But maybe we should indeed focus more on explaining the risk. |
| 21:18 | <Julian> | (I never have been discouraging "fail".) |
| 21:19 | <SDGathman> | It has never been a risk for any of my domains or client domains. There is only ever one outgoing MTA. Apply SMTP AUTH for roaming users. |
| 21:19 | <MarkK> | no, you haven't. :) With "we" I meant more a general tone on spf-discus |
| 21:19 | <Julian> | OK, so let's have ScottK work something out. Then we should discuss it on spf-discuss, and if there seems to be rough consensus that it makes sense, the council can bless it. |
| 21:20 | <MarkK> | it's never been a risk for me either, and I publish 'fail' since day 1 |
| 21:20 | <ScottK> | Sounds good to me. |
| 21:21 | <Julian> | So, are there any other comments or questions on the BITS meeting or on Scott's report? |
| 21:21 | <MarkK> | No; except to thank him for his attendence. :) |
| 21:22 | <ScottK> | Stuart too, he was there on the phone and e-mailed me questions/points to make during the meeting. |
| 21:22 | <MarkK> | Then thank you too, Stuart |
| 21:22 | <Julian> | Yeah, ScottK and SDGathman, thank you for representing the project there! |
| 21:22 | <MarkK> | the BITS ppl are an important segement |
| 21:22 | <MarkK> | segment |
| 21:22 | <Julian> | Definitely. |
| 21:24 | <Julian> | OK. William hasn't shown up yet. So we'll have to skip item 1.a. |
| 21:25 | <Julian> | "1.c. Collecting other news for the upcoming spf-announce message" |
| 21:25 | <Julian> | At our last council meeting, we decided to make the website switch on or before 2006-12-01. |
| 21:26 | <Julian> | We also decided to send out a message to spf-announce at roughly the same time (on the same day if possible). |
| 21:26 | <MarkK> | sounds good |
| 21:26 | <Julian> | That will be a nice opportunity to publish some news about SPF. |
| 21:26 | <Julian> | So we need to collect interesting news items. |
| 21:26 | <Julian> | Obviously, the website switch will be one of them. |
| 21:28 | <Julian> | I just created the private page http://new.openspf.org/auth/News/Upcoming |
| 21:28 | <Julian> | If any of you have ideas, please add them there, or, if you don't have access to the page, send them to spf-private. |
| 21:30 | <Julian> | Here are some ad hoc ideas: |
| 21:30 | <Julian> | Mail::SPF will get released before 2006-12-01. |
| 21:30 | <Julian> | The test-suite seems to be mostly done, too. |
| 21:31 | <Julian> | We could announce pySPF 2.0, too. Comments on that? |
| 21:32 | <MarkK> | Mail::SPF will replace Mail::SPF::Query, right? |
| 21:32 | <Julian> | Not directly, but in purpose, yes. |
| 21:32 | <SDGathman> | Someone said the disagreed with a test in the suite. Was that you Julian? |
| 21:32 | <Julian> | MarkK: I am planning to release Mail::SPF::Query 2.000 as a drop-in replacement that's just a wrapper for Mail::SPF. |
| 21:32 | <Julian> | SDGathman: Yes, I disagree with two specific test cases of the test-suite. |
| 21:33 | <SDGathman> | I was going to check them out, but got lost in the thread. Do you have which they are? |
| 21:33 | <Julian> | I have been skipping "cidr6-0-ip4" and "cidr6-ip4". |
| 21:34 | <Julian> | The issue I have with them is this: http://archives.listbox.com/1007/200611/0006.html |
| 21:35 | <SDGathman> | Ok. I rememeber the discussion a month ago. |
| 21:35 | <SDGathman> | Whether an IP4 connection on IP6 should match IP6 mechanisms. |
| 21:35 | <Julian> | Yeah. |
| 21:36 | <Julian> | My issue is that I don't see "ip6:::/0" matching all of IPv6 EXCEPT for ::ffff:0/96. |
| 21:36 | <Julian> | I admit that this is sort of a philosophical issue. |
| 21:37 | <SDGathman> | The problem is that a policy could have different results depending on whether it came in via IP6 or IP4. But the sender makes that choice. But only if receiver implement it consistently. |
| 21:37 | <Julian> | RFC 4408 is silent about it. |
| 21:37 | <SDGathman> | For instance, a sender might want IP6 connections to be rejected because they hate IP6. Or vice versa. |
| 21:37 | <Julian> | Thus, I would NOT expect "ip6:" not to match ::ffff:n.n.n.n. |
| 21:38 | <SDGathman> | Right - if you indeed want different results depending on connection type. |
| 21:38 | <SDGathman> | And that is the philosophical aspect. |
| 21:38 | <Julian> | You can't force receivers to reject IP6 connections because _you_ hate it. If the receiver uses an IPv6 socket, you can't do anything about it. |
| 21:39 | <ScottK> | I would interpret things so senders and receivers in the IPv4 world can (with the limited exception of syntax validation) ignore the existance of IPv6. |
| 21:39 | <ScottK> | IPv6 users know they live in a complex world of IPv4/6 and have to figure out the corner cases. |
| 21:40 | <SDGathman> | A ip4 sender is safe as long as they don't use any ip6 mechs. |
| 21:40 | <Julian> | Right, you can't ignore syntax validation, because the spec requires it even if you don't speak IPv6. But then there's no point in stopping after IPv6 syntax validation, because IPv6 addressing math is an order of magnitude simpler than IPv6 syntax validation! |
| 21:41 | <SDGathman> | But an ip6 mech that matches ::FFFF:ip4 is ambiguous. If there is that much disagreement, I may have to resort to multiple acceptable results. |
| 21:41 | <Julian> | Why is it ambiguous? |
| 21:41 | <SDGathman> | Not addressed by the RFC. |
| 21:41 | <Julian> | Well, not explicitly at least. |
| 21:41 | <Julian> | ::ffff:n.n.n.n is a valid IPv6 address. |
| 21:42 | <Julian> | A special one, but one. |
| 21:42 | <SDGathman> | It depends on what "treat as an IP4 address". |
| 21:42 | <SDGathman> | means. |
| 21:44 | <Julian> | Agreed, but the spec doesn't say that "ip6:" cannot match "IPv6 addresses that are treated as an IPv4 address". |
| 21:44 | <Julian> | Anyway, we aren't getting anywhere right now, and this should be discussed on spf-devel instead. |
| 21:44 | <MarkK> | so, where is the ambiguity then? |
| 21:44 | <SDGathman> | But "treat as an IP4 address" could imply that. |
| 21:45 | <Julian> | So, can we continue this discussion on spf-devel? |
| 21:45 | <Julian> | Or perhaps spf-discuss? |
| 21:45 | <SDGathman> | ok |
| 21:45 | <Julian> | Any other ideas for news items? |
| 21:46 | <MarkK> | Stuart: isn't that just language? It's like saying: 'treat as an IPv6 addres which is treated as an IPv4 address" |
| 21:46 | <SDGathman> | At some point there has to be a decision - to pick one or the other or both or none. |
| 21:46 | <MarkK> | ok |
| 21:46 | <Julian> | Comments about announcing pySPF 2.0? |
| 21:46 | <SDGathman> | Is it packaged ok? |
| 21:47 | <Julian> | I have no idea. |
| 21:47 | <Julian> | I just read someone suggesting that it be included in the announcement. |
| 21:48 | <SDGathman> | Be nice if someone besides me tried installing the package. |
| 21:48 | <SDGathman> | Pretty simple package - one module, two scripts, and some docs. But stuff happens. |
| 21:48 | <MarkK> | I like the idea of including it in the announcment |
| 21:49 | * | Julian too. |
| 21:49 | <ScottK> | Is it up on the Python Cheeseshop? Last I looked, it still had 1.7. |
| 21:49 | <MarkK> | I'll give it a run on my newly installed python |
| 21:50 | <ScottK> | I'll put it up as the code base for my validator shortly. |
| 21:50 | <Julian> | OK, here's another idea for a news item: we could bring up the Microsoft S-ID patent and how it relates to the Open Specification Promise (i.e. MS won't sue you). |
| 21:50 | <ScottK> | The one that's up there isn't to far behind 2.0 as it is. |
| 21:51 | <SDGathman> | Just ran setup register... |
| 21:51 | <ScottK> | Julian: I'd stay away from that. |
| 21:51 | <Julian> | ScottK: Why? |
| 21:51 | <ScottK> | Not our problem to promote SID. |
| 21:51 | <Julian> | I'm not sure I'd consider that a promotion. |
| 21:51 | <ScottK> | Appearing to be to close to MS (closer than we are in fact) doesn't win friends and influence people in certain places. |
| 21:52 | <Julian> | It's more like FUD. ;-) After all, we don't really know whether the OSP makes S-ID free-software compatible. |
| 21:52 | <ScottK> | I just don't think it relates to SPF at all. |
| 21:52 | <SDGathman> | So far we "promote" SID be recommending to publish empty spf2.0 records. |
| 21:53 | <ScottK> | We have to warn people to consider PRA when publishing SPF records because of the unfortunate reuse issue, but beyone that I view it as irrelevant to SPF. |
| 21:53 | <SDGathman> | To disable record {ab,re}use. |
| 21:54 | <Julian> | SDGathman, MarkK: What do you think about mentioning the "S-ID patent and OSP" issue? |
| 21:54 | <SDGathman> | I wouldn't mention it. |
| 21:55 | <MarkK> | saying MS won't sue you, imho, I think would only instill an idea in ppl's mind that MS *might* sue you. |
| 21:55 | <MarkK> | e.g.; don't mention it |
| 21:57 | <Julian> | We wouldn't be saying that "MS won't sue you". It would be more along the lines of "There's the S-ID patent, and there's the OSP, and legal experts are still evaluating what it means". It would be more like reminding people that S-ID is still covered by a patent and that this can be a problem. |
| 21:58 | <ScottK> | I'd leave it alone. |
| 21:58 | <SDGathman> | We really shouldn't care about promoting *or* dissing SID. Live and let live - except for where they attack SPF via record reuse. |
| 21:58 | <ScottK> | Talk about SPF. |
| 21:58 | <SDGathman> | It should be fine for people to use SID - as long as they don't do the vile record reuse part. |
| 21:58 | <Julian> | OK, there seems to be rough consensus not to mention it. |
| 21:59 | <MarkK> | if it ever becomes an issue, we can sure mention it later |
| 21:59 | <Julian> | Too bad. I would have had such a nice headline for it... "MS has license to kill". ;-) |
| 22:00 | <Julian> | OK, let's move on. I see no further suggestions for news items. |
| 22:00 | <Julian> | "3. Status of the SPF domain names" |
| 22:01 | <SDGathman> | How about test suite 1.0 sans ip4mapping tests? |
| 22:01 | <SDGathman> | For news item? |
| 22:01 | <Julian> | Yeah, I already proposed the test suite as an item. |
| 22:02 | <Julian> | http://new.openspf.org/auth/News/Upcoming |
| 22:02 | <Julian> | I added those that seemed to have consensus. |
| 22:02 | <Julian> | Feel free to add more. |
| 22:03 | <Julian> | "3. Status of the SPF domain names" |
| 22:03 | <Julian> | William wanted to contact the ASF again, and the SPI, too, about them owning the openspf domains for us, but since he isn't here, there's no point. |
| 22:04 | <Julian> | "4. How to proceed with regard to DougO's alleged DoS scenario" |
| 22:05 | <Julian> | So, it seems as if DougO hasn't really discovered a vulnerability that is specific to SPF. |
| 22:05 | <SDGathman> | The only convincing way is to measure actually implementations of the attack (with a single MTA). |
| 22:05 | <Julian> | Furthermore, SPF seems to be better designed with regard to processing limits than other DNS applications. |
| 22:05 | <SDGathman> | Then compare with an attack based solely on PTR :-) |