**Session Date/Time:** 24 Jul 2026 12:00

[00:00:06] **Pete Resnick**: We're being transcribed as we're kibbitzing about what we had for dinner last night.

[00:00:11] **Bron Gondwana**: Yeah. Yeah.

[00:00:11] **Murray Kucherawy**: And when's the last time I had liver?

[00:00:13] **Bron Gondwana**: Everything he said, yeah, I said, yeah. Doesn't know

[00:00:16] **Pete Resnick**: how to spell.

[00:00:17] **Murray Kucherawy**: Alright. It's 02:00. Let's get going. We have a fairly full agenda today. I'm Murray. This is Pete. We are the chairs, and welcome to DKIM at IETF 118. Please note, if you have not seen this yet this week, that would be incredible. But please note the Note Well. As Barry likes to say, this slide covers intellectual property rights and obligations. Excuse me. This slide contains links to two documents that describe the processes that we follow in the IETF, guidelines for counter conduct, anti harassment procedures, privacy statements. This is all stuff you agree to implicitly by coming in the room or joining our mailing lists. Please make sure you're familiar with all of it. If you have any questions, please see the chairs or our work area director in the back there.

[00:01:01] **Pete Resnick**: Could someone close the door

[00:01:02] **John Levine**: while we're

[00:01:03] **Murray Kucherawy**: Meeting tips. Quick reminders. Please be sure to sign in to some one of the tools so that you can be counted as attending. It helps us plan meeting rooms in the future. You should be using the MeetEco Lite client to join the queue and show hands if you're in the room. In any event, please keep your audio and video off when you're not using them. And if you're at home, a headset is strongly recommended. Although the we're be managing the queue, please make sure you say your name when you begin speaking at a microphone. A few quick resource links for IETF 118 in Vienna generally, the main agenda, how to prepare for a meeting, and how to report issues. These these slides are in the chair slides. I know you don't have to you can't really click these screens, but you can get at this PDF from online. The agenda will be falling here. Are there any hacks hacks? Are there any bashes for the agenda?

[00:01:51] **Pete Resnick**: We already added one. Yep. The Bron's trace stuff at the bottom is new. Anybody else have anything? John mentioned that he might wanna talk about the other sort of feedback, in AOB.

[00:02:05] **Murray Kucherawy**: Yep. And I think that we'll probably get to AOB with little more than five minutes.

[00:02:08] **Pete Resnick**: I think so too.

[00:02:10] **Murray Kucherawy**: If not, we'll get rolling. Let's do a hackathon report. Ron probably has stuff to say, and it sounds like Mauro does too.

[00:02:20] **Bron Gondwana**: This is Bron without having put my name in the queue. That's alright.

[00:02:23] **Murray Kucherawy**: I called your name.

[00:02:23] **Bron Gondwana**: I didn't actually do much at the hackathon on DKIM2, unfortunately. I was sidetracked by work work things. But I've been doing a lot of development in the the previous time leading up to this. And so I discovered that received SPF was an issue on my testing systems as a header that's being added by systems. Other than that, I have worked in implementations in a bunch of languages. I have a couple of mailing list tools that can do DKIM2 on the way through, and it's all working pretty nicely. So I have created a weekly meeting where I'm going to be spending an hour messing around with DKIM2, and anyone who's available to join in can hop in the the Zoom room that I've created for it, hang out with me, test things. It'd be great to do a couple of rounds of of cross testing with other people in real time.

[00:03:15] **Pete Resnick**: And that link is in the email that Bron just sent to the list?

[00:03:18] **Bron Gondwana**: Sent that email to the list.

[00:03:20] **Pete Resnick**: And, Mauro, did you wanna talk about what you put together?

[00:03:31] **Mauro Escalante**: Hi, Mauro Escalante. Well, I implemented the DKIM2 in mail-auth, which is a Rust library and also a Stalwart mail server. And I also created a a Docker container, which is a test matrix with between all known DKIM2 implementations. Bron's, also Steve's Go implementation, and another one, Phoenix, all the ones I could find on the list. And this Docker container is a cross test. It's a multi hop implementation, so it makes a message pass through all the four implementations and verify, sign, yeah, all the do all the the show. So the only problem I found was due to the message folding, but it's a minor issue to be fixed. And the idea is to move these Docker containers written using test containers to the official repository so so other implementers can add their libraries there. Yeah. That's it. Cool.

[00:04:36] **Murray Kucherawy**: Anything else on hacking or interrupting or other good things like this? Okay. We can go. We are amazingly eleven minutes ahead of schedule. We can move on to Richard's slide deck. Let me get that up here, and I'll pass control to you, Richard.

[00:05:00] **Richard Clayton**: Right.

[00:05:01] **Murray Kucherawy**: You have slide control.

[00:05:03] **Richard Clayton**: Okay. Thank you. Okay. This is the issues which required some discussion and some consensus arriving at. And though, of course, consensus is on the mailing list, having a discussion here is obviously going to be extremely helpful. So first thing is this is more to draw people's attention to it as much as the fact it's contentious because some people might think it is extremely contentious and get terribly upset down the line. So we're trying to flag it up as as much as possible for everybody. Now you will recall from your deep knowledge of the DKIM2 proposal that delivery status notifications bounces are sent back along the forward path. And that means that if the forward path went through the same system more than once, which is the sort of thing that happens to email, when it gets rewritten and so forth. So it may may be sort of internal. Exim does this sort of thing all the time in order to get all sorts of wonderful effects. It pushes it through Exim more than once. If you've gone through a complicated path like this where it's gone through the same system more than once and you get a bounce, you get one of these DSNs coming back to you, you might struggle to work out whether or not if the DSN is for you handling it on hop seven or for you handling it on hop three. So in order to address this and much simplify things, we said that what we would require was that when you generated a DSN, you have to generate a DSN for the message as it had arrived to you, perhaps in the distant past. But when the message arrived to you, you're gonna produce a bounce for that. And, therefore, you're strip out of the third section of the DSN. You're gonna strip out all the headers, all the header fields which apply to the message after it left you going forward from you. This is all just just fine and simple and easy to explain. However, if you are trying to undo use recipes in order to reconstruct what the message looked like on the outward path and you had added a and there was a null recipe there, you might struggle to get that right because null recipe says, I'm not telling you what happened. Now when we thought about this, we couldn't see any use case for null recipes for header fields. There's lots of use cases for null recipes for bodies. We don't need to discuss that now. But for header fields, we couldn't actually think of a use case. If if you you but the only thing you could possibly suggest was that perhaps, you know, there's malware in some header fields, and you wouldn't strip out the malware and still pass the message on. We think that's insane. Why would you want to pass the message on rather than saying, do not sell me malware? So, basically, we can't think of any reason for a null recipe. So the spec now says must not in that space or or it doesn't actually say must not. It's actually remove the possibility of having a null recipe. So if there's a use case for null recipes for header fields, the trick is to speak up sooner rather than later, and then we will try and work out how to make DSNs work.

[00:08:46] **Pete Resnick**: So I would really like to see someone stand up and say, I've got something to use this for, or at least some heads bobbing up and down in the room to indicate that this seems fine. This seems fine. John, do you have any concerns or were you just putting down your laptop? Yeah. Get up to the mic if you're gonna do it. I

[00:09:24] **John Levine**: think this seems fine. And in the worst case, if you can't reconstruct the body, you can just send back a DSN with the header assist, which is what happened

[00:09:30] **Pete Resnick**: Mhmm.

[00:09:30] **John Levine**: Which is what often happens anyway.

[00:09:34] **Richard Clayton**: This is entirely to do with the headers. It's nothing to do with the body. Your if you can't reconstruct the body, you're then going to have to strip out what the body was in order to make all of the things work, and there's discussion of that. Bodies and no recipes not not affected by this at all. Okay. Right. Everybody's happy with this. That's We told everybody. So if people scream down the line that there's a use case for this

[00:10:03] **Pete Resnick**: And and the change is already in the current rev of the document. Correct?

[00:10:07] **Richard Clayton**: It yeah. It's it's in spec -04. It's on the open issues because there wasn't very much, if any, on the list discussion. This came out of interworking experiments. The Okay. The fact that we needed to do this.

[00:10:21] **Pete Resnick**: The room seems happy. Let's plan on that unless we hear screams on the list.

[00:10:28] **Richard Clayton**: Okay. Now, when I wrote the spec, I managed to put in some must nots to do with generating message instance header field when you didn't need to do so. Right? Recall that message instances describe the, the state of the of the message at the point at which you you're handling it. And if you change the message, you need a new message instance. If you don't change the message, you do not need a new message instance header field. And so I had written some text which basically was telling people not to make them. And it turned out from the interworking experiments that there were people in this world who noticed somebody was making a message instance when they didn't need to, and somebody else was actually bouncing the message and saying, no. This is not a legal DKIM2 message because you have a message instance with no recipes in it. So there's no change to the to the message. So, there was some discussion on the list of this, and, Pete, I think, was pointed out that that a must not was not appropriate for something which was nothing to do with making things work working. It basically, the reason that we were discouraging extra message instances, which weren't necessary, was because every time you put one in, then a machine has to do some work, and all the machines further along have to check that check that work and recalculate the hashes and so forth. And this just heats up the planet, and we don't like doing that. And it takes time and latency and that sort of thing, so we'd rather not do it. So the suggestion is that for the next version of the specification, we should change the must not into something saying do not heat up the planet. And this covers a rather exotic case, which I'm not sure is totally real, where you change the message instance header not because you have a recipe, but because you want to use some different hashes. But so that is all very exotic. But if people wish to forbid, extra message instances, then we could, leave it as a must not, and, I can add some text to the validation saying that if you spot one of these, you should reject the incoming message.

[00:13:13] **Pete Resnick**: Braun.

[00:13:15] **Bron Gondwana**: This is Bron. I I'm against the must not because it's not an interworking thing. I think we're better off allowing it, discouraging it. I do think we need to have some limits on there can be a maximum of 255 message instances per email. If you hit that many, then it's time to throw it away or something like that. And likewise, a maximum number of DKIM2 hops, again, in the ridiculously larger than is reasonable, but small enough that you can't do millions of them.

[00:13:47] **Pete Resnick**: Can can I suggest that if the numbers are the problem, you you sort of inverse it and say, receivers must be able to accept at least this much. You know, that that way, you're talking about the the interoperability issue is really on the receiver side for being unable to do that if

[00:14:13] **Bron Gondwana**: they're Yeah. The receivers can bounce for whatever reason. They can say, this looks like it's gone too far. Go away. But we do want to set a a reasonable limit that people can expect will work.

[00:14:25] **Richard Clayton**: I I would have thought the reasonable limit was 15 or 31 rather than two five five given that there is a usually a limit of 20 on received header fields.

[00:14:36] **Bron Gondwana**: I think that's reasonable for signatures. The question is whether we want to allow more message instances for someone that wants to document their individual changes inside something or whether we're going to say, no. You need to collapse them at the point that you next sign.

[00:14:57] **Pete Resnick**: Anybody else have any particular opinions on this? I'm hoping there are some people in the room who have to code this who are thinking in terms of what's two fifty five gonna look like as opposed to 31.

[00:15:12] **John Levine**: One more digit.

[00:15:15] **Pete Resnick**: One more digit. Lots more buffer space, but, you know, data centers heat up the planet plenty already. We can take it to the list. I you know, I'm fine. Obviously, the chairs are fine with whatever, but you all have to decide on something here.

[00:15:34] **Bron Gondwana**: Yeah. I think my argument is we need to pick a number. We can, like, shed the number.

[00:15:39] **Pete Resnick**: Ah, Alexis, suggests 42. Excellent. It is always the correct answer. And he likes 31 better. Okay. Good. We will bring this to the list and try and come up with a number that is useful. But I think everybody's agreed that must not add extras is not must not add useless ones is not an appropriate must not.

[00:16:07] **Richard Clayton**: Fair enough. My apologies for putting it in.

[00:16:09] **Pete Resnick**: Yeah. No problem. Next.

[00:16:14] **Richard Clayton**: Okay. Post quantum. As a result of the interim, which we now have five minutes for so we could remember what happened, there was going there was the process was going to be that a requirements document was agreed on the list, and then we would then go off and seek advice from experts as to which post quantum algorithm we should select. The reason for doing this is that if we pick a post quantum algorithm and put it in the spec on day one or where we are now, day 300, then six 100. Then that that pushes up significantly the chances that people will implement it as they roll things out. If we get it wrong, well, we get it wrong, and we can sort out the mess down the line. But, there is a fair amount of consensus as to which PQ algorithms are, okay and which ones are not now. And, you know, eventually, they'll get broken, but it's only eventually. So there are issues with very long keys, and this is something which has recently come up in the DNS op group because they started thinking about this as well. And they're starting to think maybe running DNS over UDP is not such a clever idea after all, which is about forty or fifty years too late. There you go. One of the experts who chipped in on our list said that, well, actually, one of the exciting issues in the PQ space is whether or not the algorithm you choose is hybrid or not. I'm not going to waste our time discussing what that is, but one of the ways in which one can get around the experts recommending a non hybrid algorithm to us is that we could say that all of the algorithms which were in a DKIM2 signature header field, all of them must pass rather than, just, just a should on the on on that. We would make it a must. And and if one of them failed, then that would be evidence that somebody was attacking one of a weaker PQ algorithm, which wasn't hybrid. So, however, this was not what the working group thought was a good idea. At a very early stage, this came up. And currently, we have shoulds and so forth, and the expectation is that there will be systems which will treat one pass as being just fine. This is not an issue that we have to necessarily, sort out today, and we certainly don't need to pick the PQ algorithm now. However, we ought to, see whether or we wish to reconsider the the should, must on everything passing because that will affect the the statement of requirements, which is passed to the experts when the advice is finally sought. So that's what this issue is.

[00:19:47] **Murray Kucherawy**: Just to re recap what we talked about at the interim, Way was going to propose a problem statement that we would take to some sort of expert resource that the sec area was gonna give us. The sec area gave us Paul Wooters, the former AD. We did propose a problem statement that was posted to the list, it's gone back and forth. There was some info from Steven, some stuff from John. I don't think that text converged yet to what the actual statement we wanna make, but we can arrange for that consultation to happen whenever whenever that does converge. But I'd that's mostly follow-up from last time. We can carry on here with like, that we and I think also, Richard, we should make sure Paul hears what the suggestion what your suggestions here and what's evolved since then. Maybe we're we're at a point where this is largely mood or something.

[00:20:35] **Richard Clayton**: I I think what we should do is try and finish off wordsmithing what we wrote, adding stuff, adding yes buts to reflect Steven and John's comments, and then we should try and get move on on this. Yeah. I would like to I would like to be able to put in a PQ algorithm into the spec by the time of the next IETF.

[00:21:01] **Murray Kucherawy**: Wei, looks like he has rejoined. Maybe he'll hop in the queue either way. Jim, go ahead.

[00:21:06] **Jim Fenton**: Hi, Jim Fenton. I don't know if anybody else was in the room, but I went to a side meeting this week about, DNS sec support with PQ, and they're doing a lot of looking at kind of what the performance impacts of many more TCP queries will be on, name servers and and everything else. So, there is there is some other areas I think that that kind of align with us in terms of concerns about, key sizes and stuff like that, and we can probably, take advantages of of some of those investigations.

[00:21:47] **Pete Resnick**: On

[00:21:54] **Bron Gondwana**: the this is Bron. On the all algorithms must pass, I thought that the spot we got to in this was that the receiver can choose which ones they they know how to check and whether they want to check them or not as a configuration option, but everything must pass if it's checked.

[00:22:11] **Richard Clayton**: No. It it says should because people said that having only one pass and another one fail was an interworking issue. You must go back to the list, or Barry can repeat his opinions here.

[00:22:33] **Pete Resnick**: Well, Way, go ahead and, Barry, hopefully, you can jump in and comment on this.

[00:22:40] **Wei Chuang**: Yeah. I did, as mentioned, put out some language with some help on, you know, just asking a a question from the CFRG about, you know, the algorithm.

[00:22:55] **Murray Kucherawy**: I

[00:22:55] **Wei Chuang**: mean, my read of that list wasn't there wasn't too much cut for virtual. There was some suggestion of algorithms on that discussion thread, but I figured that that was more commentary rather than questioning, you know, the phrasing or the details of of that question. I I had thought that what was put out there was sufficient to just go ask. And I don't know why, I guess, you know, based on that discussion, which I thought was pretty benign, that there was any real controversy. So and, I mean, you know, I guess folks who are are at the IETF, I guess, maybe maybe that question can just be asked of the people there that are very familiar with, post quantum and and just get some advice there.

[00:23:55] **Murray Kucherawy**: I mean At least I have that resource. I know when and like I mentioned, it was Paul, and he's ready for us. I just when I reread that thread, it seemed like we hadn't there was feedback about your proposed statement. If it's fine if the working group is fine to go with what we have exactly as we have and that was just sort of people venting, then fine with me. I just I thought I'd let that converge before I move move forward with Paul.

[00:24:23] **Pete Resnick**: Barry, go ahead.

[00:24:25] **Barry Leiba**: Yeah. I had to find the right window and then figure out where the button was. Yeah. I I don't like the idea of requiring all algorithms to pass. I'm trying to think of a of a case where it would be legitimate for that not to happen. So I don't have a strong objection to that. I think my real my big objection was all signatures passing, which didn't necessarily mean the same thing. So I I don't know how you word it so that the idea is that if you have multiple signatures on, at at different stages and there have been changes, they don't all need to pass. That needs to be clear. But if you have multiple signatures on exactly the same message, I have less of an issue with requiring all of them to pass because I like I said, I can't think of a use case where it would be legitimate that they wouldn't.

[00:25:38] **Pete Resnick**: Everybody else is looking like it's Friday. And honestly, when I read the discussion the first time, I thought we were talking about Barry's second case, which is all the signatures on a given message have to pass if there's more than one, you know, on on an unchanged message. Versioning, I I'm pretty sure that would be good too, but I can at least get my head around why that might not be the case. Yeah. John. Jim's oh, Jim's first. He beat you to it. Go ahead, Jim.

[00:26:18] **Jim Fenton**: Probably by milliseconds. Jim Fenton again. So I have to say I'm really not an expert on this on the PQ stuff, but the big controversy in the in the, TLS working group has had to do with whether about algorithms that are PQ only and and certain other algorithms that include both PQ and sort of traditional public key Hybrid. Algorithms hybrid algorithms. So if we're using a hybrid I mean, there isn't a question then. If you're using a hybrid algorithm, if we we decide that we wanna use a hybrid algorithm, that there isn't a a requirement there to have two different signatures because the one signature will cover, will will still be secure even if somebody finds a flaw in the, in the PQ algorithm.

[00:27:11] **Pete Resnick**: Right.

[00:27:14] **John Levine**: Yeah. This is John. I mean, that is true. I think the the the case I'm thinking I'm more worried about the case where the verifier doesn't understand all the algorithms. I mean, it look. You know, like, we're gonna we're we're gonna ship the the original draft that has, I don't know, elliptical curve algorithms, and then and then at some point, we'll we'll add the p we will add add add a PQ algorithm, at which point that's effectively hybrid if you can verify both of them. But if you can only verify one of them, then it isn't. But so I guess but my thinking is I'm okay with must verify everything so long as there is, like, bold black type that says the ones you understand. And if you cannot if if there are signatures if there are algorithms that that the verifier doesn't implement

[00:27:58] **Pete Resnick**: That you may may ignore those.

[00:28:01] **John Levine**: Well, you have to ignore.

[00:28:02] **Richard Clayton**: Well right.

[00:28:03] **Pete Resnick**: I I

[00:28:03] **John Levine**: Well, possibility would be, say, like, if you see if you see an algorithm you don't understand, you could say, I give up. I think that would be terrible for interoperability. So I think you I think you I think you have to ignore algorithms you don't understand.

[00:28:20] **Pete Resnick**: Go ahead, Bron.

[00:28:21] **Bron Gondwana**: Alright. This is Bron. Exactly what John said there, it would be reasonable to bounce it back in the HTTP case as we're seeing with all the debates around email and other things where you are talking to the originator. It's not reasonable if you are the fifth hop in a chain to bounce it back because the second hop put a post quantum key on there that you don't understand, a post quantum al algorithm you don't understand. There's been some fuzziness in the discussion I've heard in the room around signatures here. There's two types of things. There is a different hop, so a different instance of the DKIM2 signature, and there are multiple signatures on the same instance, which we allow multiple signatures on the same instance. So the question is, can you validate all of the signatures on the same instance? And I think in that case, needs to be if you can validate them and you do validate them, they must pass. But you're not required to validate all of them. You're required to validate one and be able to understand it. So it may be that in the far distant future where we have added a hybrid post quantum and you validate that, you decide I don't need to also check the RSA one forty four bit key, but it's there just in case there's some old validator also in the chain. But the important thing is if you validate it, it has to pass. You can't have one passing and one not passing.

[00:29:49] **Pete Resnick**: Barry, you're up.

[00:29:51] **Barry Leiba**: Just following up with after hearing John and Bron, the it would be a silly situation to say that if if I don't understand say, I don't understand the post quantum algorithm, so I'm gonna bounce that, if that's required, then it's silly to have multiple algorithms. The reason you have multiple algorithms is in case somebody only supports one and not the other, it's better than not than having nothing supported. So I I think we might wanna go with a should instead of a must on the all algorithms pass with the explanation that this means that you don't have to check all the algorithms, etcetera, you know, everything that Bron and, and John said.

[00:30:48] **Pete Resnick**: Andy?

[00:30:51] **Andy**: Andy, as an individual who is probably gonna say something stupid, Is is it that we're saying a small number of algorithms are required, or is it just any algorithm? Because any is gonna I mean, people would use those things that are those I know. I got your point taken off. I mean, there are out there are cryptographic algorithms out there that are used in certain parts of the world that are unacceptable in other parts of the world. So if it's if it's like, I I don't understand any of these algorithms. They're fine. I'm just gonna let it go then that

[00:31:29] **Bron Gondwana**: No, if you check it.

[00:31:30] **Andy**: That's not what I heard. So okay.

[00:31:34] **Pete Resnick**: So, Pete, as an individual, and you'll forgive me for not getting up to the floor, I I an attack surface seems to me, I sign it with some algorithm that you don't understand. And someone else gets in the way, makes changes to the message, and signs it with an algorithm that you do understand. And now I, as an attacker, have a way to if I know that this message is signed with something that some number of people won't understand, I try and sneak in by changing the message and signing it myself. That sounds like a bad outcome. Is that not a problem?

[00:32:21] **Bron Gondwana**: Bron again. If you receive a message and there is any DKIM2 signature on it, which you don't understand any of the algorithms in, you have to reject it or treat it as not DKIM2 because you can't validate the chain. You need to validate a of the algorithms on each signature, and it needs to pass. But there may be additional algorithms that you can't validate. Every every hop must have a passing signature on it. So, yeah, you treat it as not DKIM2 if you cannot validate it, which may be a reject or it may be Whatever. If you can validate the most recent signature, then you can safely bounce back to them regardless of the rest of the chain, but that's all you can do with it or trade it as not DKIM2.

[00:33:22] **Murray Kucherawy**: Okay. Yeah.

[00:33:24] **Richard Clayton**: Why this is an open issue. So

[00:33:26] **Pete Resnick**: Okay. So this will remain open. You do not have enough yet to write any text in your end of the world, and Way is still working with folks on what is being tossed back and forth across the wall.

[00:33:40] **Murray Kucherawy**: Yeah.

[00:33:40] **Richard Clayton**: I I I think we should press on with Way's statement, wordsmith it correctly, and then try and make some progress.

[00:33:48] **Pete Resnick**: Mhmm. Very good. Okay. Next.

[00:33:53] **Richard Clayton**: Okay. This is should be very straightforward and uncontroversial. People have pointed out that there was no requirement that there is a requirement for header field names in the JSON for the recipes to be unique, but there was no requirement for them all to be, say, lowercase or did or uppercase. And therefore, you would have to do some you have to take the stuff out of the JSON and lowercase it. And people said, why didn't we say that everything had to be lowercase in the JSON, which is a fine question. And I think the answer is that was an error, and we should make everything lowercase for the header field names in the JSON. Obviously, not the other bits of the recipes because they are case significant and contain exotic characters and that sort of thing. But for the header field names, then putting them in insisting that people put them in lowercase into the JSON. And if you don't do that, then your message is nonconformant. That seems just fine to me. But other people may feel strongly that they wish to put copy the stuff in from the case which was sitting in the header fields which they had to hand, and they didn't want to spend the effort lower casing it.

[00:35:19] **Pete Resnick**: Any concerns in the room? Going once, going twice, So it shall be if it's not complained about on the list.

[00:35:29] **Richard Clayton**: K. Fine.

[00:35:34] **Andy**: Okay.

[00:35:37] **Richard Clayton**: The receipts and certifications. Ron pointed out that it was in inherent in almost every, possibly every case when a DSM was created and handled by anybody. You could entirely predict what many of the fields would be because you'll guarantee your mail from would be null. You you would associate all the other things and so forth. So what was the point of having a message instance field anyway? Perhaps we could have some special header fields for for handling bounces. I might say I don't think anybody I've talked to is deeply in favor of having yet another mess header field defined here. We have two, and that is probably one more than we wanted when we set off. So no enthusiasm for us for a special header field here. However, out of that discussion did come, the, feeling that, identifying that something was a DSN was not necessarily entirely trivial. People pointed out that they were having to pause ahead of the rest of the header fields in order to see whether or not there was an appropriate appropriate minefields, which would make it a DSN and so forth. So the suggestion came up that perhaps we should put in the flag into the flag field of DKIM2 signature. We could add a flag that said this is a DSN, which would mean that a fairly early part of the code path could identify, without doubt that this was supposed to be a DSN. You could then send it off to the bit of the code which is going to handle, the DSN, and then that could do validation and so forth as required. That seems, moderately sensible. However, it's another flag, and it's more complication and so forth. So and people have said, well, actually, bounces are not in the same path as everything else because everybody puts in a special rigs, all of their bounces in order to go to completely different addresses anyway be because that's the only way that you can actually operate at scale. However, for smaller sites, they may well not be doing that. So having a DSN flagged might make some sense to smaller sites even if it wasn't actually particularly useful for bigger ones. So that is the issue, so people may have opinions.

[00:38:35] **Pete Resnick**: Yep. We'll go. Mauro, go right ahead. You're up.

[00:38:43] **Mauro Escalante**: Hi, Yeah. I we discussed this on the list. I don't think it's necessary to have a JSON flag because you can parse the content type Unless you want to save a few nanoseconds parsing the string, you can figure out there is a DSN from the from the content type headers. And then you need to parse anyway the Mime structure to extract the return message so you can confirm that anyway while you're doing the parsing that it's an actual DSN. So in my opinion, I don't think it's necessary. But if I'm missing something while content type parsing is not enough, I'm I'm open to open you. That's it.

[00:39:29] **Pete Resnick**: Bron?

[00:39:31] **Bron Gondwana**: This is Bron. I accept all of that. I retract my suggestion. Sorry for wasting your time.

[00:39:38] **Pete Resnick**: Excellent. Yeah. I thought there was some complaint that maybe people were generating DSNs without multipart report, but then no. Okay.

[00:39:48] **Richard Clayton**: Well, they they they may be generating such messages, but in the Deacon two context, then that would not be valid.

[00:39:57] **Pete Resnick**: That seems more than reasonable to me just speaking without a hat on. Ron?

[00:40:04] **Bron Gondwana**: Sorry. Popping back up again. Almost certainly, you'll be giving a different bounce address anyway, which only handles these things. It will also have to handle both a rejection over the wire and naive receivers that send a regular DSN that is not DKIM2. So you need to handle those cases anyway.

[00:40:32] **Pete Resnick**: Yeah. John.

[00:40:38] **John Levine**: I wanna make I see. There's basically two two two cases for DSNs. One is the ESP case where there's there's it goes to a special address, and the code knows how to parse it. The other is is I I send I send email to my brother-in-law, I mistype his address and it bounces back. You know? So it doesn't those bounces are already pretty pretty baffling, but I I I would like to make sure we don't make it more likely that they get lost or mangled.

[00:41:09] **Pete Resnick**: Okay. Not not hearing a whole lot of, objection in the room, and this was a change to accommodate what Braun was concerned about, but is no longer, if I remember correctly. We'll we'll confirm on the list, obviously, but I I think you have your marching orders, Richard.

[00:41:28] **Richard Clayton**: Okay. We can always add it later on if we get more experience from the interworking, particularly of the writing to brother in law's level of interworking rather than the ESPs.

[00:41:42] **Murray Kucherawy**: Right.

[00:41:43] **Bron Gondwana**: Okay.

[00:41:47] **Richard Clayton**: Right. Alignment. The Deacon two spec, very deliberately does not say anything about DMARC or indeed about SPF for that matter. But text about DMARC has to go, and in fact, there is some text there already into the BCP document. It is argued by some people, well, that we should expect a full alignment between the the from header of the original message I. E. Five three two two from header, the mail from five three two one envelope, from address, and the d equals domain on the first DKIM2 signature header field, and all of these should be the same, because, that way, it needs to be that way in order to get demarked passes, and that is the way in which good mail as opposed to spam is always sent. Well, it's not always sent that way. And one the of the reasons that we have a distinction between five three two one and five three two two from is because they don't need to align in classical email sending. So all of the spec says is that the mail from and the decals have to align because that is part of the replay protection systems and and the chain of custody protections that DKIM2 has, but there is no requirement inside DKIM2 itself for any alignment with the 5321 from header. And some people believe that we should change this and say that the 5321 from Heather should align as well, and that this will not make any difference to any real email. As it says on the slide, discuss.

[00:44:00] **Pete Resnick**: Alan, you are first up to discuss.

[00:44:06] **Alan**: So I kinda feel like we have two options. We can either, in DKIM2, say that for the first first hop, all three of these things must align,

[00:44:18] **Andy**: or we

[00:44:20] **Alan**: can update DMARC to accept DKIM2 as a authentication mechanism by which senders that want that property can declare that they want all three of these to align and for recipients to reject mail where that's not true. Doing neither means that random domains can send on behalf of my employer's domain with no no way for DMARC to say that's not allowed, which seems unwise.

[00:44:57] **Pete Resnick**: We seem to have a great deal of discussion developing. Jim, you're up next.

[00:45:04] **Jim Fenton**: Hi. Jim Fenton. I'm that guy that hasn't read the latest drafts and is pretty well out of date, so feel free to tell me to sit down right away if if this is a problem. That said, so the requirement that mail from when the message was first sent and d equals, on the signature align seems to cause a I would think causes a problem with mailing lists akin to the one that requires rewriting of of, email addresses. Is that the case? And if so, I have a problem there because I don't think that we should I mean, DMARC has its has its own requirements. I don't think that we should be trying to do things to DKIM in order to necessarily restrict the way that it currently works.

[00:46:03] **Pete Resnick**: Go ahead, Wei. Yeah.

[00:46:07] **Wei Chuang**: So I guess plus one to what Alan said And to, I guess, Jim's concern, I I think the idea with that mail from and latest signature alignment and and also just wanted a plus one. What Richard said is that we need that sort of alignment for for that replay protection. I think if the concern is around whether or not mailing lists can identify themselves, I I think, they should if they want to participate and not look like someone trying to do a replay attack. I think that so the I I mean, I think that actually this alignment question is slightly also different too. I think this particular question is more about, you know, on the slide that is around alignment with the from header and as opposed to, say, you know, the male from and and the d equals. I think this issue is about identifying some notion of an originator, and trying to say, hey. What is the identity of the party that claims to have sent the message? DKIM2 does make it more complicated and and in fact that that it supports multiple such, from headers, potentially in the message because the from header may be rewritten, and that's oftentimes done to go support, you know, DMARC one with, I'm sorry, Deacon one with, you know, DMARC, being that, like, DMARC requires that sort of alignment. And, to support mailing lists, oftentimes, it is rewritten, when the mailing list modifies a message. Now what I, thought was interesting, and I put out some some stuff just right before the meeting on the, list, about this thread. I think Tobias had started off a thread of asking this question, was basically we have in the BCP as well as the spec document commentary around you know, there there is such a thing as an originator. And it occurs to me that we don't have a good way for a receiver to identify what, you know, that is. And we do need some sort of mechanism to define who the originator is. And I claim that, you know, one way to do this is to go look to see if there was from header alignment at the signature i=1. And then that might be a workable way of saying, okay. Most likely, that's who the author or who was supporting the author of the message. And that might be, you know, just a heuristic to try to define these things.

[00:49:08] **Murray Kucherawy**: This is Murray from the front also being lazy about getting up to the mic. I'm a little worried about all three of these things being required to be in alignment in the sense that I remember open source implementations. If you change the from to be some domain you support, that's fine. Getting d equals alignment with that is probably easy, but requiring that mail from also align would be a problem because the open source tools, as I recall, would emit a canonical name for that host, and they may not align. So we might be imposing a requirement that is hard for some legacy operators to meet. So it's kinda like what Jim just said as well. Go ahead, Bron.

[00:49:46] **Bron Gondwana**: Alright. This is Bron. I think we need something in DMARC that says, I only send DKIM2 messages. Anything that's not DKIM2 from me is considered bad. And we because you basically need demark for the negative case in DKIM2. You don't need it for the positive case because you can put in the flags on the signed message everything that you want the receiver to know about this particular message. So it's just for handling the negative case, and so we need to have a way of describing that. And, otherwise, it looks like there's enough people with use cases for alignment that certainly the BCP should have some shoulds and some if it's not there, then look at it as scant. But I don't think we need musts for any of this. And, certainly, the spec itself should just say this is the mechanism. This is how you can tell who it was without requiring alignment.

[00:50:47] **Pete Resnick**: John.

[00:50:53] **John Levine**: This is John. I have a I have a perverse case, which I can promise you shouldn't happen but will, which is you have some random mailing list. It rewrites that it it it rewrites the front line because it is configured to do that. Then they upgrade, and they start putting on DKIM2 signatures. And guess what? Since the Deacon matches on the most on the on the last signature, but not the first signature, it'll fail at all the mail abouts. So I fear that it that if we're gonna if we're gonna require alignment on DKIM2, I think we need we prob probably any d equal domain matching or perhaps the first or the last matching. But I think if it's just the first, you're gonna run into this case where the mailing list are gonna say, wow. DKIM2 broke stuff even even worse than it was before. The hell with you. We'll never do it.

[00:51:39] **Pete Resnick**: Mhmm. Mhmm.

[00:51:43] **Richard Clayton**: Way.

[00:51:45] **Wei Chuang**: So one thing, it would help to understand the this, older legacy mailing list, scenario. Why why is there problem with the mailing list not being able to identify themselves with alignment? I mean, just I I just don't know. So I just wanted to understand that, John.

[00:52:15] **John Levine**: Oh, the when I send stuff through, say, an ITF mailing list, and if I had if if I appear people's reject turned on, it rewrites the front line to be itf.org, and it adds a signature saying itf.org. But that is now the second or third signature. It's not the first signature. So the first signature was me. The third signature is ITF. The header is rewritten to itfinacom in a so then the the DKIM2 verifier will say, well, the most recent signature verifies and the whole chain verifies. But the but the but the address on the front line matches the most recent signature, not the original signature fail or not or not not not not aligned. You know? And the reason they will continue to re rewrite the from line is because not everybody's gonna implement DKIM2 right away, so they're gonna have to keep rewriting it for the for the DKIM1 crowd.

[00:53:06] **Pete Resnick**: Well and I would say more importantly, the rewrite the firm header is a configuration of the mailing list, and the DKIM2 is probably going to be a configuration of the MTA. Right. Go ahead, Wave. You have more.

[00:53:24] **Wei Chuang**: Yeah. So, I mean, it sounds like there there was a concern that there is the from header alignment issue. And, I mean, as far as I know, the spec doesn't call for that being aligned. It does require that the signature, and the mail from align. And I I still think that I at least I've so far, I've as I've heard, I haven't heard a problem with that yet.

[00:53:52] **Pete Resnick**: Which signature?

[00:53:53] **Wei Chuang**: Yeah. And the mail from Align. Yeah. Mean, DKIM2.

[00:53:56] **John Levine**: Yeah. I mean, I think the the clearest way I can make it is that the way the way this slide makes it, a mailing list can be DKIM1 aligned or DKIM2 aligned, but it can't be both.

[00:54:10] **Wei Chuang**: Right. I mean, this this is this slide is drawing, you know, that there ought to be some sort of from header alignment, and it was going to be a BCP, you know, text proposal. Right? That and then that's just to define some sort of language to at least my take was to find an originator. And because, you know, the the spec does call for there being a a description of an originator for for folks who want to understand who that is. And that does, of course, talk towards, the DMARC issue where that is absolutely necessary. But I don't see you know, excluding the issues around DMARC, and I know that everyone's trying to dance around that. And as far as I know, there isn't a requirement with must or anything like that about that. I mean, excluding that, I don't see the the problem between the dkim2 signature, the mediate one, and the mail from. I I'm I'm still trying to understand why that would be a a risk or an issue.

[00:55:25] **Pete Resnick**: No. I I I don't think it's about the mail from I think it is about the from header that people are talking about. And if I understand you correctly, Wei, you're saying with regard to the from header field, the DKIM2 document should be silent, and we should figure out how to update DMARC. Is that That that would

[00:55:49] **Wei Chuang**: be a way forward. Absolutely. I mean, my understanding is that the preference at the moment was to update the BCP for that because there are issues with trying to update, say, the DMARC document. I agree that at some future point, you know, we should, con tackle that. But at the moment, I think there's more more consensus to trying to update the BCP document.

[00:56:12] **Pete Resnick**: Okay. So I I believe that you and John are in violent agreement, but let let's

[00:56:16] **John Levine**: I I'm I'm in violent agreement except to note that the the the specific proposal here

[00:56:21] **Pete Resnick**: On the slide.

[00:56:22] **John Levine**: Is is is hopelessly broken.

[00:56:24] **Pete Resnick**: Okay. Appreciate that. Alan, go ahead.

[00:56:30] **Alan**: I'm I'm gonna disagree with John's statement because this the statement on the slide is specifically talking about the first signature, not the mailing list case where it's the third signature. There there's nothing here that says the third signature must align with the from field in the original message because that's sort of not workable thing in any email flow involving more than one system. So all of these discussions about what happens with intermediaries is not not what's being proposed here. This is just talking about d like, i=1 signature and the d equals on that signature and the mail from used to deliver that specific message and the from header field included in that message at that point in time. And then, like, later, if you've got recipes that change the from field, you undo them, and you should be able to undo them to something that equally aligns. But that, again, is talking about the original message, not the thing that you got on the wire at at i=10.

[00:57:47] **Pete Resnick**: Richard, you had a comment from the floor? Richard?

[00:57:56] **Richard Clayton**: Okay. Plus one exactly to what Alan just said. The slide is talking about hop one. It is not talking about mailing lists, which are not at hop one. They do their own thing. There is something which has not come up yet, which is something which mailbox providers are going to have to think about down the line, is now that they can see and reconstruct what from the five three two two from header field was at this when the message was first sent, and this has been mangled since then, what, they may decide that it's appropriate to use the recipes to go back to the original from header field and display that to the user in their user interface, rather than, and use that for their demark calculations and so forth as to the validity of the message. And that is what and that is what they're going to display to people. And the fact that mainly this is mangled things will be hidden away because that is an appropriate heuristic for them to use in terms of how they present the mail to the user when it finally arrives. So there are other issues here which interwork with this. And, again, this is all BCP stuff, but it is something which we ought to come to a reasonable consensus as to what the BCP document should say. Otherwise, it is not BC, is it?

[00:59:30] **Murray Kucherawy**: Bron?

[00:59:31] **Bron Gondwana**: Bron, violently agreeing with the last two speakers that, yes, the recipes give you the undo. Obviously, if the mailing lists Dkim aligns with its from, that's still gonna get unwound. John, do you agree with this? Has this covered yep. Cool. I'm getting a nod from there. And also very much agreeing with the idea that nothing in spec itself is going to say anything about the content that's going over the wire. All that spec cares about is the envelope, and it puts that into the DKIM2 signatures. And it's it's a general thing, and the specific alignment will be a practice that might change more frequently over time as DKIM2 gets more widely deployed.

[01:00:15] **Pete Resnick**: I from the floor, I just put the question in, and Alan half answered it for me, which I got that part of the answer in my head already. So a mailing list that does DKIM1 or no DKIM at all receives a DKIM two message, and it rewrites the from header field and then sends out and it is received by a DKIM2 thing, is there any possibility that that message bounces?

[01:00:48] **Richard Clayton**: Perhaps we could move to my next slide.

[01:00:50] **Pete Resnick**: I love moving to your next slide if that will give the answer to the next question.

[01:00:57] **Richard Clayton**: Okay. How we handle DKIM1 messages? I wrote about this on the list, and there was not a huge amount of pushback to what I wrote. I don't think anybody replied to it, in other words. If you accept to DKIM1 message and forward it, then and you are DKIM2 aware, then should you add a DKIM2 signature? There's more complicated but related issues which arrive with when thing messages hop in and out of the DKIM2 ecosystem. Now if you are mailing list, then putting a DKIM2 signature on something which arrived at Deakim one is probably a good idea because the people who receive it will will basically be able to do some analysis on the message. And if they don't like it, then they're gonna generate a DSN, and that's gonna come back to you as the mailing list. And that point, you can arrange not to bother the person who sent it to the mailing list. You can deal with whether or not they should remain subscribed and things like that are very straightforwardly. And if the bounce is something like mailbox does not exist or whatever, then that's nothing to do with the message per se, then that is an issue for the for for you to deal with your subscription list for the mailing list. Now if you are not a mailing list, then I don't think there are any upsides to putting on a DKIM2 signature at all. Yes. You will get the DSNs, but unless you can really reliably assert that this is not a DKIM replay, then, essentially, if there is a DKIM replay which occurs with this message, then you are the person who is going to get blamed by the, recipient, and this is your reputation. This is going to get dinged. So there's no real upside to the putting on a DKIM2 signature if it arrived to you as Deacon one. Now if you're a submission server, that's different. If you're a submission server, then you should strip out all of the stuff and and start the message on its on its way purely in the DKIM2 world. I'm talking merely about people who are in the middle of the chain, who are just forwarding stuff. If you're DKIM2 aware and you get a DKIM1 message, then I don't think you should DKIM2 sign it. But other people may not agree with me. And this is something for the BCP. This is not a spec issue.

[01:03:40] **Pete Resnick**: We've worn them down or they all agree

[01:03:43] **John Levine**: with that one. I have one

[01:03:44] **Richard Clayton**: more slide, and then we can

[01:03:47] **Murray Kucherawy**: All go to sleep.

[01:03:51] **Bron Gondwana**: Agree with everything you said.

[01:03:53] **Pete Resnick**: Everybody on board with this?

[01:03:56] **Richard Clayton**: No? You just have to accept it's an open issue and that it would nice be nice if it wasn't still an open issue at the next meeting.

[01:04:09] **John Levine**: Right.

[01:04:09] **Pete Resnick**: So maybe maybe you can answer the question that I think more or less Jim and I asked in the chat, which is if you are completely DKIM2-unaware and you receive a DKIM2 message and do some rewriting and pass it along, the next DKIM2 thing to see that will probably complain, will it not?

[01:04:38] **Richard Clayton**: Yes. It probably will. But equally

[01:04:48] **Pete Resnick**: And maybe that's not a problem, but I

[01:04:50] **Murray Kucherawy**: just wanted to understand. It may

[01:04:53] **Richard Clayton**: or may not handle. It depends on what it depends on local policy. Right?

[01:04:58] **Murray Kucherawy**: Right.

[01:04:58] **Richard Clayton**: You may have noticed that, yeah, Yahoo also says that various things should happen. But if you send mail where you have not met these standards, then you may or may not get your mail accepted depending.

[01:05:11] **Pete Resnick**: Right.

[01:05:11] **Richard Clayton**: And that depending is entirely local policy. And I can certainly tell you that depending on the IP address you send from, you may get completely different application of local policy. Yep. And that is the way the world is. Thank you. Is full local policy.

[01:05:27] **Pete Resnick**: Alright. On we go to feedback of the first sort.

[01:05:31] **Richard Clayton**: Okay. Right. A feedback loop for those who are not familiar with it, is when a mailbox provider, after the goodness of its heart, decides to provide a report about things like message placement, whether or it went in the spam folder or what they what they thought of the quality of the message or whether what the user did with the message, when they opened it, stuff like that. It is entirely it is generally to do with whether or not anybody thought it was spam, but you can have all sorts of other things. And that is provided back to the sender. This is not a bounce. It is intended to help senders understand whether or not their email is suitable for purpose. Now DKIM2, the specification, we put in a couple of flags related to feedback loops because some of the existing feedback loops are based off DKIM1 signatures, basically because, if you can see a DKIM1 signature or, for that matter, DKIM2 signature on a message, then you know that the person who put on the system that put on that signature saw the contents of the message. And therefore, the lawyers are happy that you are not sending feedback to some random stranger. You're sending feedback about the message to somebody who has already seen all of the message themselves. They may not remember seeing it, but in principle, they they have a really good memory of it. They know all about it. And therefore, you providing your opinion about the message does not leak any privacy information or anything like that. So that's how so many feedback loops, which exist and aren't all that many these days, run off the DKIM signatures. However, the specification, at the moment, the BCP, have nothing particularly about what feedback is like and so forth. The question here, and that is is something which ESPs are kind of interested in, is is there any appetite for trying to standardize, take the opportunity to standardize, some stuff about feedback loops? Now there's charter issues with doing this, but, basically, do people do people feel that the notion of feedback loops is so well understood these days that writing down the specification for it and trying to make them into work a bit better would be a useful thing to do? Or is it still so proprietary and so strange and different between mailbox providers that this is just is a waste of time?

[01:08:16] **Pete Resnick**: Alan has thoughts. Alan has exasperated thoughts. Do

[01:08:30] **Alan**: I think there's value in standardizing it? Yes. I I do think that that that would be very worthwhile. Does that work happen here? I don't think so. I don't think this has anything to do with authentication. So, yeah, I I I understand it feels weird to have a a flag in this thing that's, like, about feedback without being able to point at something that you would use that for. It it does seem pretty weird. And I understand why we need it, and there's there's privacy reasons why why we need to be able to specify where the where the stuff goes. But, yeah, it's I felt like the I don't think there's a good answer here.

[01:09:33] **Pete Resnick**: Alan's answer appears to be if we have to. Bron?

[01:09:38] **Alan**: Well, if we could convince Mailmate to do it or something.

[01:09:43] **Bron Gondwana**: Mailmate would love more work. This is Bron. I agree that this this work would be good. I think sequencing wise, it needs to come much later. I don't think we should block or wait on it at all. Those who are most interested in it should show up and do it if they want it. Whether it's here and we recharter after we've already finished spec and at least done a lot of work on BCP or not, or whether it goes somewhere else, I don't care. I don't want us to block and wait on this at all.

[01:10:20] **Pete Resnick**: I think your chairs will never be upset with

[01:10:23] **Murray Kucherawy**: defer. Anybody

[01:10:29] **Pete Resnick**: else have a thought on this? Do we know who might say, no. No. No. You have to do it now way?

[01:10:40] **Wei Chuang**: Can a placeholder flag be present in the spec and then basically do that work later. And I guess the spec can say something about that this is going to be defined at some later point.

[01:10:56] **Richard Clayton**: Well, this is actually what it does already.

[01:11:00] **Pete Resnick**: Because you have to ignore Ignore flags. Ignore undefined flags anyway. Right?

[01:11:05] **John Levine**: John? I would

[01:11:07] **Pete Resnick**: Well, Braun was first, but

[01:11:08] **Andy**: Well, I Okay.

[01:11:09] **Pete Resnick**: Thought it out, and John's gonna go first.

[01:11:11] **John Levine**: Alex Brautman has a draft that's been kicking around about feedback, basically publishing something in the DNS that says, here's here's where to send your your key DKIM-linked feedback stuff. So, I think we'd start with that. You know? And I agree that that it's perfectly fine just to say, we'll think we'll think about it later, and maybe it'll be like that.

[01:11:31] **Pete Resnick**: Bron?

[01:11:33] **Bron Gondwana**: This is Bron. I just wanted to say one thing that I think we do specifically need to have is the do not send feedback to hot earlier than me to allow the privacy protecting forwarders to say, I I don't I I know that I'm blocking this.

[01:11:50] **Richard Clayton**: That is in spec -04 already.

[01:11:53] **Murray Kucherawy**: Yeah. That was consensus in the last interim, I think.

[01:11:56] **Bron Gondwana**: Just saying don't remove it. That's all.

[01:11:58] **Mauro Escalante**: Okay.

[01:12:02] **Pete Resnick**: We're we're hearing mostly defer this discussion until other things are done.

[01:12:09] **Richard Clayton**: Okay. In that case, I'm done.

[01:12:12] **Pete Resnick**: Excellent. I'll get control there. Yeah. And, Bron, you had a couple of slides about trace headers.

[01:12:23] **Murray Kucherawy**: I do, indeed.

[01:12:25] **Bron Gondwana**: thank you.

[01:12:26] **Murray Kucherawy**: You want the clicker?

[01:12:27] **Bron Gondwana**: Yeah, why not? No, you can click for me. That's fine. Alright. Trace headers. There's some arbitrary number of them. Next slide, please. So this is the definition of trace header from RFC five thousand three twenty two. It defines two of them and says, these are the entirety of the trace fields. Next slide, please. But really, is that all? We've added some other things that aren't signed all of arc star authentication results delivered to got added later, and DKIM-Signature, as well as received and return path, which are the two specific trace fields listed in the RFC. And of course, all of x hyphen. Next slide, please. So I got an LLM to read through all of the RFCs and see which documents define things and call them a trace field. Everything here, the specification says, this is a trace field as defined in mail. So there, as you can see, two of them we have said, we're not going to include received SPF with run into issues with already. Some of them aren't from mail, but some of them are, and presumably exist in other systems that I don't run. Next slide, please. There's also some things that behave like a trace field anyway, but the doc didn't say trace field, they just gave instructions that looked remarkably like a trace field, including the arcs and the delivered two that we've already identified, along with the original recipient, and apparently two, which probably should also be in our list of things that we don't sign. If we could go to the next slide, please, which is where I have my questions. What should we do with all of these? I have a document which said, update CIANA registry and says to Anna, please mark these things as trace fields because they really are. And also does some other things like saying, please mark these as standard because they were defined in a standard, but nobody ever said to add that. And so there's a column that says this is a standard field right next to an empty bunch of things, which are very much also standard. And so I'm going to try and find the right venue for that. My area director's carefully not looking at me here. But I do think that's that's important maintenance work to make that registry more valuable. But also, we probably should have these things in there. What I don't have in these slides and have been thinking about since is that we need an escape valve. And I think we should also ask Anna to reserve Trace Dash. And we should skip Trace Dash in all our signatures and then say, all future trace header registrations must begin with trace dash or trace hyphen, and then whatever they want to say so that there's this defined list of we did this before we thought about it. And then everything else, you can just say skip everything that's a trace header and allow people to define new trace headers without having breaking out our existing signature process.

[01:15:43] **Pete Resnick**: That's very interesting.

[01:15:44] **Bron Gondwana**: I think I think we need to do that. I also think we should have a vendor dash prefix, which is also skipped and allows vendors to define their own things without putting an x in front of it if they want to. At the moment, everyone just does x hyphen something, but there's there's people get confused around that. And I think a specific this is a vendor field, that's not signed is also valuable. That's my proposal. Discuss, as they say. Way.

[01:16:19] **Wei Chuang**: Yeah. I think this is all good things to document, so kudos to putting all this together. One thing that I wanted to, bring to consideration regarding the vendor dash now say a vendor does want to have some sort of vendor specific header and wants that to be, preserved, so that, they can go validate, that it wasn't tampered with at some later point. So there may be need for some consideration of sort of, like, the opposite case in in some way. They have the whole rest of the namespace. Right. Right. Right. And then, like, you know, something that calls out, that that basically if a vendor wants to do that, then, you know because right now, we already have carved out x dash as sort of that sort of vendor space that will not be, you know, it won't it's it's gonna be treated as basically like a trace header. I know it won't be basically taken consideration for the header, signing. Actually, one one other, sort of risk, I guess, is and maybe this is something that the spec can, you know, consider or basically forbid. It's like, so with these trace headers, what and they won't be protected. They won't be, hashed and signed. What happens when when they are included in the algebra, the header algebra? So they're not protected, but they are included in the algebra. And perhaps there ought to be some sort of language that says, okay. We you know? If if they're for these trace headers or trace header like things that are not gonna be signed, they should not or they must not be included in in, the algebra just because otherwise, it's it's kind of a, you know, dicey sort of, proposition maybe for, say, you know, the recipes to or or creating a a valid prior version of of the message, basically, is what I'm saying.

[01:18:29] **Bron Gondwana**: Yeah. I that is an open question whether the recipes must not include things that that don't contribute to the hashes. I lean towards leaving it open that you can create a recipe that shows what you did even to the fields that aren't being hashed, but it doesn't matter. It won't it won't make a difference whether that part of the recipe is applied or not to whether the previous things pass.

[01:18:57] **Wei Chuang**: Actually, I'm I'm for some sort of language in that

[01:19:00] **Bron Gondwana**: Yeah.

[01:19:00] **John Levine**: This this

[01:19:00] **Bron Gondwana**: should be language one one way or the other around that for sure. So

[01:19:08] **Pete Resnick**: most of this sounds not Dkim working group specific with the exception of what Wei is talking about and maybe the, you know, reserving the trace, you know, trace dash prefix. This does seem to me like an interesting document overall because I don't know that you need vendor if you've got TraceStash. Because I can have TraceStash Pete Corp, and I can have Pete Corp. And it the TraceStash Pete Corp is stuff that should be internal that I expect I should delete on the way out of p corp, but if I fail to ignore it Yeah. And p corp is I expect it to go out and come back and and everybody to be happy. And maybe this is a separate document about, you know, how to do trace headers, vendor headers, extension headers, etcetera Yeah. As a separate document.

[01:20:10] **Bron Gondwana**: A space in the header field namespace that vendors know they can screw around in, and they're not going to get stomped on by another standard document, which is why people are using X- hyphen now because the we say we're not gonna create anything.

[01:20:26] **Pete Resnick**: Right.

[01:20:26] **Bron Gondwana**: It's standard that

[01:20:27] **Pete Resnick**: the Except anybody can stop on stomp on Any pretty Microsoft. And

[01:20:32] **Bron Gondwana**: But it it's pretty obvious that they're doing the wrong thing. Whereas if a working group comes along and says, we're going to use this name that someone was already using, the working group wins because ITF owns the namespace. And so carving out a bit that we say we're explicitly not going to put anything in here, and it's not signed, which is x dash or we're we're explicitly not gonna put anything in here, and it is signed. I think we do need to have both of them. I we have to be careful not to break the ability of the rest of the world to create trace header fields ever ever again without messing with DKIM2. So that's that is the bit that's relevant to this group. Right.

[01:21:14] **Pete Resnick**: Yes. Go ahead, Jim.

[01:21:17] **Jim Fenton**: Yeah. Jim Fenton again. I haven't looked at the registry in a long time, but is there an attribute in the registry already that says this is a trace header?

[01:21:27] **Pete Resnick**: Yes. Email would

[01:21:28] **Bron Gondwana**: has two items in it, which are the two that are defined Yeah. In 5322. And all the other things that have said I'm a trace header since have not asked Diana to update that.

[01:21:39] **Jim Fenton**: Okay. So it seems a little bit a little bit against the notion of having a registry to have some semantics associated with the name. Do we have other examples of where there's a a registry?

[01:21:55] **Murray Kucherawy**: Media types. Okay. We have a vendor tree, a personal tree, and the standards tree.

[01:22:00] **Bron Gondwana**: Okay. Good.

[01:22:02] **Jim Fenton**: Thank you.

[01:22:07] **Murray Kucherawy**: But I guess the one thing I would say about that is that the media types community is used to that. We're imposing something new in this community. I don't know how they're gonna react.

[01:22:18] **Bron Gondwana**: Yeah. Andy, what would you like me to do with this document?

[01:22:22] **Pete Resnick**: Go away.

[01:22:25] **Andy**: This is Andy. I would prefer that you be very, very kind to the Mailman chairs and ask them to ask them to ask the work group to take this on. And if you need a priority, ask them to prioritize it. I don't think this belongs in email core. Alright.

[01:22:42] **Bron Gondwana**: Ken, let's let's go have let's go get some fish and chips and discuss.

[01:22:47] **Andy**: Yeah. You may know him. So yeah.

[01:22:50] **Bron Gondwana**: I spoke with Alexi about his similar draft. He said, please don't add this to my similar draft, which is basically ready to go, and I don't want to wait. He also said, I wrote some of these documents, and and I'd like to help you make this even better. And we went through and discussed all the fields in the documents he's written and added text about them to this. Alright. Ken.

[01:23:25] **Ken Murchison**: This is Ken shooting from the hip and have having now talked to my co chair, I would expect that if this is just documenting existing practice and updating that registry, that'd be pretty straightforward and would sail right through. If we're adding language and carving out adding language talking about what we should be doing, carving out a namespace that's a little bit heavier lift, and I think it's gonna take longer.

[01:23:51] **Pete Resnick**: Yep.

[01:23:51] **Ken Murchison**: And given given our current workload, it's gonna get backed up a little bit unless we can get our Mailman friends to start moving quicker.

[01:23:59] **Bron Gondwana**: Yeah. I feel like maybe there's two things to do here, one of which is to this document basically as is without any of the carve outs and then a separate carve out, especially because this can probably be an informational document, whereas the carve outs very much need to

[01:24:14] **Pete Resnick**: be standard tracking. Yeah. Yeah.

[01:24:16] **Ken Murchison**: My thought exactly.

[01:24:18] **Pete Resnick**: K.

[01:24:21] **Bron Gondwana**: Alright. Thank you.

[01:24:23] **Murray Kucherawy**: I believe John had a topic.

[01:24:26] **Pete Resnick**: You wanna talk about the other feedback?

[01:24:28] **John Levine**: We we we talked we did.

[01:24:30] **Pete Resnick**: We talked about the feedback that you wanted to talk about.

[01:24:32] **John Levine**: We talked about the DMARC stuff, and we talked about the the sandbox

[01:24:35] **Pete Resnick**: stuff. Excellent. Okay. All covered. So so AOB. We are at AOB. Does anybody else have any other a o b? A o a o b. Oh, fearless a b. A b a o b.

[01:24:53] **Andy**: Just wanna bring to everyone's attention the DMARC working group or, yeah, their mailing list. I don't know what Barry's final conclusion is on there, but there was talk about bringing, like, ARC considerations or something like that. I don't know if that would land here because what they were talking about is DKIM2 obsolete set or something. So

[01:25:13] **Wei Chuang**: Oh, yeah.

[01:25:14] **Andy**: Maybe keep that in mind.

[01:25:15] **Mauro Escalante**: I

[01:25:16] **Andy**: I'm not even sure. I don't know if that fits in your your charter either. It

[01:25:22] **Murray Kucherawy**: it would be a squeeze. Are you talking about the actual state change doing it here instead of there?

[01:25:29] **Andy**: No. No. No. No. No. No. The the I mean, I haven't written this. I I I'm not writing this document. Right? This is what's been I've seen on the mailing list. It was just that they well, maybe they do want it

[01:25:43] **Mauro Stalwart**: to So they

[01:25:44] **Andy**: They don't have to get a draft to make make it historic, but

[01:25:46] **Murray Kucherawy**: I think They have to make you do something.

[01:25:48] **Andy**: Yeah. But they wanted a document documenting why they're making it historic.

[01:25:51] **Pete Resnick**: Yeah.

[01:25:52] **Andy**: And there's no and and it's it's basically saying use Deacon two. That's my understanding.

[01:25:56] **Murray Kucherawy**: Right. And some of the argument is don't do that until DKIM2 is ready, which would then you could synchronize it with or do it in this working group with your help, of course.

[01:26:06] **Mauro Escalante**: Yeah. Alright. Anyway want that DKIM2 to obsolete.

[01:26:09] **Murray Kucherawy**: That's what I'm saying. It's like they might it's like so the are the the we're off topic for this working group at the moment, but the question the challenge over there, what they wanna do is deprecate ARC immediately. The the some of the people resisting that saying, we shouldn't do that until this stuff is done.

[01:26:26] **Andy**: And I'm I'm not even convinced that's a proper order anyway, but anyway.

[01:26:32] **Murray Kucherawy**: We can figure it out later. Four minutes to go.

[01:26:38] **Pete Resnick**: Going once, going twice, you get four minutes back to go get munchies before the next session. And

[01:26:50] **Murray Kucherawy**: see you all in San Francisco.

[01:26:51] **Mauro Escalante**: If

[01:26:52] **Pete Resnick**: See you all or oh, we'll I'll make sure. We'll we'll put a question to the list about whether we when and whether we want a next interim.

[01:27:01] **Murray Kucherawy**: People seem to like them.

[01:27:01] **Pete Resnick**: But people do seem to be getting something out of them. Yes. Alan? The interim. Alan, you wanted to say something?

[01:27:09] **Alan**: I was just saying yes, interim.

[01:27:11] **Pete Resnick**: Yes, interim. Okay. Appreciate

[01:27:13] **Murray Kucherawy**: it. Perhaps so.

[01:27:13] **Pete Resnick**: Alright. We will see you soon.

[01:27:15] **Andy**: Not dkim two related. If you, were in the MTA hooks thing, you could we could scrum for a bit.

[01:27:21] **Pete Resnick**: Oh, okay. Thank you all. Yes.

[01:27:53] **Murray Kucherawy**: Tonight? Yeah. I must go shopping.

[01:28:04] **Pete Resnick**: Yay. Yeah. I'm just closing down things.