[14:22:32] --- dcrocker has joined
[14:43:59] --- jlcjohn has joined
[14:56:38] --- mrose has joined
[14:57:14] --- wrs1864 has left: Lost connection
[14:58:39] --- resnick has joined
[14:59:04] --- resnick has left: Disconnected
[14:59:23] --- resnick has joined
[14:59:42] --- andy has joined
[15:00:29] <andy> hello
[15:03:21] --- tonyhansen has joined
[15:05:41] <mrose> ok, let's get started.
[15:05:47] <mrose> first top, resent headers.
[15:06:01] * resnick moans in horror
[15:06:03] <mrose> pete, you have the floor
[15:06:28] <resnick> I'm more inclined for people to ask questions about what I've posted so far.
[15:06:51] <resnick> Is there anything folks want clarified?
[15:07:30] * resnick listens to the crickets
[15:07:41] <mrose> did fred order the ribs, knowing before hand that it would tip the car?
[15:08:11] <andy> I'll start. It seems to me that Resent headers are never suppose to be used if the MTA delievers. Correct?
[15:08:21] <andy> reverse of that actually.
[15:08:58] <resnick> Let me start with: Resent-* fields are for use with an MUA function.
[15:09:10] <resnick> Now, ask your question (if you still have one).
[15:09:16] <andy> ah... yes. That's what I think is key.
[15:09:23] <andy> that helped settle it.
[15:09:31] <andy> of course, where does that leave mailing lists?
[15:09:40] <resnick> The problem is that sendmail and it's brethren act as MUAs sometimes.
[15:09:43] <resnick> As for mailing lists:
[15:10:15] <resnick> They've always been a special case and therefore have never been subject to MUA "rules".
[15:10:53] <dcrocker> pete, let me challenge that. why/how are mailing lists different from users who do forwarding?
[15:11:20] <resnick> First: s/forwarding/resending so we don't get into that particular rodent hole. But....
[15:11:52] <resnick> I don't think they're especially different, and could see a justification being made for using Resent-* with them.
[15:12:16] <resnick> The problem is they do something different than what most "resending" functions in MUAs do.
[15:13:15] <resnick> For example:
[15:13:31] <dcrocker> i don't have any trouble believing that, but i don't know what the details are. i suggest framing this in terms that we can add to the email-arch document.
[15:14:33] <resnick> Resent-Sender must be sent with a single address if the Resent-From has more than one address. The semantics there don't strike me as mapping onto a mailing list.
[15:14:58] <resnick> (That was a bit opaque; do people see what I'm looking at?)
[15:15:32] <dcrocker> no. the mailing list 'owner' is the resent-sender. what am i missing?
[15:15:56] <dcrocker> for that matter, any single re-sent message has one resent-from (also the owner?)
[15:16:21] <resnick> Mmmmm....So you see a mailing list as a resending agent. Did I get that right?
[15:17:24] <resnick> And the header munging that a list does is just "bad behavior"?
[15:17:39] <tonyhansen> are messages coming via a mailing list "from" the sender of the message, or "from" the mailing list? Different people answer the question differently.
[15:18:26] <tonyhansen> how you answer that question affects how you view resent- headers, header munging, etc.
[15:18:50] <dcrocker> i am not particularly expressing my opinions. i'm trying to understand the construct being put forward. i think mailing lists do, in fact, perform user-level forwarding (re-sending, etc.). I'm not saying that requires re-sent headers. just trying to understand your point about the limitations of re-* usage.
[15:18:50] <resnick> Tony: I think that's probably one of the reasons that 2822 avoided lists. There are big variances in people's views of "what is a list and what are it's duties".
[15:19:23] --- willix has joined
[15:19:51] <tonyhansen> hence, some of our current problems
[15:19:56] <dcrocker> pete - strictly speaking, header munging is fine, because the mailing list is re-posting the message and can do whatever it wants. clearly, to be useful, the list needs to be careful about munging.
[15:20:12] --- fenton has joined
[15:20:55] <resnick> Dave: Right. But the fact that we find header munging (sometimes) fine for lists, but almost always really bad for resending, says something about the semantic mismatch.
[15:21:04] <dcrocker> tony - the question of 'from' is interesting, yes. however the human communication is from the original originator to the 'community'.
[15:21:55] <resnick> As I said earlier, I think an argument can be made for Resent-* on lists, but I'd want to see discussion of the apparant change from 822/2822.
[15:22:37] <resnick> MTA-level redirecting (where the MAIL FROM remains the same) I think is the really problematic case.
[15:22:53] <resnick> I don't think Resent-* was ever intended for that.
[15:23:16] <willix> I don't understand. Who wants to see Reset headers used for lists (other them MSFT)? What possible argument could there be in support of it?
[15:23:55] <dcrocker> pete, you mean .forward?
[15:24:09] <willix> Mail Lists already set Sender header. They also set "List-ID" (which is NOT an email address), we can work on something to extend that.
[15:24:56] <resnick> will: Because some lists don't set Sender, and List-ID is inconsistent. But I'd be in favor of using List-ID instead of Resent.
[15:25:18] <resnick> Dave: .forward falls into that category, but only by happenstance of implementation.
[15:25:39] <dcrocker> ack. tnx.
[15:25:46] <andy> Isn't there a simple fix for List ID? If it is an email address, use the domain part. If it is a domain, use that.
[15:25:49] <resnick> System level alias files are the canonical case.
[15:26:23] <andy> s/fix/algorithm/
[15:26:32] <resnick> List-ID would normally be something like "listname.domain.tld".
[15:26:44] <willix> We can specify that mail lists MUST (or SHOULD) set Sender.
[15:27:05] <resnick> willix: What if the original message has a Sender field?
[15:27:24] <resnick> Though I understand it's done, I don't think lists should set Sender.
[15:27:38] * resnick turns to face the windmill
[15:28:00] <andy> The easier fix is to put in a record for "list.domain.name" instead of modifying the list software to insert headers.
[15:28:23] <dcrocker> original vs. list 'sender': 1) the definition of sender is the poster; that's the mailing list for this latter sequence; 2) why retain the original sender?
[15:28:26] <andy> well, actually... I guess that depends on the software in question.
[15:29:02] <resnick> Dave: Do I want to lose the information that a particular message was sent by my secretary to a list?
[15:29:15] <resnick> Maybe, maybe not.
[15:29:25] <dcrocker> why retain it for the fan-out phase?
[15:29:37] <resnick> I do for a normal MUA resend, don't I?
[15:29:44] <resnick> Why retain it there?
[15:30:04] <willix> I just recently looked at RFC2919 and it has format list-id = list-label "." list-id-namespace with list-id-namespace = domain-name / "localhost"
[15:30:11] <dcrocker> IP-level equivalent: when you send an IP datagram, the packet has the originating ethernet address. it is replaced for the next hop. why retain it?
[15:31:21] <willix> List-label does not have to be part of real list email address, i.e. if its list-em@listdomain.com, it does not have to be list-em.listdomain.com
[15:31:36] <dcrocker> architectural view, perhaps: From is MUA to (final) MUA. Sender is MSA to (intermediate) MDA.
[15:32:23] <resnick> Architectural: Disagree. From is author of the content. Sender is user of the MUA.
[15:33:38] <willix> Of all email lists I'm on only spf-discuss uses List-ID: <spf-discuss@v2.listbox.com>. All other mail lists are ok. Also one email list I'm one sets list-id as 1234334345343@localhost (i.e. some long mostly numeric string as list-lable) and it does not correspond to real email list at all
[15:33:41] <resnick> When I resend a message (normal MUA case), I want the remote end to have *all* of the information about the original sending event, including that the author's secretary sent the message.
[15:34:49] <resnick> Otherwise, why would I need Resent-* fields? I could just change Sender.
[15:35:04] <dcrocker> makes sense. but is it a consensus view? much of this is arbitrary. i'd like to see it discussed in terms of players and their actions,r ather than implementation. ie, the 'human' side first, with technical to follow. so, why author versus mua operator? note that Sender is typically recipient of bounce info. that's not required, of course, but it is typical. but original sender almost never should get mailing list bounces.
[15:35:10] <willix> Regarding having information about original sender at each step I agree.
[15:35:39] <willix> Would people consider my suggestion on using Submitted-By header for that?
[15:36:17] <resnick> willix: Why not just List-ID (or List-Owner) for lists and Resent-Sender/Resent-From/Sender/From for other mail?
[15:36:19] <willix> I have entire draft basicly worked out by now, I can post it end of today (its rather long and probably still have syntax problems though)
[15:36:32] <dcrocker> "I want the remote end to have *all* of the information" - this gets to exactly the right question. and i don't have any trouble with that particular position. but we
[15:36:33] --- fenton has left
[15:36:53] --- ghewgill has joined
[15:37:21] <dcrocker> are constrained by established practice. if we are going to grow a new behavior, we have some choices. by way of exploring a different example:
[15:37:54] <dcrocker> we could view sender as the bounces address; hence it needs to be changed according to who should get bounces; and then
[15:38:00] --- DOtis has joined
[15:38:11] <dcrocker> we invent an originating-mua-operator header./
[15:39:13] * resnick winces at pushing Sender into a MTA-level marker
[15:39:57] <resnick> Sender, like From and Date, are MUA things.
[15:40:03] <willix> So you want to replace RFC2821 meaning from being ReturnPath to something else? I don't think this will fly because it has such a long history of how its used
[15:40:08] <resnick> Envelopes and Received headers are for MTAs.
[15:40:23] <resnick> (And Return-Path; thanks willix)
[15:40:28] <jlcjohn> pete++
[15:40:48] <dcrocker> pete - yes, that's what we had in mind for sender originally. but i'm trying to deal with established practise.
[15:41:11] <dcrocker> willix - i'm trying to acknowledge that sender is essentially equivalent to mailfrom.
[15:41:39] <resnick> Dave: I think established practice is mixed, and that's part of the problem.
[15:41:44] <jlcjohn> Dave: I see no reason to try to force a change of Sender every time MAILFROM changes.
[15:42:04] <jlcjohn> (by BATV, for example)
[15:42:42] <resnick> I also think it's easier (i.e., shorter distance) to push Sender away from being MAIL FROM than it is to push it towards given current practice.
[15:43:32] --- mtnviewmark has joined
[15:44:03] <resnick> However, I do think that even though mailing lists are a hairy issue, they are less problematic for present purposes.
[15:44:09] <resnick> .forward is the real problem.
[15:44:10] <willix> dave - I don't think Sender is equivalent to RFC2821 MAIL FROM., its well established to be added to send bounces to and Sender may not be that. Why I acknoledge that name chose for MAIL FROM is not good about indicating of its meaning, I dont think changing its meaning just because it is so is a good idea
[15:44:19] <dcrocker> (looking for solidifying this:) From:author/Sender:MUA-operator/MailFrom:bounces. Where is the most reason poster?
[15:44:24] --- wrs1864 has joined
[15:44:42] <mtnviewmark> (Sorry I'm late -- sick kid, and I'll be leaving early too...)
[15:45:05] <resnick> Dave: Assuming you meant "recent", it's Resent-Sender/Resent-From.
[15:45:06] <dcrocker> (the smiley was not intended, though it might be appropriate)
[15:45:36] <dcrocker> reason -> recent, yes.
[15:46:36] <dcrocker> what is the difference between resent-sender and resent-from, when used by a mailing list?
[15:47:52] <resnick> If we decide it's OK for a mailing list, I don't see any difference.
[15:48:05] <dcrocker> ok. let me push this a bit further:
[15:48:39] <dcrocker> resent-* was designed to splice a new recipient into a direct exchange with the original author. and the
[15:48:40] <resnick> (unless someone wants to get fancy if there are different addresses for the list owner and some sort of list management agent, but now we're getting silly)
[15:49:27] <dcrocker> reason for having -from along with -sender was the usual point that the content/decision authority might be a different person than the one operating the posting software. (Hence pete's point about mua operator is historically consistent.).
[15:49:44] <dcrocker> so, does this map up with the mailing list behavior, or we now overloading resent-*?/
[15:50:10] * resnick agrees strongly with the characterization of the question!!
[15:50:40] <DOtis> How is this different from using the name captured in the Received: header?
[15:50:55] <willix> As I understand it "Sender" header is used to indicate person submitting message on behalf of somebody else. So secretary could use Sender while both's name is in From. When used by Maillist it is basicly that MailList is resending message on behalf of original sender, so if you keep it with RFC2822 meaning it would be that Resent-Sender is mail list and Resent-From is person in From
[15:51:06] --- MatthewElvey has joined
[15:52:06] <willix> But in general I don't agree that mail lists should use Resent fields at all. I think we should just keep current use of Resent as is and for list and forwarders (all kinds of them) work on something new
[15:52:17] <DOtis> If CSV validates this name, it is stronger than any other identity.
[15:52:28] <mrose> we have to wrap this up in 8 mins
[15:53:01] <resnick> To that end, can we put the list discussion on hold and spend the last bit talking about .forward?
[15:53:06] <dcrocker> "Resent-Sender is mail list and Resent-From is person in From", I think that is clever, but wrong. the original from is not doing any re-sending. /
[15:53:11] <willix> The reason is that no matter what we decide we'll end up with having ALL mail lists and MOST forwarders add new headers. So no reason to require them to use Resent for that and confuse people with original meaning in RFC2822
[15:53:19] <dcrocker> pete - yes with topic switch.
[15:53:27] * andy agress with pete
[15:54:07] <resnick> I don't know what to do with these (let's call them) "resending" services. Do they want to keep the envelope the same?
[15:54:12] <willix> Its in Resent-From because its basicly person on behalf of who the resending is being done.
[15:55:12] <mtnviewmark> yes - resending services generally do want to keep the envelope the same
[15:55:39] <tonyhansen> yes, envelope stays the same
[15:55:41] <dcrocker> pete- the problem with a receive-side redirector is that the originator cannot be responsible for any processing errors on the next leg to the recipient./
[15:55:44] <mtnviewmark> ("want" = what operators of such services desire)
[15:56:11] <jlcjohn> For the .forward case, I see only two useful pieces of information: 1) who requested the .forward, and 2) who should tear it down.
[15:56:17] <willix> Regarding enevelope it depends on resending service and if it wants to take care of bounces or not. Most mail lists do but only few forwarding services do (there is no consensus behavior in either case)
[15:56:27] <mtnviewmark> (but, frankly, I think they are all weak for not taking on the responsibilty of dealing with bounces!)
[15:57:19] <resnick> Well, let me ask it a different way:
[15:57:41] <mtnviewmark> I believe the public mailing list survey done by gmane for the WG noted that all mailing list software in use for public mailing lists did indeed handle bounces and so re-wrote MAIL FROM
[15:57:41] <resnick> Do they change if we say, "At least re-write the envelope"?
[15:57:59] <dcrocker> hmmm. going through a forwarding service/.forward/or the like represents a successful processing of the original address.
[15:58:02] <mtnviewmark> That same survey found that only about half altered Sender:
[15:58:46] <mtnviewmark> Since the forwarding serivce is the proxy for the final, hidden, destination, I'd have to agree, it is a"successful processing" and represents, for the sender, the completed transaction
[15:58:52] <dcrocker> under what circumstances should a delivery failure on a redirected/.forwarded segment get sent to the original folks, rather than the forwarding folks?
[15:58:55] <wrs1864> IIRC the survey correctly, it was closer to 80% set Sender: mailing lists are required to change the 2821.MAILFROM. (I forget if that is RFC2821 or 2822 that says so.)
[15:58:56] <andy> I'll note that most of the mailing lists I am subscribed to do not change MAIL FROM.
[15:59:28] <wrs1864> andy: I'm surprised. Which ones don't?
[15:59:31] <mtnviewmark> Personally, if I ran a forwarding service, I'd want to see those bounces, as then I'd know that the address I'm proxying for is broken.
[15:59:58] <mtnviewmark> Survey: http://www.imc.org/ietf-mxcomp/mail-archive/msg00880.html
[16:00:57] <mtnviewmark> 14 out of 24 software packages
[16:01:00] <andy> wrs: I'd have to go through. But it was noticable because only 3 did do it. And I'm a bunch of lists.
[16:01:16] <tonyhansen> .forward sets up an alias for a user. If I send a message to someone who just happens to use a .forward, I'm the one that wants to know if it was delivered to that person. I certainly don't want any bounces redirected somewhere else.
[16:01:30] <andy> wrs: sorry, did not do it.
[16:02:01] <dcrocker> bounces vs. confirmations - yup. different addresses make sense. mumble.
[16:02:18] <jlcjohn> Agree with Tony: the original sender usually wants to know; the forwarder is less likely to care about quick response.
[16:03:59] <wrs1864> mtnviewmark: Ah, I guess that is how you count them. 80% of all mailing lists on gmane set Sender:, but only 60% of the mailing list software packages do.
[16:04:06] <dcrocker> bounces - mumble FOO. there are two different needs. the originator well might want to know the message didn't get through. but obviously they cannot fix the problem; so the controller of the redirection needs to be informed... ALSO.
[16:04:19] <resnick> Right. And adding Resent-* in that case does seem like it violates the intention of 2822, but I don't know that it would be bad.
[16:04:19] <mrose> we have to wrap this up.
[16:04:39] <wrs1864> What is wrong with creating a new header?
[16:04:40] <mtnviewmark> Why don't users of forwarding services want the forwarding service to handle the bounce: If I use mark@forwarding.com, I don't want people I give that address to to know that it fowards to mark@secret.com - which means if the mail bounces from mark@secret.com, I don't want it going all the way back
[16:04:51] <jlcjohn> Dave: the forwarder may be no more able to fix the problem than the originator.
[16:04:54] <resnick> war1864: Deployment.
[16:05:16] <resnick> jlc: Sometimes. Sometimes not.
[16:05:24] <wrs1864> but almost no one uses the resent-* headers the way the PRA expects
[16:05:52] <DOtis> If the desire is to find a header closely associated with the sending MTA, why not use the EHLO/Received: that has been validated rather than injecting a new header?
[16:05:55] <mtnviewmark> Even if mark@secret.com bounces because I don't want the mail due to policy, I want evilqueen@icepalace.org to get the bounce from my "public" address, mark@forwarder.com
[16:06:24] <resnick> Doug: Received is a non-starter. It's trace, and it's not even close to reliable enough in its content.
[16:06:31] <dcrocker> douglass - ehlo does not give an email address. otherwise using that string could be interesting.
[16:06:35] <jlcjohn> I think Mark is discussing a different kind of forwarding than the original .forward.
[16:06:44] <mtnviewmark> (Not to derail things, but, really, in the wild, do we see messages with one or more addresses in From: and a secratary that operates the MUA in Sender:? -- aren't we beyond the age of dictaphones?)
[16:06:53] <DOtis> Ah, but with CSV this information can be reliable.
[16:07:14] <wrs1864> Are we discussing CSV now or SenderID?
[16:07:14] <mtnviewmark> jlcjohn - no, really if I use .forward on my public account to forward to my private machine inside, same thing applies.
[16:07:44] <mtnviewmark> (Dittor for ReceviedSender: vis-a-vis ReceivedFrom:)
[16:08:09] <mtnviewmark> again - unintentional smiley... F r o m : <just a space here> )
[16:08:34] <resnick> mark: s/Received/Resent-/, right?
[16:08:51] <mtnviewmark> er, yes, brain-operating on only a few hours sleep (see comment about sick kid!)
[16:09:08] <resnick> chairs: Where does this leave us?
[16:10:16] <mrose> we're done for now.
[16:10:57] <willix> For charis: I think we'll have to choice but to rework SenderID (and its almost certain the name will not be kept either)
[16:11:29] <MatthewElvey> s/to choice/no choice/?
[16:11:32] <mrose> well, we're certainly all entitled to our opinions as to what the coices are.
[16:11:36] <mrose> s/coices/choices/
[16:11:46] <mrose> okay, that's it for now; further discussion on the mailing list.
[16:11:51] --- mrose has left
[16:12:50] <willix> We should go ahead with SPF Protocol and Mail From (possibly, I'm still worried about SRS and like that), but SenderID drafts will have to stopped from advancing until we can decide what to do (i.e. we'll certainly need new discussion on this concept on the list)
[16:13:19] --- dcrocker has left
[16:13:23] <willix> Matthew - right "no choice"
[16:13:56] <DOtis> Has anyone reviewed the marid-mpr draft?
[16:14:07] <MatthewElvey> Me.
[16:14:23] <willix> MPR - I reviewed it as well
[16:15:05] <willix> Its a good start if we were to decide to drop SPF. But its momentum is such that it'll not happen unless Microsoft decides to threaten everbody with its patents in some bigway
[16:15:35] <MatthewElvey> Hasn't M$ already done that?
[16:16:27] <willix> (my opionion only) - no. They will not enforce the patents
[16:17:29] <willix> And everybody realizes they are way too general and there is considerable prior art
[16:17:36] <mtnviewmark> is anyone going to the FTC shindig in Nov.?
[16:17:46] <MatthewElvey> They have a history of enforcing patents - why would they not enforce this one? It's quite clear that they went through a lot of effort to make their license incompatible with the GPL. Why would they have done that if they had no intention to enforce their patent?
[16:18:08] <mtnviewmark> is anyone going to the Hackers conf. in Nov.?
[16:21:27] <MatthewElvey> Past behaviour is often the best predictor of future behaviour.
[16:22:15] <willix> Well to be certan MPR actually would fall under their patent too ...
[16:22:25] <MatthewElvey> I think CSV+MPR would do well if they leveraged the extant SPF records, which should be valid for HELO. Thoughts?
[16:23:28] <DOtis> I would like to avoid the use of TXT scripts as much as possible. The CSV records or would remain a better choice for several reasons.
[16:25:00] <MatthewElvey> I don't think it falls under the patent application - as Levine pointed out, the patent is only on the body, not the envelope. MPR looks at the From: from the body, but specifically to detect forgery, not to catch spam (or SPAM) as per the patent application. (And remember, it's just a patent application, folks - though I too have referred to it as a patent - it's easy to do.)
[16:25:34] <willix> CSV is not as extendeable. Its ok for double-checkiong back on EHLO, but SPF is good for more complex situations and in general its actually pretty good compact scipting language well fitted for what we need for dns
[16:26:08] <willix> I don't like abuse of TXT any more then you do though... I want new RR type for it from the start
[16:26:27] <DOtis> The script is where much of the danger exits.
[16:26:32] <DOtis> exists.
[16:27:01] <MatthewElvey> Doug, certainly there are reasons for and againt, as we've discussed on-list. willix, did you look at my draft? (SPF3)?
[16:27:20] <willix> Was it posted? Where?
[16:27:48] <DOtis> I did quickly.
[16:28:24] <DOtis> I think one must get away from attempting to list addresses for the association of mailbox domains to MTA or the danger remains.
[16:30:49] --- andy has left
[16:31:17] <willix> I checked John Levine's post again (his analysis of the patents) and he said that it covers both SPF classic (envelope from) and callerid (headers from) and RMX and original Paul Vixie's draft too.
[16:31:25] <willix> Here it is actually "To me, that covers SPF, Caller ID, Sender ID, and any plausible variation on them that calls back to the message domain for advice on handling the message. By some readings it might also cover CSV, but from the narrative text it's clear that they're talking about message domains, not host domains."
[16:33:04] --- mtnviewmark has left: Disconnected
[16:33:18] <MatthewElvey> I posted to the list: I put SPF3 up here: http://elvey.com/it/sieve/draft-ietf-marid-spf3-00.txt as it's not up at iietf.org/internet-drafts yet. To save folks time, I put up http://asrg.sp.am/wiki?action=history&id=Spf3 . Folks may want to look at that to see a quick diff showing the "*Substantive Changes*" between my draft and draft-ietf-marid-prococol-03.
[16:33:20] <willix> So basicly only host domains are somewhat safe, i.e. only HELO and PTR (MTAMARK) checking is safe if you really agree that they have rights to what they claim in their patents
[16:34:50] --- tonyhansen has left: Disconnected
[16:35:26] <MatthewElvey> I'd s/they have rights to what they claim in their patent/ they will get a patent on what they claim in their patent application/
[16:36:28] <MatthewElvey> Arrgh .. oh never mind.
[16:40:31] <willix> My personal opinion about microsoft claims is to let them stick it in their b__ and for us to continue further and deply it as widely as possible. If they decide to fight in the future, make a big deal out of it in press and everywhere else and it'll hurt Microsoft badly how they are damaging anti-spam effort and illegally claiming somebody elses work.
[16:42:42] <MatthewElvey> I don't think fear of hurting their reputation will keep them from trying to enforce their patent. How could M$'reputation get much worse than it already is? Swordfish (the movie) is proven to be nonfiction?
[16:45:06] <willix> Another billion in fines from Europe might cause them to decide to change their mind as well as inevitiable loss of sales due to every bad publicity stunt. And for what? To cause some problems for open-source where you have hard time going against them in court because there is often is no legal entity.
[16:46:00] <willix> But as has been said on list. Its hard for tech geek to imagine how suites and lawyers think
[16:53:18] <MatthewElvey> M$ hasn't demonstrated any second thoughts about funding SCO's lawsuits, or about doing this: http://www.linspire.com/lindows_michaelsminutes_archives.php?id=112
[16:53:48] <MatthewElvey> Both recent.
[17:04:26] <MatthewElvey> Doug, I am curious to know whether you thought the limits I set on an SPF3 lookup were any good.
[17:05:12] --- MatthewElvey has left
[17:13:12] --- resnick has left
[17:26:46] --- ghewgill has left
[18:03:14] --- tonyhansen has joined
[18:06:37] --- tonyhansen has left
[20:16:27] --- willix has left
[20:25:50] --- DOtis has left: Logged Out
[22:44:30] --- wrs1864 has left