[14:24:12] --- fenton has joined
[14:40:35] --- jlcjohn has joined
[14:44:19] --- andy has joined
[14:46:27] --- mtnviewmark has joined
[14:53:53] <andy> So my clock says 4:05.
[14:53:54] --- ogud has left: Lost connection
[14:54:37] <jlcjohn> Does Mark want to say whether I need to repost my comments?
[14:54:55] <mtnviewmark> You're in Perth?!?!? ... oh, 4:06 *pm*...
[14:55:30] <andy> mark?
[14:55:40] <mtnviewmark> there were many comments in that list, and some of them are simple incorporations... some are not
[14:55:54] <mtnviewmark> perhaps I'll post a reply, but with a new, "last-call" subject line.
[14:55:55] <jlcjohn> true...
[14:55:57] <mtnviewmark> Is that okay?
[14:56:13] <jlcjohn> Sounds pretty good.
[14:56:13] <andy> ok by me if it is ok by John.
[14:56:45] <andy> Marshall is on travel today and may not be present. So let's go ahead and start.
[14:57:13] <andy> With so few people, I do not think we need the token passing protocol.
[14:57:44] <andy> I'd like to start moving the working group to working on CSV. So, are there any outstanding issues with CSV?
[14:59:18] <jlcjohn> From my standpoint, not much: the authors are putting their efforts more into BATV
[14:59:31] <mtnviewmark> does that mean they think CSV is done?
[14:59:46] <jlcjohn> IMHO, mostly yes.
[15:00:44] <mtnviewmark> I have several issues with the design...
[15:00:53] <jlcjohn> OK...
[15:01:12] <andy> First, did you guys talk after the last session?
[15:01:16] <mtnviewmark> no
[15:01:20] <jlcjohn> alas...
[15:01:35] <mtnviewmark> I seem to remember a lot of draft editing before deadlines...
[15:01:36] <andy> just checking....
[15:01:51] <jlcjohn> ;^)
[15:01:54] <andy> that was not meant as an admonishment.
[15:02:32] <mtnviewmark> should I just spew my list (mostly off the top of my head?)
[15:02:43] <jlcjohn> fine with me...
[15:02:49] <andy> yeah
[15:03:28] <mtnviewmark> 1) The weight value really only has one demonstrated useful value (2) - the other combinations of bits not being well understood
[15:03:31] --- wrs1864 has joined
[15:04:14] <jlcjohn> 1) does the actual draft need language changed?
[15:04:19] <andy> is that it Mark?
[15:04:31] <mtnviewmark> 2) I wonder does CSV-DNS follow existing RHBL practice -- or are we creating a new standard for lookup of info that doesn't need to be created
[15:05:13] <jlcjohn> 2) The authors feel a need for more than one-bit.
[15:05:33] <jlcjohn> (I'm not sure there _is_ an existing standard to copy.)
[15:05:57] <mtnviewmark> [on 2] no, there isn't a standard, just existing practice, and I believe they return 127.0.0.x where x returns useful info
[15:06:11] <jlcjohn> agreed...
[15:06:18] <wrs1864> (sometimes it is 127.a.b.c)
[15:06:45] <mtnviewmark> 3) I fear that the SRV record may have deployment issues (though less so since only people running servers need to deploy it, not vanity domain users)
[15:07:25] <jlcjohn> 3) Good question: we've asked around and not found problems.
[15:07:26] <dcrocker> mark - ANY record type has deployment issues. the challenge is choosing one with issues that are the least harmful. /
[15:07:40] <mtnviewmark> 4) Strikes me that there is a even one-DNS look up less solution than CSV involving A records at _client._smtp.<helo name>
[15:07:57] <jlcjohn> 4) Thought we'd settled that...
[15:08:00] <fenton> Has anyone asked the DNS folks about the "creative" use of the Weight field? Do they have any problem with that?
[15:08:30] <mtnviewmark> [on 4] sorry, I wasn't active in prior CSV discussions...
[15:09:05] <dcrocker> dns folk & weight: we are likely to get push-back from them on anything other than a purist, new record.
[15:09:25] <jlcjohn> 4) We need the "authorized" bit; and the "don't bother trying A)ddress lookup also helps.
[15:09:31] <dcrocker> we have a reasonable basis for the current choice and have felt that it is sufficient to overcome their possible objections.
[15:09:46] <wrs1864> dcrocker: I agree. It isn't just the weight field that is being "abused"
[15:09:47] <mtnviewmark> 5) In summary, since so much of a thing like CSV is already available in my MTA (Postfix), I think a solution that matched that would be better, quicker to deploy, and more quickly embraced
[15:10:09] <mtnviewmark> [list done]
[15:10:12] <fenton> dcrocker: no doubt.
[15:10:20] <jlcjohn> 5) Actually, I'm looking at how to implement in Postfix...
[15:12:25] <mtnviewmark> see Postfix's smtpd_helo_restrictions
[15:12:38] <dcrocker> mark - i'm not sure what 'already available' features you refer to (i got here late), but authentication and authorization have no
[15:13:03] <dcrocker> current conventions. In fact, neither does accreditation. So there is LOTS of existing practise, but it all differs. Please clarify. /
[15:14:05] <mtnviewmark> Postfix has a the ability to take the IP, make sure the rDNS look up on it validates, and then do a RHBL check on that domain name
[15:14:25] <mtnviewmark> Now, this differs from CSV in three ways:
[15:14:49] <mtnviewmark> 1) it uses IP -> PTR to get the domain, not HELO -- but really this isn't that different
[15:15:01] <jlcjohn> 1) Oh, but it is!
[15:15:19] <mtnviewmark> 2) CSV allows the domain to authorize -- and this is the one bit of importance -- but I think we can get it a different way
[15:15:38] <mtnviewmark> 3) RHBL and CSV use different methods to look up the reputation
[15:16:07] --- DOtis has joined
[15:16:09] <mtnviewmark> Now on the issue of 1: If you expect HELO domain to correctly be the name of the host, then it isn't
[15:16:17] <jlcjohn> 2) How else would you get unambiguous authorization?
[15:17:12] <mtnviewmark> [still on 1] On the other hand, if you are expecting HELO to be "repurposed" and now to be a domain name used for authorization, then, well if we are going to change HELO's meaning (okay with me), it isn't that hard to change MTA software to use that domain
[15:17:31] <mtnviewmark> [still on 1] in fact Postfix already has checks on HELO...
[15:17:42] --- Harry has joined
[15:18:12] <fenton> On 1), we need to be clear on whether HELO is a hostname or domain name, and if it's a hostname, how many levels up is the domain name to use?
[15:18:30] <dcrocker> mark -- using helo's domain name is not repurposing it. the name is a claim of affiliation. CSV validates that claim./
[15:18:53] <mtnviewmark> [on 2] I'd say, rather than do an SRV lookup on _client._smtp.<domain>, and then do an A lookup on the <target> (though I realize that DNS servers will anticipate the query and give me the value, but it is still 2 queries)
[15:18:57] <dcrocker> fenton - what do you mean 'how many levels up'?
[15:19:02] <DOtis> CSV puts no restriction on EHLO other than it resolve using a CSA record.
[15:19:53] <fenton> I mean, if the host name is host.a.b.c.domain.com, how do you know to look up for domain.com and not a.b.c.domain.com? It would be nice not to have to publish records for every subdomain.
[15:20:11] <mtnviewmark> [still on 2, I'll get back to 1]: just do an A look up on _client._smtp.<domain> -- publishing A records there can be the authorization: positive auth if it includes the client IP, negative otherwise
[15:20:26] <dcrocker> fenton - you look up the entire name you are given. anything else would be far, far outside any formal standards./
[15:20:39] <DOtis> I would expect accreditation type of services would handle such sub-domain problems.
[15:20:47] <mtnviewmark> [on 1]: I believe RFC2821 says that HELO is supposed to be the host name of the client.
[15:21:15] <DOtis> CSA does not change this. It only requires that it resolve to a CSA record.
[15:21:24] <mtnviewmark> [on 1]: Now, if we are creating a standard which will induce people to put something other in HELO, then we are repurposing it (which is okay, but we should be clear we are doing it)
[15:21:51] <DOtis> No. There is no need to do this.
[15:21:57] <mtnviewmark> [on 1]: Good - so if you expect HELO to be the name of the client, then really, using it over the PTR for the client IP is just an optimization
[15:22:10] <mtnviewmark> [on 1]: A good optimization -
[15:22:13] <fenton> DOtis: But it sounds like a lot of CSA records need to be created owthewise
[15:22:24] <dcrocker> mark - something other than what? if people are putting a name there, today, then they are already making a claim of affiliation. csv simply validates that claim./
[15:22:36] <DOtis> The number would equal the number of hosts.
[15:22:43] <DOtis> How is that a problem?
[15:22:53] <mtnviewmark> [on 1]: Yes - But I think you can validate that claim with a method that is MUCH closer to what existing practice does today
[15:23:33] <dcrocker> mark - there are LOTS of different existing practices today, not just one. AND they are IP Address based, not domain name-based/
[15:23:47] <DOtis> CSA does not restrict combining EHLO domains and ignoring the host name, but that is not a topic that needs to be addressed.
[15:23:58] <mtnviewmark> [on 1]: It isn't a problem, it is just unnecessarily different than current practice
[15:24:33] <mtnviewmark> dcrocker - I don't think that is true -- I think there is one predominant domain based practice: rDNS the IP, and RHBL that
[15:24:54] <jlcjohn> rDNS is largely broken...
[15:25:25] <DOtis> The description used in the MPR draft shows how many EHLO domains can be combined into a single lookup.
[15:25:47] <DOtis> The sub-domain problem goes away.
[15:25:51] <mtnviewmark> DOtis: Is that because the EHLO domain will NOT be the client IP? That is what I asked about earlier.
[15:26:00] <mtnviewmark> s/client IP/client name/
[15:26:44] <dcrocker> rDNS is universally acknowleged to be problematic, as the CSV document notes./
[15:26:48] <mtnviewmark> so: Current practice: client IP -> PTR -> A -> RHBL
[15:27:00] <mtnviewmark> CSV: HELO -> SRV -> A -> DNA
[15:27:24] <mtnviewmark> I think: HELO -> A -> RHBL would be simpler and closer to current practice
[15:27:43] <DOtis> I had offered a solution privately for that problem...
[15:27:48] <mtnviewmark> And again, we get the auth by not looking up A for <helo-domain> but for _client._smtp.<helo-domain>
[15:28:00] <jlcjohn> Mark: how does that get around incomplete A)ddress RR lists?
[15:28:19] <mtnviewmark> How does CSV? -- same problem
[15:28:37] <jlcjohn> CSV has the bit to say "don't bother"
[15:28:47] <mtnviewmark> But, in general, if we expect the HELO domain to be the domain name of the client, then we don't expect many A records for it
[15:29:14] <mtnviewmark> Yes, but as we've discussed, if the 'don't bother bit is set, it is tantmount to saying - you can't do anything with this
[15:29:21] <DOtis> By using the host name, there can be a mapping of name to IP list.
[15:29:45] <DOtis> If you use something like mailbox domain, then no there can not be.
[15:29:49] <jlcjohn> Mark: "don't expect many" may not cut it when dealing with millions of MTAs.
[15:30:02] <mtnviewmark> DOtis: I don't think anybody here is talking about mailbox domains -- the topic is CSV
[15:30:27] <dcrocker> mark -- "we get the auth by not looking up A for <helo-domain> but for _client" involves different administration than is done today and different checking software. So now we are quibbling about some details./
[15:30:34] <DOtis> I was referring to the scale or expectation of being able to list IP addresses.
[15:31:40] <mtnviewmark> So this is the logic: "Some domains are going to use a HELO name on so many MTAs that they won't be able to fit all the A records in a DNS UDP response - hence we need a way to say - Sorry, you can't check based on IP address."?
[15:31:58] <mtnviewmark> (This seems to apply to both what I'm proposing and CSV)
[15:32:03] <DOtis> No.
[15:32:12] <DOtis> Why should they not use the host name?
[15:32:18] <jlcjohn> Mark (on "don't bother"): Recall that SRV gives us quite a few more bits to grow into.
[15:32:20] <mtnviewmark> So where does the number of A records being too large come up>?
[15:33:05] <DOtis> I think this was to isolate functions more than to suggest it can't be done.
[15:33:12] <jlcjohn> Mark (on check IP address): What part of "rDNS is broken!" don't you understand?
[15:33:28] <mtnviewmark> jlcjohn - I do understand!
[15:33:33] <jlcjohn> THX!
[15:33:51] <mtnviewmark> That is why current checks of IP -> PTR -> A -> RHBL are poor choices
[15:34:41] <jlcjohn> On SRV (vs. A): Are we actually arguing anything other than religion here?
[15:34:45] <mtnviewmark> But, HELO -> A -> RHBL avoids the rDNS -- BUT, basically you've traded one pile of pooly configured things (rDNS) for another (HELO) -- though we don't mind forcing people to start getting HELO right
[15:35:17] <fenton> But HELO is much more in control of senders
[15:35:29] <jlcjohn> Right: without getting a useful HELO, we have only shifting sand to build on. :^(
[15:35:48] <mtnviewmark> [on SRV vs. A]: many people seem very concerned about DNS bandwidth, so A is less bandwidth than SRV - and it would much easier to deploy as it is very like what MTAs already do
[15:35:49] <DOtis> Agreed. The same admin can ensure everything agrees.
[15:36:21] <mtnviewmark> Don't get me wrong: I LIKE CHECKING HELO!
[15:36:45] <dcrocker> poor configuration: one of the reasons rDNS is problematic is that the administration of that part of the DNS does not align with the folks who own
[15:36:45] <DOtis> There is not much to be saved and much to be lost.
[15:36:46] <fenton> A isn't that much smaller than SRV, is it? The big issue is if you run out of the UDP realm.
[15:36:55] <jlcjohn> SRV vs A: The SRV gives me much more room for expansion: I like that. ;^)
[15:36:59] <dcrocker> the actual domain names. by contrast, a forward resolution scheme maps much better/
[15:37:11] <mtnviewmark> Er, remember: Even with SRV, you still need the A records as well
[15:37:24] <DOtis> SRV also indicates authorization AND provides the IP address list.
[15:37:29] <mtnviewmark> So really, this is SRV+A vs. A
[15:37:45] <jlcjohn> ... except the A comes as part of SRV...
[15:37:51] <dcrocker> "with SRV, you still need the A records" - right, since the SRV is doing a NEW function (authorization).
[15:38:13] <mtnviewmark> that is only an optimization -- so yes, there is still only one round trip to the DNS server, but there are more RR being returned
[15:38:31] <jlcjohn> true...
[15:38:36] <DOtis> No. It provides information not seen otherwise.
[15:38:56] <jlcjohn> Doug: that's why there's more bandwidth...
[15:38:57] <mtnviewmark> DOtis - I was proposing to get that information by existing of the A record at _client._stmp.<domain>
[15:39:05] <mtnviewmark> rather than the A record at <domain>
[15:39:20] <mtnviewmark> s/exsiting/existance/
[15:39:33] <jlcjohn> Mark: yes, I noticed; and that does provide almost one-bit of information.
[15:39:43] <jlcjohn> But SRV can provide many.
[15:39:59] <mtnviewmark> No, if you are really anticipating alternate schemes of authentication -- then perhaps the drafts should make that clear
[15:40:14] <DOtis> With all the talk of extensibility...
[15:40:18] <fenton> but wait, SRV provides a symbolic address that still needs to be resolved with an A lookup, right?
[15:40:27] <jlcjohn> Let's ask how you ensure that the subdomain A records stay in sync with the main A records.
[15:40:36] <DOtis> It is part of the SRV record per the RFC.
[15:40:44] <mtnviewmark> and rather than the nutsy bit fields -- use one bit to say authorized/not-authorized and use an enum to say whcih method -- the first two are By-IP-List and Unknown
[15:40:45] <jlcjohn> Fenton: the server does that automatically.
[15:41:08] <jlcjohn> Mark: where's the enum?
[15:41:32] <mtnviewmark> Let's steal the weight field for the bit, and the priority field for the enum
[15:41:38] <fenton> thanks. It's just that the SRV records in my zone file have symbolic names. Didn't know that was automagically resolved.
[15:41:58] <jlcjohn> I'm certainly willing to discuss priority as an enum...
[15:42:40] <mtnviewmark> [Quick question: Does BIND automatically add the A records for the target name in an SRV record? Like it does for an MX record?]
[15:42:46] <jlcjohn> (I'm not sure what other values might mean, though...)
[15:43:03] <jlcjohn> Mark: basically it's the same kind of logic.
[15:43:16] <wrs1864> mtnviewmark: yes
[15:43:24] <mtnviewmark> jlcjohn - yes but seems much more clear to me -- and someone else did mention on this list "there are lots more bits to grow in"
[15:44:03] <mtnviewmark> whereas, the current bit field scheme results in values that took you and I an hour to get the question asked and answered!
[15:44:14] <fenton> Mark: Everyone says it does but 'dig' doesn't seem to be displaying the numeric address, which makes me wonder...
[15:44:20] <mtnviewmark> (and because the meaning of the bits is spread across the two drafts)
[15:44:49] <mtnviewmark> okay, quick - who is running Bind 8 or 9 and has an SRV records - I'll dig it!
[15:44:51] <jlcjohn> Mark: I see no fundamental problem with an enum for that, though I can't imagine the enum growing past eight bits.
[15:45:02] <DOtis> mail-abuse.org
[15:45:04] <DOtis> bind 8
[15:45:12] <fenton> Mark: try _krs._tcp.bluepopcorn.net
[15:46:02] <dcrocker> mark - "enum to say whcih method"... what alternative methods are you thinking of? the point behind a standard like this is to have one way to do the job./
[15:46:25] <mtnviewmark> Uhm DOtis: No SRV record there!
[15:46:33] <mtnviewmark> Fention: Yup, no A records come back with it
[15:46:47] <mtnviewmark> So - looks like we'll be seeing two trips to the DNS server for awhile!
[15:47:10] --- qpathname has joined
[15:47:46] <mtnviewmark> dcrocker: I'm not thinking of any other methods: I think IP list is enough. But others keep saying you have to have a way to say "well, the IP list won't work, so you can't authenticate that way" -- but I don't see where this leaves a server -- what method you use?
[15:47:48] <wrs1864> I think that is because the bluepopcorn.net nameserver isn't authorative for the domains that are referenced in the SRV record
[15:47:50] <DOtis> try _client._smtp.harry.mail-abuse.org
[15:47:52] <andy> I just tested my BIND 9 implementation and it isn't returning A records in the additional section either. And could have sworn it did that before.
[15:47:55] <qpathname> Hi, Daniel Quinlan here
[15:48:17] <mtnviewmark> yes - A records came back in that one
[15:48:35] <mtnviewmark> good
[15:48:35] <jlcjohn> Umm.. are there A records? my _client._smtp.mailhost.jlc.net. returns one.
[15:49:36] <mtnviewmark> In the DOtis case, while there was only one A record of the target, there were others sent back too (NS hosts)
[15:49:54] <jlcjohn> NS is normal additional info.
[15:50:45] <mtnviewmark> Question: The server does a query for SRV @ _client._server.mx.example.com and gets back a SRV with a target of mx.example.com and in the additional section, an A record for mx.example.com...
[15:50:59] <wrs1864> note that in the mail-abuse case, the name server *is* authoratative. to the best of my knowledge, MX lookups won't return A records in the non-authoratative cases either.
[15:51:02] --- willix has joined
[15:51:17] <mtnviewmark> ... Now my SW just did a resolver query to get that, so presumably the resolver lib cached the additional...
[15:52:01] <mtnviewmark> .. when the server SW does the resolver query to get the A record for mx.example.com -- 1) we are assuming the resovler library will used the cached value, 2) what happens if the additionl section didn't contain all the A records for the name?
[15:52:17] <mtnviewmark> Or is this case just pathalogical?
[15:52:50] <jlcjohn> Mark: I'm not sure I understand the question.
[15:52:55] <mtnviewmark> DOtis: [back on the issue of other methods]: If there really is only one method of authentication, IP-List, then why do we need more than the one bit of authorization info?
[15:53:05] <fenton> So are you saying this is a reason to use A directly rather than SRV?
[15:53:41] <mtnviewmark> fenton: As for the question, no I'm just trying to understand the semantics of additional RR records - and if you can rely on that to be 'complete' info... But really, I can't take that off line
[15:53:50] <jlcjohn> BTW, I assume we all mean A iff connection is IPv4...
[15:53:52] <mtnviewmark> fenton: as for the issue of other methods, yes
[15:54:10] <mtnviewmark> (yes if IPv6 then s/A/AAAA/g
[15:54:18] <DOtis> It says none. not authorized and authorized. It also says supported.
[15:54:31] <DOtis> How do you get one bit to say all of that?
[15:54:54] <mtnviewmark> 'cause it is a bit, and an absence of a bit:
[15:55:05] <DOtis> Whaaa
[15:55:08] <andy> I've got an NMI, so I'm gonna tune out. But I encourage everybody to stay on this discussion. It is very good, and I'm glad we are moving forward on CSV.
[15:55:21] <mtnviewmark> a) not supported? Then they'll be no record at _client._smtp.<helo-domain>
[15:55:43] <mtnviewmark> b) support, and auth? Then there are A records at _client._smtp.<helo-domain>
[15:55:51] <DOtis> Supported but this machine may have been compromised as example.
[15:56:06] <DOtis> It could be a machine providing shells.
[15:56:06] <mtnviewmark> c) supported, but no machine auth? Then one A record for 127.0.0.255 at _client._smpt.<helo-domain>
[15:56:07] <dcrocker> "what happens if the additionl section didn't contain all the A records" - given that the information is being returned by the same entity that created the information, one presumes that they will design that information to be used successfully, including fitting into the additional info field./
[15:57:11] <mtnviewmark> dcrocker: Okay, so the whole issue of "don't look for the IP list" has nothing to do with too many A records to fit -- or with some other presumed way to authenticate the hosts. Fine.
[16:00:50] <jlcjohn> Mark: 127.0.0.255 is a good point: we could indeed agree to encode additional information that way (as an additional A (_and_ AAAA) record.
[16:01:14] <jlcjohn> But, I still worry about keeping things in sync...
[16:01:28] <mtnviewmark> Yes - that is the best argument in favor of the SRV record I've heard
[16:01:46] <dcrocker> question: i'm not sure where the discussion is or where it is going. can anyone summarize?
[16:01:56] <mtnviewmark> I can summarize what I've learned
[16:03:09] <mtnviewmark> A) In SRV vs. A: SRV has an admin. advantage in keeping things in sync, and will only require one trip to DNS server iff the server is authoratative for both
[16:03:46] <mtnviewmark> A con't) Though A records would require a little less bandwidth, and might be easier to do in existing MTA software (as they already do it)
[16:03:54] <mtnviewmark> s/do it/do something very close/
[16:04:33] <mtnviewmark> B) CSV authors don't anticipate CSV covering other authentication schemes than IP-List, and don't expect the IP-List to be long, and do expect the HELO name to be the client name
[16:05:23] <mtnviewmark> there
[16:05:48] <DOtis> Do expect the helo name to reference the MTA CSA record. The client name would be defined as the HELO name in this case.
[16:06:22] <mtnviewmark> where by reference, you mean via the _client._smtp prefix...
[16:06:52] <DOtis> That if the EHLO domain is authenticated and authorized, then it could be concluded to represent the client name.
[16:07:09] <mtnviewmark> Well, let's not get to pedantic, but I think when I say "client name" I mean the DNS name that corresponds to the "client IP"
[16:07:27] <DOtis> To the client MTA.
[16:07:36] <jlcjohn> Mark: there are often many names to one IP.
[16:07:41] <mtnviewmark> yes
[16:09:24] <mtnviewmark> so, I think when we say the authenticated and authorized HELO name is the ".... name" we should be clear that it isn't different than something obtainable (or not) via rDNS) ... perhaps the "auth name" or some such
[16:09:43] <mtnviewmark> s/isn't different/is different/ --oops
[16:10:09] <DOtis> I would not want to suggest that rDNS be used.
[16:10:17] <jlcjohn> I agree it would be good to use a clearly descriptive name for the authenticated/authorized HELO string.
[16:11:15] <DOtis> Like harry?
[16:11:25] <mtnviewmark> DOtis: good, then since we use "client ip", we should confuse people by saying "client name" for anything other than the DNS name of the host
[16:11:30] <jlcjohn> Hmm... ;^)
[16:11:31] <mtnviewmark> "harry name" is good
[16:11:41] <mtnviewmark> "csv name" is good
[16:12:27] <DOtis> IP is transitive. What does this mean?
[16:12:44] <mtnviewmark> "IP is transitive"? Where did this come from?
[16:13:27] <mtnviewmark> Well all, this has been wonderful, but it is now 2:30 and I have to go
[16:13:39] <jlcjohn> Sounds like a plan! Thanks.
[16:13:41] <DOtis> It is only used to route to the client but may change often.
[16:14:29] --- mtnviewmark has left: Disconnected
[16:17:45] --- DOtis has left
[16:29:23] --- Harry has left
[17:28:59] --- fenton has left
[19:32:51] --- andy has left
[19:39:15] --- qpathname has left