[14:28:12] --- gordonf has joined
[14:31:24] --- wrs1864 has joined
[14:36:46] --- wrs1864 has left
[14:37:41] --- wrs1864 has joined
[14:39:16] --- SamSilberman has joined
[14:44:48] <gordonf> I've been off-line all weekend. Much going on aside from DC's new draft?
[14:46:35] <wrs1864> did you see Andy Netwon's note? RFC2821 first, RFC2822 next. need to discuss semantics (and syntax) now.
[14:46:54] <wrs1864> is there a jabber session today?
[14:47:00] <gordonf> There's supposed to be I thought
[14:47:13] --- tonyhansen has joined
[14:47:22] --- molson has joined
[14:48:31] <gordonf> I'm not convinced we need to go whole hog on a mess of representations - I wonder how much longer before SMTP becomes obsolete.
[14:48:51] --- resnick has joined
[14:49:05] <wrs1864> SMTP will probably die around the same time ASCII dies...
[14:49:09] <gordonf> heh heh
[14:49:25] <gordonf> One of those "temporary solutions?"
[14:49:51] <gordonf> I didn't want to go ape on something I believe, anyway, should be replaced.
[14:50:05] <gordonf> If it's not going to get replaced that's another matter
[14:50:22] <molson> Why not fix it rather than replace it?
[14:50:39] <gordonf> It seems our attempts to "fix it" breaks a lot of apparently useful stuff.
[14:52:17] --- mrose has joined
[14:52:43] <mrose> sorry for joining a few minutes late. andrew is in transit. we will wait two more minutes and then start.
[14:53:10] --- mengwong has joined
[14:53:16] --- mengwong has left: Disconnected
[14:53:55] --- mengwong has joined
[14:54:45] <mengwong> mooo.
[14:54:53] <gordonf> baaaa
[14:55:24] <mengwong> so, can we tweak S/MIME to act more like Y!DK?
[14:56:03] <gordonf> what's y!dk? Yahoo's trusted sender initiative?
[14:56:10] <wrs1864> yeah
[14:56:16] <wrs1864> DomainKeys
[14:56:30] <mrose> okay. let's get started.
[14:56:44] <mrose> this will probably be a shorter chat, given the number of folks on.
[14:56:57] <mrose> andrew is in transit, and will be unable to join. hence, i'll be doing all the moderating.
[14:57:43] <mrose> so, who'd like to start? reminder: the protocol is "enq - <topic>", wait for a go from me, and then "eot" when done.
[14:58:12] <wrs1864> <rts SPF as a base>
[14:58:23] <mrose> wrs - go.
[14:58:26] <resnick> rts spf as base
[14:59:01] <wrs1864> I'm not entirely sure exactly what everyone means by "semantics". Would it help to use SPF (or DMP) as a base just for discussion purposes?
[14:59:03] <wrs1864> EOT
[14:59:13] <mrose> resnick - go.
[14:59:14] <gordonf> <rts>
[15:00:06] <resnick> Well, let me answer Wayne's query first: Semantics is "the meanings of the pieces of data we're going to store in the DNS."
[15:00:47] <resnick> And insofar as that goes, I think it would be useful to examine SPF (and Caller ID) and extract from them the things that we think are most important to represent in the DNS.
[15:01:25] <resnick> But I think it would be a really bad idea to use either of those documents as a "base" per se, because they are really tied up in the syntax (the data) rather than the semantics.
[15:01:50] <molson> I agree; they are auseful source for requirements
[15:01:54] <resnick> I've started making a list of semantic elements (not done yet). We should leave syntax to a later date.
[15:01:57] <resnick> eot
[15:02:02] <mrose> molson - you don't have the token
[15:02:06] <mrose> gordon - go
[15:02:16] <gordonf> Example Semantics: Records for each sender vs records for the domain?
[15:02:29] <gordonf> Also: SPF's a different proposal now than it was before IETF 59 - it more resembles RMX's storage mechanism now
[15:02:32] <gordonf> <eot>
[15:02:38] <mrose> molson - go.
[15:03:01] <wrs1864> <rts SPF changes>
[15:03:29] <resnick> <rts examples of semantics>
[15:03:50] <mrose> molson - token revoked
[15:04:12] <mrose> we'll stick with semantics in general before talking about specific proposals, so resnick - go
[15:06:00] <resnick> As an example of what I'm thinking about: We might decide that conveying IP addresses is something we want in the DNS, conveying domain names is, but conveying MX records isn't. We might consider user messages (i.e. "Here's why it didn't work") important, or not. <eot>
[15:06:02] <mrose> resnick - ?
[15:06:18] * resnick apologizes for typing long paragraphs
[15:07:11] <wrs1864> <rts>
[15:08:14] <mrose> wrs - go
[15:08:21] <wrs1864> So, is using IP address vs using RR of hostnames (A, MX, etc.) a semantic issue?<eot>
[15:08:34] <resnick> <rts>
[15:08:54] <mrose> resnick & wrs - you two go back on forth on this, until both send eot
[15:09:04] <wrs1864> <rts no moderation for a while?>
[15:09:11] <mrose> correct
[15:09:45] <resnick> wrs: Correct, it's the *meaning* of the records that we're going to discuss first. Then we'll get down to what form they will take (i.e., the syntax)
[15:09:57] <resnick> So, for my own opinion:
[15:10:30] <resnick> IP address and domain names of A records are fine, MX's and messages to send back to the user are big time overkill.
[15:10:53] <wrs1864> I don't know if everyone saw Greg Connor's post to the mailing list, but If I understand things correctly, I thought he did a reasonable job of listing the semantics
[15:11:13] <wrs1864> Why are A records ok, but MX not ok?
[15:11:18] <wrs1864> or do you mean RMX?
[15:11:28] <gordonf> <rts, MX not ok>
[15:11:55] <resnick> As memory serves (and we should bring in some others on the list)...
[15:11:56] <wrs1864> many domains have in-MTAs == out-MTAs, hence MX is a very useful shorthand
[15:12:21] <resnick> Indirection of MXs to CNAMEs to A records has caused all sorts of headaches in the past.
[15:12:24] <mrose> gordon - join conversation with resnick and wrs
[15:12:41] <gordonf> Larger domains, the ones being spoofed, do have different send and receive hosts. Some don't have receive hosts at all,
[15:12:41] <resnick> I'd hate to see us add MARID->MX->CNAME->A
[15:13:39] <resnick> gorodonf: I don't think anyone's asking for MX to be required, just whether it should be an available shorthand, which I don't think it needs to be.
[15:14:00] <gordonf> I agree, it takes just as much information in DNS to say: "Use my MX machines as senders"
[15:14:15] <gordonf> Because it then has to look the MXes up
[15:14:21] <wrs1864> Well, MARID adds one level of indirection. I don't see MARID -> CNAME -> A as being much better.
[15:14:48] <resnick> wrs: You're probably right, and we should ask whether that's even a good idea.
[15:15:02] <wrs1864> you are thinking of IP address only?
[15:15:08] <resnick> Or A records.
[15:15:25] <resnick> (i.e., I can give a domain name that points to a bunch of addresses)
[15:15:27] <wrs1864> as in FSV or DMP?
[15:15:31] <gordonf> (Assuming 2821 for a moment) Given all the information we have in a 2821 conversation we should try to attempt to make the query in one DNS packet
[15:15:41] * gordonf is biased of course
[15:16:18] <resnick> I agree with wrs on at least the point that some shorthand is good
[15:16:24] <resnick> Hence allowing for A records
[15:16:40] <wrs1864> resnick: you mean something like "_MARID.domain.tld A 1.2.3.4" "_MARID.domain.tld A "1.2.3.5"?
[15:16:43] <resnick> (I'd rather not have to change my A records *and* my MARID records every time.)
[15:16:53] <molson> <rts buried requirements>
[15:17:16] <gordonf> resnick: What about MARID-aware software that could change them for you? As in dynamic DNS updates?
[15:18:18] <resnick> gordon: I don't think I want that kind of dependency.
[15:18:48] <gordonf> It's something to consider even if the semantics are much simpler
[15:18:53] <resnick> wrs: No, I was saying that the MARID record (TXT or new RR) would point to a domain name which would have an A record.
[15:18:58] <gordonf> I wouldn't make it mandatory
[15:19:30] <wrs1864> resnick: ok, but then every time many people update their list of MXes (add a secondary), they have to update their MARID record
[15:19:32] <gordonf> I better eot for now
[15:20:00] <mrose> resnick - ?
[15:20:01] <resnick> wrs: Yes, if you're at a site where MX always == MARID, you'd have a double update.
[15:20:23] <wrs1864> (IIRC, Margaret had a RTS>
[15:20:37] <mrose> yes, i'm waiting for eot from you and resnick
[15:20:39] <resnick> <eot any time>
[15:20:45] <wrs1864> I posted some SPF usage stats to the mailing list a few weeks back. A huge number of domains have that
[15:20:53] <wrs1864> <eot>
[15:21:12] <gordonf> <rts>
[15:21:17] <mrose> molson - go
[15:21:49] <molson> I think I heard two requirments - minimal DNS lookups and one place to update
[15:22:12] <molson> Are they in conflict?
[15:22:14] <molson> <eot>
[15:22:20] <resnick> <rts conflict>
[15:22:38] <mrose> gordon - go
[15:22:53] <gordonf> DNS traffic stats for SPF available? <eot>
[15:23:08] <mrose> resnick - go
[15:23:29] <resnick> Yes, # of lookups and # of updates are in conflict. Which is why they can't both be requirements, but desirables which we should maximize.
[15:23:31] <wrs1864> <rts SPF stats>
[15:23:39] <resnick> <eot>
[15:23:43] <mrose> wrs - go
[15:24:15] <molson> <rts desirables>
[15:24:29] <wrs1864> I don't have figured right at the top of my head, but a very large percentage of SPF records require just one DNS lookup to determine everything, and that SPF record is cached.<eot>
[15:24:58] <wrs1864> <rts amendment>
[15:25:09] <mrose> wrs - continue
[15:25:39] <wrs1864> Ok, I guess in pratice in the short run, there are also some DNS lookups for global whitelisting. In the long run, this should not be needed.
[15:25:41] <wrs1864> <eot>
[15:26:07] <mrose> molson - go
[15:26:36] <molson> I think minimal lookups is the requirement - it happens far more often
[15:26:51] <molson> updates are less frequent and can be addressed with tools
[15:26:52] <molson> <eot>
[15:27:00] <resnick> <rts>
[15:27:12] <mrose> resnick - go
[15:27:33] <resnick> molson: I lean that way too, which is why I think we should nip it at A records and not use MXs.
[15:27:37] <resnick> <eot>
[15:27:51] <wrs1864> <rts mx>
[15:27:56] <mrose> wrs - go
[15:28:27] <wrs1864> One thing to consider about MX records is that they are often queried by the MTA to do anti-spam checks anyway. They are already cached.<eot>
[15:29:08] <resnick> <rts>
[15:29:14] <SamSilberman> <rts mx>
[15:30:03] <mrose> resnick - go
[15:30:05] <resnick> wrs: Is there a reason to believe that servers will continue to use MX records once they get MARID?<eot>
[15:30:10] <mrose> sam - go
[15:30:41] <wrs1864> <rts mx usage>
[15:31:01] <SamSilberman> Mx records are queried by the sender (normally).. the receiving MTA only querires them to today because there is no alt. method <eot>
[15:31:19] <mrose> wrs - go
[15:31:23] <wrs1864> Yes, I think that domains that send email back and forth between each other will generally have MX records cached.
[15:31:26] <wrs1864> <eot>
[15:31:41] <resnick> <rts>
[15:31:54] <mrose> let's try an experiment - given that there are so few folks on today, let's skip moderation for the next 15 minutes and see how it goes
[15:32:20] * gordonf is on phone and may be silent for a while
[15:32:21] <resnick> I receive lots of mail from the IETF list servers, but I'll betcha I don't have their MX's cached.
[15:32:44] <resnick> I don't buy that as a valid reason to leave MX lookup as a needed function.
[15:33:28] <resnick> I just don't think indirection of this sort buys you that much, and it makes the lookups more complex.
[15:33:43] <gordonf> Not to mention adds more DNS overhead
[15:33:55] <wrs1864> I think we need to be careful not to be penny wise and pound foolish. The reasons that MX was included in SPF are 1) they make it simpler for many people, 2) it reduces errors from people having to do double updates, and 3) it isn't a significant cost.
[15:33:55] * resnick nods
[15:34:32] <molson> But how much of that can be addressed by a publication tool?
[15:34:36] <mengwong> there is a tradeoff here. what's complex for computers is easier for humans. what's easy for computers is harder for humans. given that we aren't paying by the cpu second, i think we should make things easy for humans.
[15:34:57] <molson> good point
[15:34:59] <mengwong> if you created a publication tool, you would have the easy format and then you would have to compile that into DNS.
[15:35:07] <mengwong> and that would be a barrier to adoption.
[15:35:13] <wrs1864> If we had a MARID RR, we could have the name servers send the MX and A records as additional records in the DNS query.
[15:35:38] <mengwong> resnick, do you have an antispam rule that requires that senders have valid, resolvable domains? if so, you are doing MX and A lookups already.
[15:36:17] <resnick> meng: I don't, but that's a different matter.
[15:36:20] <mengwong> in any case, isn't this a syntax issue, and not a semantics issue?
[15:36:32] <resnick> No, it's not syntax.
[15:36:52] <resnick> We're deciding what functionality we need. Indirection of records is one.
[15:37:20] <resnick> (Sorry, catching up; I had a phone call)
[15:37:43] <resnick> The frequency of changes to these things needs to be balanced against the frequency of the operation....
[15:38:15] <mengwong> ... as well as the overall deployability of whatever we come up with.
[15:38:17] <wrs1864> And neither of those are as important as potential errors from people forgetting to update both records
[15:38:19] <resnick> Assuming that every e-mail message is going to get these lookups done, CPU cycles (and more imporantly UDP packets) are not free.
[15:38:33] <mengwong> this is not an academic exercise; we are asking a lot of people out there to do this work, and the easier we make it, the more likely they are to do it.
[15:38:47] <mengwong> if we make it hard for people to do this, they won't bother.
[15:39:15] <resnick> Eventually, tools can be automated to do the updates properly. For most folks, we're not talking about rocket science.
[15:39:32] <molson> Most people will need a tool; most domain owners are not particularly technical
[15:39:33] <mengwong> i know about tools. i wrote a publishing tool for DMP. still, nobody published DMP.
[15:39:41] <mengwong> the tool was out there, nobody used it.
[15:39:58] <wrs1864> (I did!)
[15:40:00] <mengwong> it was too hard for them. when i reformatted into SPF, lots more people became interested and willing to publish.
[15:40:28] <resnick> Scaling to Internet-wide use is not trivial on either user or computer issues. I think you're minimizing the latter seriously.
[15:40:38] <molson> who was trying to publish? Who is the audience for the update mechanism?
[15:40:49] <mengwong> also, the maintenance thing is an issue. if you can set-and-forget, that's a bonus. if you have to do redundant updates, you're going to get mysterious breakage when people forget.
[15:40:52] --- gordonf has left
[15:41:58] <wrs1864> molson: early adopters tend to be more technical. And yet, even technical people shied away from the DMP-like system that SPF originally used
[15:42:22] <resnick> On MX alone: MX and MARID are semantically different. Some folks might want them the same, but many (perhaps most) will want them different. I think making it easy for people to conflate them might make things easier for upfront config, but is going to hurt down the road.
[15:42:47] <resnick> Whether we need other recursions (like A records) is different.
[15:43:10] <mengwong> you know, SPF lets you say things like v=spf1 mx:outbound.mydomain.com
[15:43:29] <mengwong> it's not restricted to "mx means inbound mxes only".
[15:43:50] <resnick> And this is a good thing?
[15:43:57] <wrs1864> yes
[15:44:01] <wrs1864> (IMHO)
[15:44:20] <wrs1864> although I guess a:outbound.mydomain.com is probably more reasonable
[15:44:27] <resnick> Yup.
[15:44:38] <SamSilberman> why not both?
[15:44:55] <resnick> MX sounds like it's going to make a twisty maze of DNS records.
[15:45:03] <resnick> Side effects will eventually be a big mess.
[15:45:55] <resnick> Sam: Both?
[15:46:06] <wrs1864> Why are MX records pointers instead of addresses?
[15:46:44] <wrs1864> I forget where it was talked about, but I seem to recall an RFC that says that this indirection is part of the philosophy of DNS
[15:47:11] <resnick> One level of indirection, absolutely.
[15:47:20] <resnick> but....
[15:47:27] * resnick goes to find 2821
[15:47:36] <wrs1864> but everything in compsci can be solved by adding another level of indirection!
[15:47:53] * resnick chuckles
[15:48:05] <SamSilberman> I might agree that the initial query to get the initial SPF records shoud not be an MX lookup, but the subsequent indirections certainly can look up the MX
[15:49:12] <mrose> we're at the three minute mark. any closing comments?
[15:49:47] * resnick will take his comments to the list.
[15:50:16] <wrs1864> people's time is far more important than computer time! Error prone systems should be avoided, if possible.
[15:50:20] <wrs1864> <eot>
[15:50:24] <mengwong> large networks already have a maze of outbound mail servers. the reason SPF is messy is because the problem domain is messy, and the solution domain matches the problem domain.
[15:50:31] <mrose> all - thanks. i agree that greg connor's email is a useful synopsis that people may wish to comment on...
[15:51:26] <mrose> without taking any sides in this particular argument, i will merely note that "messy" solutions tend not to get approved by the higher-ups... they seem to care more about architecture and design consistency that bolt-on jobs. that may inform some folks opinions on things
[15:52:58] <mengwong> messiness is relative. suppose i already have all my outbound servers described under outbound.mydomain.com. if you're going to ask me to redescribe them all under an A record, that looks pretty messy to me.
[15:54:55] <mengwong> with respect, i suggest that there is a significant lack of overlap between the IETF membership and the system administrators responsible for running large networks today, and without input from the people who would be responsible for implementation and deployment, much of this conversation is speculative and not definitive.
[15:55:57] <resnick> Messiness of *your* zone file is one thing. Messiness of the packets going across the network is another. Again, you don't want to minimize the latter. And on the "overlap" question, I think you might be surprised as to who has what experience.
[15:56:16] <mengwong> i'd like to be proven wrong on that count.
[15:56:16] <wrs1864> Yeah, but that doesn't change the "less is more" preference for the IETF
[15:57:07] <wrs1864> resnick: is the problem just the packets?
[15:57:17] <resnick> There's a reason for that preference. Get involved in a few conversations about congestion control; your disturbance level will go up.
[15:57:33] <resnick> wrs: No, not just the packets themselves. Also, the operations of servers.
[15:57:35] <wrs1864> would adding a patch to the name server that sends the MX and A records along with the MARID record solve the problem?
[15:57:59] <resnick> I'm inclined to get Ned Freed to weigh in. He has experience building servers that lots of those big folks use.
[15:58:34] <wrs1864> IIRC, he is supposed to be the DNS rep for MARID, right?
[15:59:05] <resnick> patches: We're starting to get to the level where I'm just scared, and I think Rob Austein (the DNS dude) is the right one to ask.
[16:00:15] <wrs1864> Well, anything that supports a new RR type will need a small amount of code anyway. BIND9 has nice plugins for this. Maybe "patch" is the wrong word.
[16:08:18] --- gordonf has joined
[16:09:28] --- resnick has left
[16:10:22] --- gordonf has left
[16:13:58] --- tonyhansen has left
[16:22:59] --- mengwong has left
[16:24:40] --- molson has left
[16:42:10] --- SamSilberman has left
[17:20:22] --- mrose has left
[18:07:07] --- wrs1864 has left