Session Date/Time: 29 Apr 2026 20:00
Pete Resnick: Well, greetings all. Welcome to our friendly neighborhood interim meeting for DKIM. I thought I was going to get out of being the voice of DKIM for today because Murray was going to take it, but Murray ended up with a conflicting meeting as well. And my voice is a bit weak after having a cold and cough this past week, so I apologize if it gets a little gravelly toward the end. Well, we're about two minutes after the hour. Let's get the administrative stuff out of the way first. So, this is an IETF meeting. This reminder slide is basically saying that if you are participating in the IETF, then you are agreeing to follow IETF policies and procedures and processes. There's a QR code there if you really want to look at all of the assorted text. But the key features for today: there are IETF guidelines for conduct and an anti-harassment policy and anti-harassment procedures. Please follow those guidelines. I think everybody's been reasonably well-behaved over time. There are also important policies and processes with regard to intellectual property rights. The RFC numbers for those are also on this slide. Please be aware of those, and if you've got stuff that's covered by patents or patent applications, there are requirements for disclosure. If you are worried about those, please look over those documents. And RFC 2026 gives you all the stuff about the processes, 2418 about working group guidelines and procedures. And of course, a reminder that everything's recorded. So, hopefully everybody is aware of these already, but it is our regular reminder. So here's the agenda for today: the administrivia we are currently taking care of. We have discussion of our main document, which is no longer draft Clayton, Murray put the wrong name in the agenda, but that's okay, it's draft-ietf-dkim-dkim2-spec and Richard will be quickly going over the state of the draft since last we chatted and then spend much of our time going over open issues. Then we're going to go over the status of other documents. I know and I don't see Wei in the room yet, Wei sent me some slides having to do with his DNS document, hopefully he'll be able to attend soon and he can present those. But there are a couple of documents that we need to address. Oh, and Allen says he can speak for Wei if he's not here. Thank you, Allen. And we cleaned up the data tracker with some documents that had been outstanding for a while and made sure that what shows up is what we're dealing with. So, and then we'll have time for all other business. Hopefully we will have plenty of time. We seemed to last interim go through relatively quickly. So with that, I'm going to hand over to Richard to share his slides. And there they are. And Richard, you've got the floor. And by the way, as soon as Murray gets here, he will probably be taking over the chair. So Richard, go ahead.
Richard Clayton: Okay. Right. Slides for today. For those who have read many versions of this draft, just to remind you where we are currently. This is from DKIM2 - Clayton. This sort of very nicely looking slide before somebody converted it into the current format. Oh well. We've removed much of the JSON. What remains in JSON are the recipes. The reason we have left those in the JSON, which is then base64 encoded, is because that considerably simplifies the life of implementers because you can just pick a JSON library and parse it, whereas if you had to parse the recipes by writing random bits of code, you would have a hard time of it. The SMTP envelope parameters are base64 encoded in order that you don't need an RFC 5321 parser in order to be able to walk along the relevant header field. The hashes, signatures, selectors, algorithms, and so forth are now in sets separated by commas and the items within those are separated by colons. This is just a reminder of where we are for the sort of basic syntax. For 01, I removed the section which defined what a tag-value field was and then copied the relevant bits, which by no means all of it, into the specification of the two header fields which the specification defines. Hannah has spoken up against this on the list on the basis that this might mean that we cause the basic syntax there to diverge a bit between the two. For the next version, I was going to address this by putting in a sentence saying that the basic structure was the same, so that when we got tempted to do this, we would have to remove that sentence and Hannah could shout a lot and say how much it messed up implementers. But I don't think having it as a separate section adds very much to the document, and in fact, it made it a little bit shorter, which is always good. The other thing is that for 01 compared with 00, I have completely rewritten the section about how and when to validate emails. So hash 9 says basically what needs validating and why and when. And section 10 says how to do the validate and at the prompting of the interim last time, there are now exemplar error messages included, which hopefully implementers will not wish to write their own versions of those but will use those. We can't make them of course, but if they use those, then interworking and debugging interworking should be considerably simpler. So that's where we are. I'm not going to go over what the draft says because you have already read it, because otherwise you wouldn't be here. Okay, so next slide. We have a number of open issues or open-ish issues. As if you are a devoted reader of the list, you will have seen copious correspondence on the topic of whether or not we need recipes. Since we have one person who is extremely keen to split DKIM2 in half and have everything but the recipes in one half and the recipes in another, and various claims have been made that the recipes don't add very much. The authors of the draft feel very strongly that we do need recipes and recipes have been present in DKIM2 since the very first point at which we started discussing this. And the objections which are being made about how complex this all makes it seem to be overridden by the fact that we have running code and that running code has not turned out to be extremely difficult for Bron and or Claude to write for us. And soon, though this is Pete's call and Pete Murray's call, nothing to do with me, we probably ought to determine where consensus lies so that we can't keep on rehashing this issue many, many times.
Pete Resnick: Right. So and I'll just say, you know, Murray and I have now been doing a weekly little check-in with each other. So in the next little bit, we're going to want to make a call. At this point, I'm thinking that the room has been leaning toward let's leave it in one document. So if you have thoughts otherwise, you probably want to raise them now and more importantly on the list and let us know. But we've been listening to the entire thread, we've been watching it carefully and so we'd like to hear where people are at. Objections are more important at this point than saying, yeah, I think it should all be together. I will pause there because the next slide is a completely different topic, so if anybody wishes to chip in. Going once, going twice. All right. If anybody has any... up, Bron wants to chip in. Go ahead, Bron.
Bron Gondwana: Just thought I'd say hi and yes, I have a close to finished working Exim DKIM2 plugin as well, having been told that would be impossible. It's about 30 lines of glue code inside Exim in a couple of places to actually hook getting access to mail from receipt to and parsing the body in a place that avoids having to copy the data around, but it is very small. That doesn't mean it'll be accepted, but if you want to do it, it's not hard.
Pete Resnick: Thanks, I appreciate that. And I will note, you know, there are clearly issues still outstanding with regard to how recipes work and how we want to address different aspects of that. This is simply about whether we need to have a separate non-recipe version of DKIM2 or whether leaving the main document as one is appropriate. So... very good. Let's move on.
Richard Clayton: Yep. Okay. There has been some discussion, though you'd be forgiven for overlooking it because it's only come up a little bit, about whether or not we need a recipe for truncated bodies. Now to rehearse this, delivery status notifications, bounces as some people call them, come in two flavors: just the headers or the header and the body or indeed the header and some of the body. If there is any truncation of the body in the DSN, because the DSN in the third section contains a copy of the headers and possibly the body, then it would not be possible to check whether or not the message being returned, not the DSN itself which has its own verification, but whether or not the message which it is carrying around, whether or not that is actually valid. Now of course you might expect it not necessarily to be valid because it may be being bounced on the basis that it's wrong and is incorrectly formatted. But if you wanted to check the body, then if it has been truncated, we need some way of expressing that. So as I understand it, the idea is that one would add a message instance header to the message which is being returned, and that would say "I have truncated the body" or some of it or all of it, and then you could reuse verification code on the embedded message, not just on the DSN itself. The question is, is this actually useful? Does anybody in practice care about checking the validity of a body anyway in a returned message? Note that the full set of header fields will be present, which means that you'll be able to check that the signature is valid and because the DSN is coming back along the outgoing path on the return path, then you'll be able to check that your signature is present and of course the signature is over just the header fields of the message instance and DKIM2 signature. Now that... if you wanted to validate whether or not those things were correct, then you would need the body, but if all you're doing is checking that your signature is present and correct over the header fields, then perhaps we don't care about the body validity anyway. And if we don't care about the body validity, then the truncated body stuff is, as far as I can tell, not very useful and we should just remove it and make the document shorter.
Pete Resnick: Allen, go ahead.
Allen Robinson: Um, so when I wrote the bounce processing very short draft a while back, I had anticipated that you would not be able to just reuse your message DKIM2 validating stuff exactly as is, because you have to go into the body and find the part that contains the header that you would want to validate that signature against. If you're doing that already, and that's pretty separate or pretty unique to DSN processing, just having that code only check the signature and not also check the body hash seems reasonable. The alternative is you've got a message instance somewhere, I don't know where it would be because it doesn't really make a whole lot of sense for it to be in the returned message header because that's not the message you're returning. So it would be in the DSN itself that says like "I truncated this other thing over here that's not related to the DKIM2 signature of the message that contains that header field." So I'd be inclined to say don't support or don't add truncation specifically for DSN. I mean we can have a debate on whether the body truncation stuff or the "trust me" version of recipes makes sense, but for DSN specifically, I don't think we need it.
Pete Resnick: Anyone else want to jump in here? Anybody else awake? Bron's saying... yeah, I saw that Bron. And since it was he and Claude who put that into the JSON in the first place, I think it goes. Yeah. So to be clear though, I'm talking about DSN specifically. Right, no, no, no, we'll get to the MIME stuff and body part truncation in general later, but yeah, this is specifically for DSNs.
Richard Clayton: Okay, I'll remove the recipe, since as Allen said, putting it in a recipe is probably a... is possibly an inconvenient place to put it.
Pete Resnick: And John Levine saying seems complicated given that fake DSNs aren't much of a threat anyway. All right.
Richard Clayton: Oh, oh, you'd be surprised. At day job, we've just started truncating the body because people were arranging to get a DSN which contained fraudulent material and then they were replaying the DSN back to people. So people opened it on the basis that they were surprised to be told that a message hadn't been delivered, at which point they were presented with the fraudulent material. And they were doing this at some considerable scale. So DSN people do in open DSNs. In this case, the DSN is valid and correctly reflects what was in the original message, but they could have forged it completely if they had wanted to. Anyway.
Pete Resnick: Bron, go ahead.
Bron Gondwana: Why don't I just pop my sound and my video on instead of trying to type it. I was going to say, even without being able to validate the body part of it, the DSN will still have the full headers which allow you to validate that the headers were correct on it. So yes, people opening DSNs will be less of a problem when they can only go back the path they came.
Pete Resnick: Yep. Okay, so we'll try and summarize this in the minutes and so long as everybody else on the list is agreed then that seems like a reasonable way forward. Okay, thank you. Right.
Richard Clayton: Okay. This slide is about the relationship of DKIM2 with DMARC, which is something that upon good advice we have been keeping very quiet about on the basis that it might become obvious down the line and it didn't seem politically wise to say that this was a DMARC killer or a DMARC major enhancement, and I'm not sure it is. It's kind of parallel with DMARC. Now the simple view which we have been promoting for some time is that a DKIM2 pass is equivalent to a DKIM1 pass. Now various people on the list have expressed the view that... well first of all, there's an obvious issue if there is a recipe which shows that the from line, the RFC 5322 from header field has been changed, there's an obvious issue as to what a DMARC pass actually means in those circumstances. And also some wariness has been expressed by people from large mailbox providers about the amount and type of change which should be allowed. Content analysis is of course always hard, however if you know that only a few lines have been changed, then maybe you can do a better job of it than otherwise, or maybe you'll do a worse job than you do if you have the whole message in your hand when you're thinking about whether or not this is a good message and whether or not the changes are a good thing. So the fact that one can unwind everything and go back and discover that the original message came from the right place and everything aligned may not be quite as exciting as you might think, but many messages are not altered on the way, so fair enough, we can just check the DKIM2 pass. Now Wei today was, yeah, today or yesterday, was posting that he observed that maybe one could refine the definition in DMARC or at least indicate that there were more and straightforward things that you could do, in particular if you insisted that the alignment at the first at the when the message was first created, there was an alignment with the mail from of the original message, which of course is recorded for you in a DKIM2 signature header field, so it's easy to get hold of and check. So you could start by checking that and if that seemed plausible, then you could do the validation of the message and see that you thought the message was fine. So expressing DMARC and making DMARC alignment a little bit more, a little tighter than otherwise might be a good thing. Now I put this on the slide because this I think is definitely an open issue for the working group. I don't think in my view that this is at the moment an open issue for the specification document because unless we need some fancy feature in the base protocol in order to help us out, this is a question of developing DMARC bis-bis or whatever the exotic old language for for three years. The is a matter for the DMARC working group to decide what DMARC means in the world of DKIM2, or alternatively the best practices document which Todd has authored and which is still to be adopted by the working group, then we can punt it and say that all of the discussion of this will end up in there. So from that point of view and in terms of tying down the specification so that implementers feel positive about things, I think this is not an issue we need to deal with short term unless people wish to modify the base protocol for some reason.
Pete Resnick: And I will say from a chair's perspective, I'm thinking that the default is not to touch this in the spec and people should come out and speak if they really want this to have some effect on the base spec and explain why. Bron, is that an old hand or are you in the queue? Bron, it was an old hand. Wei, let's see if your connectivity is good.
Wei Chuang: Yeah, well, we'll put it to test right now as I'm... anyways, we're going pretty fast down some road. So basically, yes, I think I agree, the changing the base protocol is probably unnecessary, but I do think that it is something that we should think about sooner rather than later because there's going to be a lot of people that are going to be looking for DMARC when we start doing DKIM2. Now I don't want to slow down the core specification and just getting everything bootstrapped, but I think it's one of those fast follow-ons and I think there's some value in actually even trying to figure this out on the list now rather than later, but not trying to affect the core specification. And I mean yes, so a lot of my I think, you know, Richard put it pretty well, you know, there's some things we can do to potentially you know, DKIM2 provides a lot of capability to expand what would be considered a DMARC pass. And a lot of the forwarding scenarios that we are worried about for DKIM2, we will also be wanting to look for a DMARC pass and very quickly I think we'll run into the issue: well, what does that mean with DKIM2? We have all of these capabilities with recipes, why don't we use it also for DMARC? And I think that's one reason why we should think about it sooner rather than later. I think we're losing a little bits of you here and there, Wei. All right, I'll hold it there and then I think my thoughts are basically out there.
Pete Resnick: Okay, good enough. Todd, go ahead.
Todd Herr: So a couple of things regarding DMARC. One, I guess at a minimum there might be call to add DKIM2 as an underlying authentication protocol for DMARC if we want to go that route. But I think the fundamental question as to what impact this has on DMARC is going to really come down to: what are the scenarios under which a message would fail DKIM2 that you would still accept it? There's going to come a point, I think, if we succeed in getting this DKIM2 deployed as a protocol, that folks are going to be: if you don't pass DKIM2, you don't get your message accepted. And if that's the case, then I see very little use for DMARC, maybe the reporting, I know I had some conversations about that recently including with our esteemed note taker. Um, but that's I think going to be the core question as to what impact DKIM2 will have on DMARC. And I don't have an answer to that question, so.
Pete Resnick: Yeah. Allen.
Allen Robinson: So I don't think the interesting question is what happens if DKIM2 fails. The question is, if I have a DKIM2 chain that passes and everything is valid, but one of the recipes replaced the entire body, should we still consider that to be good enough for DMARC? And I think a lot of people would say probably not, because that's not the message that that signing entity sent. So there's some ambiguity there on what do you do if you've got a pass with a modified message? Like pass with no modifications or pass with let's say just message metadata in the header changed, like I don't know, something non-visible in a field somewhere. That's probably acceptable. So I think that that's kind of the question that we need to be asking at some point. And to Wei's point, maybe it makes sense to get started on that now, but I don't think anything we're looking at requires us to change anything about the base spec. We know where changes are being made and what they are and DMARC can simply leverage that to make a decision on whether the reject policy should be triggered or not based on the state of a message.
Pete Resnick: Bron, go ahead.
Bron Gondwana: So the difference here I think is between DMARC which is an out-of-band policy mechanism and I don't think we need that with DKIM2 because other than just a policy around messages that don't pass potentially, but for messages that do pass DKIM2 validation, you can flag each individual message with a rule saying: don't modify the body or don't modify anything. And the receivers then look at that advice and say, "The original sender said I don't want this modified and it's been modified, so I'll apply the original sender's wishes here." And that we need that, and whether that's done, whether we have sufficient indications currently in the flags that we allow people to set or whether we need something else there is probably something we want to discuss as part of core, but I don't think you need to do the out-of-band anymore because you can decide on a message-by-message basis whether this is something that requires, must not go through a mailing list that adds footers to it or not.
Pete Resnick: Go ahead, Lori.
Lori Blair: Get myself unmuted as I am like furiously typing. No, I just want to say yeah, don't don't touch my DMARC reports, I'll be a very sad panda. Um, and that also gets used for things like cybersecurity investigations, mapping out botnets and stuff like that. So um, and yeah, as long as we're not touching the DMARC reporting, I heartily agree that this is an interesting question of what to do. I actually agree with Bron, if there's some kind of way that you could flag it as the original sender in a way that says, "Hey, if the message body has been modified, don't actually consider this from me."
Pete Resnick: Yeah, and that says to me at some level, because obviously changes to DMARC are not in our charter, but we can put something into the base spec with flags in anticipation of that use, so. All right, Wei, you're up next.
Wei Chuang: Thanks and hopefully my connection holds. Um, so basically the thing I was going to push back against was saying that DKIM2 will somehow deprecate DMARC. I don't think that's the case. Not only the reporting, I would say that it is trying to say something about who the originator is of the message, which all the authentication protocols otherwise don't really try to do as much. I think there's value in knowing who the originator is or who claims to be the originator and I think the capabilities of DKIM2 to identify who that is through forwarding is actually very useful. The one other thing I wanted to point out is, you know, even if there's a lot of changes in the message, as long as we know who did all the changes, then we have a useful authentication in my opinion. And then yes, so a lot of the... otherwise we have to get into this whole subjective issue of how much change is actually safe and all of that, and that's a very dangerous thing for us I think to try to try to figure out and get some common ground. I think it's far better just to be open and identify who did the changes and then have that feedback on people figure out whether or not this is passed enough based on content analysis and, you know, other safety mechanisms. So I think rather than get into the sort of content police: how much change is safe enough, we should just say we can identify everything and who made the changes and what were the changes.
Pete Resnick: All right, so this sounds like an ongoing open issue that we're going to have to deal with here. Um, and at some point Murray and I are going to have to figure out sort of what the parameters of discussion that are reasonable are and make a proposal to the list about like what the bounds will be and and see if everybody's on board with that. But all right, um, that was useful input.
Richard Clayton: I would point out that there is already a flag that says "Please do not modify it." We could perhaps document it more carefully and doubtless Todd can express whether or not how good an idea it is to set it. Right. Okay. Mailing list software, or at least ancient mailing list software, has the ability to remove attachments. I have been asking on since this came up a couple days ago, I've been asking on the list as to whether or not this is still a thing, and I would point out, which I'm not on the list yet, I just don't think so, that Sympa does not do it. Sympa does have a URL-ize option, whatever that, which is suitably complicated, but whenever I do searches for this, I see lots of people asking Sympa for this functionality and the owners of the Sympa codebase refusing to add it. So, and I am deeply suspicious that people who set up brand new mailing lists and think about these things from scratch in 2026 think that removing attachments makes any sense whatsoever because email is full of attachments these days and people, most people, would be very disappointed if they got removed. So, the question is, the business that mailing lists does this is important because this, though we've been discussing for some time the fact that security devices remove attachments because they remove malware and that sort of thing on the way into systems, and they may remove attachments or indeed add quite a lot of attachments, things like legal disclaimers and so forth on the way out, or they may force your signature to be to have half a dozen little logos in it for Facebook, X, BlueSky and who knows what all added so that people can appreciate your mail in all of its pretty glory. So, but we've consistently been arguing that those things exist at the boundaries of as messages go onto the open internet or come out of the open internet. As a result of which, we can deal with this with null recipes and a... and the fact that you have a contractual relationship with the people who are providing this functionality and therefore you can trust their recipes and if you don't trust them you can sue them. And so we have null recipes for this change is too complicated and either too complicated to describe or it is counterproductive to describe it so I will not. However, if mailing lists are doing this in the middle, then maybe we need to rethink this attitude and we need to better document this. Now the proposal which came to the to the list, I think is flawed and does not work because what they were proposing was that if you removed an attachment, you just documented the hash of the attachment which you had removed, which doesn't allow you to check anything else at all and there's no way to be able to tell in that scenario whether or not the attachment has been removed solely or whether or not the attachment has been removed and everything else had been rewritten to something you might not like. So, however, there is a workable scheme here, which is that the person who generates the mail does not sign the whole body but signs every individual MIME part (if there's no MIME, obviously just signs the whole thing) and then if people remove them, then they basically document they've removed things and people can check that everything which remains is indeed that which the original sender sent. And provided nobody can think of a show-stopping security issue which involves the fact that removing a part causes a completely different message to arrive which you would not like... now there are schemes (obviously, you know, the HTML part and the plain text part of a message alternative were completely different, which often happens), then there are issues there, but at least you've got some sort of... you can remove random icons and that sort of thing without any major difficulty.
Pete Resnick: And you've got a couple of people in the queue here, so.
Richard Clayton: Okay, so I'll stop rambling, but basically the tree of hashes we could do, it's super expensive because many messages have very large numbers of attachments these days. Um, and I think that it's not worth the candle because I don't... because I think these mailing lists are for the ark rather than particularly exciting. I'll stop there.
Pete Resnick: Allen, go ahead.
Allen Robinson: On the second point, Google Workspace supports removing attachments and also supports applying such policies to messages going in and out of mailing lists. Um, and that is certainly ancient code, but also very highly used code. Um, so I don't think this is a thing that that doesn't happen in current systems.
Pete Resnick: Yeah, I, you know, I posted in the chat, I'd love to get some input, and that is a piece of it, from other folks doing mailing lists, not just for implementation of this, but is it getting used? Joseph, go right ahead.
Joseph Teichman: Hi. Um, I'm not sure if what I'm about to say is basically just reiterating what a tree of hashes is, but when you say tree of hashes, you mean that let's say the leaf node hashes the actual text and then the parent nodes would just be hashing... taking a hash of hashes, or are the parent nodes over the leaf nodes also hashing the entire text below it? And I'm just curious like why would that be expensive?
Richard Clayton: Ah, it's expensive because each of the hashes is quite long and if you have 20 attachments, then you have 20 times the amount of hash material. Um, I don't think it necessarily needs to be a tree because I think you can just count the MIME parts from the beginning, one to N, and then just provide N hashes, or N plus one hashes.
Joseph Teichman: Um, I mean, okay, to me I thought that this was sort of an optimal solution to this problem, so. But yeah.
Pete Resnick: I appreciate the input. Bron, go ahead.
Bron Gondwana: One of my early designs on this had hashes tied to MIME part numbers in the way that IMAP numbers MIME parts, which interestingly seems to be an IMAP-specific thing, it's not specified outside of IMAP, but it is reasonably sane and easy to follow. And so you would hash each MIME part, I was hashing the binary decoded version of the body which allowed it to be re-encoded without breaking the hash because generally it's base64 encoded, but some things are quoted-printable and all sorts of horror shows. And that's relatively easy, but it does involve having a MIME part calculator and it allows MIME parts to be renumbered while still being able to detect that a part has not changed because it has the same hash and allows you to tell that an attachment has not been modified, for example, even if the body has in a way that's unrecoverable, you could still tell that the attachment wasn't changed from the original sender and there might be some value in that, but it is, I agree, it's more complex and easier to get wrong.
Pete Resnick: I'm not hearing precisely: out it goes, we have absolutely no reason to think that this is anything, but I hear the trepidation. So this one I would mark as needs more input. So I would ask folks if you would gather together mailing list people who are aware of how mailing lists are used and see if this is a pretty common thing. I'm also worried that there might be other scenarios that are not sort of end-of-the-line security appliances that might do this sort of thing, but I'm not sure. I agree, it would make recipes more complex, it would certainly make them in the long run much more straightforward to manipulate in predictable ways. Allen, go ahead.
Allen Robinson: I think alumni forwarders are another case that's maybe in need of this for better or worse. Certain educational institutions have decided to do forwarding and as part of that also do virus scanning or whatever and then they remove attachments, but then the messages get marked as spam because they no longer pass authentication checks. Um, so that's another scenario on top of mailing lists. I mean I guess it's kind of like a mailing list with one subscriber, but uh, so I don't think this is a thing that doesn't happen.
Pete Resnick: Sorry, I was just chuckling at John Levine's comment in the room. Um, but yeah, no, I agree, it's the other main use case for entity in the middle that's being helpful. So. All right. My my feeling at this point is let's keep it in the back pocket as a possibility, queue this up for additional discussion, because if we do think it's a valid use case and we're going to want to address it, maybe we bite the bullet. I'm not saying we're going that way, but I think it needs to be discussed.
Richard Clayton: Okay. Um, what I would say first of all is I think if a message contains malware, then sending the message without the malware seems to me a waste of time because it's probably not a valid message. People don't add malware onto real messages, they haven't done that for 20 years. And secondly, um, when we ask people: does your mailing list do this? then we need to phrase it in such a way that: yes, just because you ticked this box in 2001 doesn't mean that that would be a sensible thing for anybody else to tick and you could untick it and the world, the sky would not fall and we would not have to spend a fortune on hashing things in DKIM2.
Pete Resnick: I'm going to ask the IETF people because I have a suspicion that the place this might get used is: remove big things. Right, so I don't know if Mailman has a size parameter for the option. Oh yeah, Mailman has all sorts of fancy things. Right. So the purpose might be: look, we do not want big giant ridiculous things sent to you know, whatever IETF list. I want to see if that's being used for any of like announce or those kind of lists, um, and check around, because you know I agree, if it's malware, that's really usually an end security appliance responsibility, but if it's: we don't want big giant things sent to the list, that I could see people maybe using regularly.
Richard Clayton: Well, again, if I send you a message saying: "Here are the slides," and I put a 10 megabyte attachment on it, and you get the message saying: "Here are the slides," it's probably more useful to tell me that my message is too big and is not accepted rather than to deliver you the text, but.
John Levine: This is John. My recollection is that if the message is too big, it may be bounced or it may be held, but I agree with Richard that stripping off part of the message and passing the rest of it through is so 20th century.
Richard Clayton: Okay, anyway, um, we're not going to decide this today, so let's let's move on. Okay. Right. This one. We have had a discussion of which headers are to be signed at every in-person event we've ever had held on DKIM. There has been almost nothing on this topic on the list. And I draw a conclusion from that. Just to remind people, the 01 spec says that you sign everything apart from some trace headers, some some other alternative validation systems so that you can do those in any order you wish, and also X-hyphen headers are ignored. This is very simple to understand, it is clear and safe, but people say, "If for the first time in 50 years we invent a new trace header, then it would be a bit of a nuisance the fact that we have to sign it, because it would not be excluded." One might decide that X-hyphen-Trace might be a good name for such a header, but there you go. So anyway, that's what the spec says and people have implemented against that and it all seems to be fine. Some people want to sign absolutely everything, including for example the Received header fields. This will slow... this will cause anybody who forwards things between systems using SMTP where nothing is done to the message at all apart from the fact that it's moved from one place to another and a Received header field is added in order to record that as happened, then all of those people would have to deploy DKIM2 absolutely everywhere, which makes a very simple forwarder rather more heavyweight, so that is not... not a brilliant idea in my view. And then some people want the sender choice that we had in DKIM1, which the authors of the spec here decided that we would remove because it is impossible for you to know what security properties any particular header might have at the destination and we have ample evidence of people not signing or oversigning things which actually seriously matter. A variant of this which Bron has floated from time to time is to have some sort of choice of exclusions. I'm hard... I'm struggling to see how this might work because if you were to announce that you were excluding signing from, what would people make of that? Also, if you said that you were excluding something, then what if somebody further along the chain wanted to sign it after all? How... what the syntax for this is all really very, very messy and I can't get excited about this at all. And that is hopefully we can have a fairly short discussion of this and maybe we might come to a conclusion at some point. Bron, you want to go ahead.
Bron Gondwana: Yeah, I think Authentication-Results is almost a trace header. Everything else seems fine, but Authentication-Results is weird and wacky. A lot of people add it in as part of their mail inbound or outbound flow in weird places. Well, inbound flow. And so it means you need to put the DKIM2 validation before you add an Authentication-Results header, which makes sense, but if you have multiple things that are adding Authentication-Results headers because they're checking just other things, then you need to make sure that you do the DKIM2 on both sides of it because otherwise you will either break your validation or you'll break the next person's validation. And so it's sort of Tracy and you don't necessarily want to trust what someone added earlier anyway because you don't have access to their checks and you do your own checks, so I think discussing whether Authentication-Results belongs in trace is worthwhile.
Richard Clayton: Yes, it is a key aspect of Authentication-Results, which is that they are by definition meaningful only to the person who added them and to nobody else. Now, a lot of people seem to use other people's Authentication header fields and draw conclusions from these. They are in a state of sin and should not be doing this.
Bron Gondwana: People also use Received headers and draw conclusions from them, they're in the same state.
Richard Clayton: Yes, but well, you can draw the conclusions on the basis that you're doing a forensic examination in order to produce an expert report for your for for a court case or something, but using it in order to decide where to deliver mail is not widely deployed and super expensive and it'll go wrong left, right, and center. I'm perfect... apart from the fact that people seem to dislike the notion of all but and then say but the list is getting longer and longer, I think there is a reasonable case for saying that Authentication-Results are in fact an authentication system like ARC and DKIM1 and that therefore people should be able to add them before or after any without interacting with DKIM2 activity and doing it in any order they want. And arguably Authentication-Results might stop being as interesting to people going forward because the DKIM2 chain of custody tells you really rather more about what has happened to the message in a way which is actually useful to you.
Pete Resnick: So, let me make the following proposal from the chair and see how it goes down, because I think you're right, there has not been sufficient discussion of this on the list for me to pin it down on the list, which is a problem. But I am no longer hearing people jump up and scream (correct me if I'm wrong) that they want to go more toward the sender choice model, that the real argument is about what ought to or ought not be accepted from the list. Does anybody in the room want to argue against that as a base position? Because maybe what... Allen, go ahead.
Allen Robinson: Another option that's not listed here is that we have some mechanism by which senders can choose to add additional fields to the signature if for whatever reason one wanted to have some authentication coverage for an X-field starting with X. The protocol as it is now does not allow, does not have a way for you to do that. And sure, there are probably other ways that aren't just cover it in a DKIM2 signature that could be used to retain some amount of authentication information, but that means inventing a new thing in every site that cares about this, where having a mostly unused something like H equals that says to actually, yeah, like check those even though you normally wouldn't and have them just feed into the the algorithm, maybe is lightweight enough that it would be worth having.
Pete Resnick: Right, so that would be all-except list plus, you know, sender specified. And I'll take that as a friendly amendment to the notion that what I might propose to the list is: okay, we're hearing that people are leaning toward all-except list, and there's this other possibility that you could do this extension mechanism to add on some of your favorite ones. That may or may not be interoperable, but okay, yeah, as a possibility. Richard, I presume you are not standing up to say "No, no, I think we should switch it all around and not do the exception case."
Richard Clayton: I'm just going to say that if you said H=Received, then you could probably mess things up considerably.
Pete Resnick: That's what popped into my head, is not likely to be terribly interoperable, although might cause some, you know, fun for certain implementations.
Richard Clayton: Yeah, um, but but equally I'm wondering about these sites which are in a position to implement DKIM2 to add the extra H= for one of their favorite X-hyphen headers, which by definition are not meaningful anywhere else apart from on their platform, why can't they just change their codebase to change the X-hyphen into a Y-hyphen and just move on.
Allen Robinson: So as a mailbox provider that has all sorts of strange and exciting customers, um, there are certainly cases where the field is not meaningful to me as the mailbox provider, but it is meaningful in the interaction between one of the users of my platform and some system outside of my control that is producing those fields.
Pete Resnick: Yeah, the classic case I think that I've brought up before is some wiseass tried to implement X-dash-sender because they wanted something hidden, and then other people elsewhere on the internet decided that that was a really good idea and it became meaningful. And so everybody shared in the joy of X-dash-sender, which resulted in X-dash-X-dash-sender, um, to try and further hide it away in some hidden way. And I think the the result is that there are some X-dash headers that leak and not by fault of the person who originally proposed it or was using it end up being something vaguely useful. And in this case, is that likely to ever happen? I hope not. Um, but maybe giving that out allows for the possibility that you know, things might, you know, might be tickable in the future as: you know, I've gone and signed this. I'm still not hearing anyone stand up to defend: no, we shouldn't use the all-but rule, plus or minus some other stuff. So I may propose that to the list of: the chairs have failed to hear anyone stand up for other than the exception, so let's start on that and argue about whether there needs to be an extension rule the way Allen described, whether there needs to be a change to the list that is currently accepted that is in the document. Does that seem reasonable, or I should say does that seem unreasonable to anybody? All right, let's plan on that for the time being.
Richard Clayton: Okay, I have now finished all my slides.
Pete Resnick: Lovely. All right, so we are moving on to the other docs question. Um, Wei, I can... if you still have reasonable voice connectivity, I can go and present the slides and you can just yell "next" or would you prefer Allen jump in and do them?
Wei Chuang: Uh, I think I've better connectivity now. That would work for me if we just do the next and but if I happen to drop out, yeah, I mean please jump in.
Pete Resnick: Okay, so let me go ahead and share yours. So your slides are now up. DKIM - Chuang
Wei Chuang: All right, next. Okay, so I started putting together a draft basically to pull in the DNS policy from the DKIM1 RFC, and then basically just pull out the parts pertaining to the DNS policy. And then, you know, the idea was, um, you know, we were going to have a separate draft that's separate from the base specification that would just really be about the DKIM1 parts, which is a DNS policy. And but we would want to make some updates. Um, and those updates are going to, you know, be things like, you know, updating the algorithms to include the Edwards 25519 algorithm. We also have an opportunity to remove some of the unused or very weakly used components in the policy mechanism. Some of the key values, um, you know, basically are, you know, not really used or even problematic. Um, there's also some commentary on things like, you know, hex-octet formatting, and then clean that out of the specification. So this is just trying to take advantage of the opportunity to clean up some of those policy mechanisms so that DKIM2 won't have some of the things that are legacy, not very well specified, and could cause confusion. Should we take questions now or do we wait till the end?
Pete Resnick: Todd, why don't you go ahead and jump in if you've got something specifically on that.
Todd Herr: I'm confused by your use of the word policy in regards to DNS and DKIM. Can you elaborate on what you mean by that, please?
Wei Chuang: I meant inside the DKIM specification there is going to be documentation about the DNS record policy mechanism that DKIM uses. And this document is largely pertaining to that. And so sorry if my bullets... I mean, I wrote this very quickly like late at night, so maybe this is not the most wordsmith-like set of slides, apologies for that. Does that help clarify or do you want more?
Todd Herr: No, I'm still not clear because I don't... like where would I find a policy related to DKIM in a DNS record for DKIM?
Richard Clayton: It recommends hashes in some places.
Todd Herr: So are we talking... I don't understand the use of the word policy here, maybe I'm just not getting the context of the use of the word policy here, maybe I'm just.
Pete Resnick: I think it's that the document provides the policy for what goes in the DKIM record, correct, or in the DNS record?
Wei Chuang: Yes, that's correct.
Pete Resnick: It's not a DNS policy, it's a policy for putting things in the DNS in a particular way.
Wei Chuang: Here I'm trying to say this is the DNS record. Um, and I pulled in, this is probably language from elsewhere really and again, writing something late at night, not thinking too clearly, and I guess I probably should have been adhering more to the RFC language.
Pete Resnick: Lori, go ahead.
Lori Blair: So basically this is a document just talking about like how to format your record for DKIM2. Like what a valid DKIM2 record construction would look like versus an invalid. Is that what you're talking about, Wei?
Wei Chuang: Correct. Yes, yes.
Pete Resnick: All right. And am I correct, Wei, that the hope is the hope has always been that DKIM records would be mostly reusable for DKIM2 and so this would be any additional extensions that might be needed or desired?
Wei Chuang: Right. And more than that, it should be very minimal. This what changes there are is just to remove the things that have very little usage that could potentially be confusing to a DKIM2 implementer who would most likely not be using that anyways. Um, and if there is a conflict and we'll talk about this in a moment, in some sense, it would be to essentially ignore such language. And, you know, the changes call out that. And I'll explain in a moment. All right, next. Lori, did you have something else or you just accidentally unmuted?
Lori Blair: Oh, accidental.
Pete Resnick: No problem. Richard. Is that an old hand? I'm going to assume that's an old hand.
Richard Clayton: Sorry about that. I didn't press enough buttons. If you... the intent absolutely is that if you have a valid DKIM1 DNS record, then that will be a working valid DKIM record without any changes. However, if you have various exotic fields in your DNS in your existing thing, then DKIM2 is going to ignore them, whereas it might affect the behavior of your DKIM1 implementation. So what... so since most of these things are either unused, seemed like a good idea at the time N years ago, or are basically completely unnecessary and don't actually do anything useful, then the notion is to deprecate those fields so that people making new DNS records can make something which will work with DKIM2 and will not produce any surprises and that will also work with DKIM1. However, what we didn't want to do was just drag in the definition of the DKIM1 records from the DKIM1 specification because then we'd have had to write a lot of very complicated text about what to deprecate, etc. So what Wei's document does is to make this something very tidy which doesn't change anything for anybody but makes it very clear what fields are are not going to make any difference to DKIM2, which is probably what Wei's going to say on the next slide anyway.
Pete Resnick: And let's go to that next slide. Next, please. Yep, I'll do that. John, did you want to jump in or?
John Levine: I can wait for the next slide.
Pete Resnick: Okay, go ahead.
Wei Chuang: Okay, so I mean, more specifically about some of the changes. Um, so there's a set of DNS record, you know, key value, tag value, sorry, basically are very much unused or even potentially confusing, and the goal here is not to reject these or anything, it would just simply be to be ignored, which is already in the DKIM1 draft anyways. It's just saying that for these tags, they are not meaningful for DKIM2. So for example, there's three here so far that have been retired: basically the first one is the hash algorithm, you know, this is part of the algorithm that's subsumed into the key type algorithm; there's the notes and you know notes are for the most part ignored anyways, but it's just saying that for DKIM2 is not really going to be meaningful; and then the service type which, you know, DKIM2 is not going to support other uses than email and it's just reaffirming that in the specification and just saying that it is essentially retired, it will be ignored. There is one other set that potentially we should consider, but I guess there is a bit more usage, um, and that is the flags. And then so for the flags, there's one for testing. Um, so we've seen that when the testing flag is used, a lot of senders seem to be... there's a misconfiguration. They probably did not mean to use their DKIM record for actual production code, I mean production emails, sorry. And then basically that, you know, mismatches what the RFC says (I mean, which is to ignore it) and we should say something about this in DKIM2 which is basically T=Y seems like this is causing a certain degree of confusion and misconfiguration out there and we should retire this with respect to DKIM2. But again, this seems to be there is a bit more usage, a lot of it looks like it's actually due to misconfiguration. And then this is something that maybe we might need to discuss. Then there's also this T=S for alignment between the I= and the D= tag. This seems to be not used but here there's perhaps less... I mean, maybe I just don't know how it's supposed to be used and we, to be honest, we don't really check for it. But that's our belief at least. So that's this is another candidate that, you know, an overall then, you know, the T= flags tag is something that seems like it also ought to be retired. And then maybe, I guess, John?
John Levine: Yeah, I'm actually, I am in complete agreement with this. I mean, I would cavil about the N= except that the current definition of the N= tag says it's ignored and your proposed one says that it's ignored because you don't because you don't know what it means, so that doesn't matter. And there's a bunch... the only practical difference that getting rid of these is going to make is that back in the day we had grand plans that we were going to DKIM sign, you know, like SIP headers and stuff like that, so that someone might put in S=service type other than email, which should make things ignore it, but in fact if you don't ignore it, then you're not going to... there's not going to be anything that it matches so that it's not going to validate anything, so. I'm saying that I can imagine some obscure failure modes but they're all harmless. So I think this is fine. You know, and in fact the only thing I would change is in your document like there's some stuff about XML that I would take out because that didn't make much sense in the first place.
Wei Chuang: Okay, thanks. I'll look for it.
John Levine: And of course I am the one person who actually uses N=, but like I said, I don't care because it's ignored anyway.
Pete Resnick: All right. Okay, and I think next slide unless there's any others. So basically at this point, just call for adoption as a working group draft.
Wei Chuang: So, I mean, this seems straightforwardly in our charter. Um, are folks concerned about doing this work, or folks concerned about the timing, like we should put this off or or, you know, hold it in abeyance? I mean, otherwise I'm happy to just put out a call for adoption if it seems uncontroversial in the room. Richard.
Richard Clayton: I'd like to see it adopted and sooner rather than later because there's a PR issue here in terms of: if this came along fairly late on, people might get confused and think that we were making them change key, whereas the whole point is you don't have to change key, all we're doing is saying that if you've got these funny fields in here, then the DKIM2 spec says that they're ignored and this document says don't put them there in the first place unless you particularly want the effect that they will have on DKIM1, which is probably problematic anyway.
Pete Resnick: Yep. That seems pretty reasonable to me. Um, and quite a few plus-ones in the in the chat. All right. I mean, this seems relatively uncontroversial to bring on board at this time. Um, I'll go ahead and scrape together a call for adoption on that one and we'll go forward from there. Easy enough. Thank you, Wei, appreciate it.
Wei Chuang: Thank you.
Pete Resnick: Um, taking a look at our list in the data tracker, there are only three other documents in our related list. Um, the two counter-proposal documents, the one from Latimer and the one from Vittorio. Um, and you know we already talked about Vittorio's and Murray and I are going to talk to see if we want to bring a discussion of Latimer to the list or not. Um, and and maybe talk to Latimer about that. Um, the only other one is Todd's document. Todd, do you want to talk to whether that should (and I can stop sharing) whether that should be adopted now or otherwise?
Todd Herr: I mean, it's it's far from comprehensive on what use cases there might be to document with an BCP or an applicability statement, but certainly I think the intent should be to get it adopted by the group. Um, timing... I mean it may be best to get it into the group sooner rather than later just simply so we can start dealing with some of these questions like we were talking about earlier, you know, whither DMARC... and that sort of thing. So yeah, I'm in favor of adopting it.
Pete Resnick: Okay, because you know, I am, I should say, one who is not a big fan of the formal adoption meme. Um, you know, if we're going to work on it and even if it is currently just a dumping ground document for: "Hey, we should say something about this in in a use case document or in a, you know, how-to-deploy document," and you want to be the penholder on that, I'm comfortable with it. Um, if there are folks...
Todd Herr: I'm fine with that role. In fact, that was what I had envisioned as the next rev of the document would be my surveying folks and saying, "What cases haven't we talked about yet? Don't worry so much about the specific of the text, just tell me what cases we need to put in here and let's start dumping ground stuff." and then I'll hold the pen and format it and given my track record, I can eventually submit it to the RFC editors and then it'll never be heard from again.
Pete Resnick: Right. No, I think that's reasonable. Um, yeah. I mean, my feeling is unless I hear from the working group people saying bringing this on is either not going to follow what we're planning to do anyway or is somehow going to interfere with us getting other work done, I'm happy to bring it on as working group document. Bron, go ahead.
Bron Gondwana: Yeah, I was going to to add to that. It's clear we need a document like this as part of a final version of DKIM2. We can't really just publish the spec without implementation guidance, and so we're going to need it. And there's been enough discussion of things that are more implementation guidance than spec. Both discussion and some of the other proposal drafts that have come up have included both things, and so being able to say that belongs on this document, give feedback on that one, seems like a good way to split them up. So I think having it as an adopted document makes sense because then it's easier to say this stuff is related to that one, not to the not to the mechanics of operating it but the how it should be used in the world.
Pete Resnick: Richard, go ahead.
Richard Clayton: Yes, I'm I'm in favor of adopting this. The... and we do need it because what people may not have realized, because it's hard to tell what is not there rather than what is there, um, as I went through creating the DKIM2 spec, I removed quite a lot of text which Dave Crocker wrote long ago, which is perfectly valid and so forth and full of good advice and warnings as to what you could do wrong and so forth, but which I felt did not belong in a specification document but does belong in a document which helps which hopes to guide people towards producing an interoperable version sooner rather than later. So that text, which can obviously be discovered by suitable suitably fancy diffs and so forth, belongs in Todd's document if it isn't there already. And therefore, and as people come along and identify things which are confusing about the spec and the response of the working group is, "Well actually the spec is entirely clear, this is just all in your mind," that's exactly the right sort of thing to put into the into Todd's document. And therefore if it was a working adopted working group document, then that would be far more obvious to people that that was a good solution to shutting down the thread of their discussion rather than sort of punting it and saying, "Well, Todd will get around to it eventually, honestly," which sounds a bit thin.
Pete Resnick: No, good enough. I I like useful tools. Um, okay. So for both Wei's document and Todd's document, I will chat with Murray and hopefully we'll get calls for adoption, we can have that discussion and, you know, and as always, although you know, I'm always glad to take on co-editors who are willing to volunteer for such things and make them stuckies so that either of our authors do not have to do all the work by themselves, but we can get there. Um, good. So Alex mentioned in the chat... I had to go into the dusty corners of my brain to figure out the appropriate regex to make his document not appear on our list. Um, but um, because it's now being... it's been adopted by MailExt. Alex, do you want to talk about that?
Alex Brotman: It's it's a document that allows for mailbox providers to give senders data about placement and recipient reactions, I guess. Um, and so it's keyed off of the DKIM signature. So I think it would also be keyed off of a DKIM2 signature, um, but it's not specifically related to DKIM1 or DKIM2, sorry. Um, but it was something I tried to take it to MailExt and John kind of pushed me over to DKIM, which is fine, I don't really necessarily mind, I just thought it was... I don't know where it really belongs. But if you if you don't think there's time or space in the DKIM I can go back to MailExt, I guess. I don't know.
Pete Resnick: I mean, I understand the problem. Um, it's certainly not in our charter right now, I don't believe. Um, and I think MailExt may be the easier way to go. Um, is the issue simply that MailExt is resource-locked at the moment? Because I know for a period of time they said "We're not taking any more extensions until we you know clear off some of these."
Alex Brotman: Yeah, I think they're I think they're at their max of 10, which is fine. I'm not I'm not necessarily trying to push Ken or Murray to take more things. I'm just more curious of where the proper place would be. And it's again, it sounds like MailExt, but like again, John was like, "No, I think maybe it belongs over in DKIM." I you know, so I just want to know who to harass later.
Pete Resnick: John, you want to talk about why you think maybe we should take it on?
John Levine: Because it's about... because it's I mean the... again, one one more way to swap in dusty things from the from the cardboard boxes in the back corner of my brain. Um, no, this is this is about publishing what... let's see, this is you're basically you're using... it's formalizing what what Yahoo does. It's using your DKIM signature as a handle to send reports about what they think about your mail. Specifically it's not about DKIM failures, it's about, you know, feedback reports and stuff. You know, and since.
Alex Brotman: No, that's that's something else, John. That's the DKIM FBL. This is this is more... it's a JSON body that is an aggregate look at how traffic appears over a day instead of the individual FBLs. So it would say like, if if you whoever send 10,000 messages, but like 7,000 go to the inbox and 3,000 go to the spam folder, or and then there's another stanza in there where: "Hey, of those 7,000, you know, a thousand of those generated complaints," or or ENs or FPs, whatever the number may be. Uh, so that's those two different things. But the DKIM FBL is potentially another thing for the DKIM working group or again for the MailExt group.
John Levine: But do I correctly remember that it still uses it still uses the the signature domain as the handle?
Alex Brotman: Correct, they both do, yes.
John Levine: Yeah, basically, I mean, they're DKIM because they use... yeah, basically because they use the DKIM signature as the identifier to say where to send the reports. You know, and I take... like everybody else, like MailExt wouldn't necessarily be wrong. On the other hand, you know, if it's if it's keying off of DKIM reports, also it's not implausible that the reporting destination might be new fields in the key record, so it would go in Wei's document.
Pete Resnick: Richard, what are you... what are your thoughts?
Richard Clayton: We do have a flag in DKIM2 saying feedback requested, uh, so that it is clear which of the DKIM signatures feedback it should be supplied to. So that's kind of the first issue. So from the point of view of asking for feedback, um, then we've actually built that in on a per-message basis rather than the current Yahoo scheme whereby you come and you ask for ourselves and then you get added to a list and then we will provide you with feedback. The actual format of what the feedback looks like, obviously it's helpful all round if that is specified, and I suppose you might be able to stretch the charter on the basis that that Todd's document explained when you wanted to do this and Todd's document said it would be a really good idea if you use the standard format for doing these reports, "Here, look over here at this RFC." Um, so or we could adjust the charter or whatever, um, or Alex's document could sit outside of any working group and just be referred to because there's obviously good things about having a standard reporting format and tying that down really carefully because then people might actually be able to machine-process this stuff. But the asking for bit, um, that's built into DKIM2 already.
Alex Brotman: The one thing about the spec is that the spec allows you to send it anywhere instead of to the original sender. I don't remember if DKIM2 allows that, I don't think it does. So like if you if I were sending a message from Comcast to Yahoo and I wanted to send the feedback to Pete, then I could choose to do that.
Richard Clayton: We're a little bit vague in we say where that feedback goes and what it looks like is not in this document. That's all we say about that. Uh, so it could you could arrange it somewhere else. Frankly, in the real world, you are still going to have to go and ask for ourselves to be able to get it because we are not going to provide this feedback to spammers. Right. We're happy to give it to Comcast, we're not happy to give it to aardvarkhealthbills-limited.com.
Alex Brotman: That's a real place.
Pete Resnick: So I don't know if that really answers my question. Yeah, I you know, it's clear as mud but it covered the ground. Um, uh, I don't have a good answer for you, and perhaps you want to you know, just do a quick post to the list and I mean I can reach out to I can reach out to Murray and Ken too and say like... yeah, and as a matter of fact, start with Murray since he, you know, stupidly is chairing both groups. Um, and see if he's got an inkling one way or the other because I I'm afraid that this is going to take a little either uh well either a charter change or interesting charter interpretation to get in here. So. Sure, that's fine. I can email Murray and go from there. Sure. Sounds good. Thank you, everybody. Yeah, thanks. Um, any other documents that folks want to chit-chat about? We've got a half hour officially left. Any other business that people want to talk about? I don't think I have to ask whether people want the half hour back, so um. Going once, going twice. Sold. Um, thank you all. Thank you especially Lori for taking some notes for us. Uh your dead fingers are much appreciated and those are very useful. And uh Murray and I will get back to you with results of this meeting and we'll get some minutes posted to the list and uh so you know a question about when we should do our next interim, maybe in the month of May would be lovely and we'll go from there. All right, thank you all. Good to see everyone. Bye-bye. Bye.