IETF Meeting Minutes

Session Date/Time: 27 May 2026 20:00

Murray Kucherawy: Oh, there, I was muted. Can people hear me now?

Bron Gondwana: Yes, thank you.

Murray Kucherawy: There we go. All right. Pete and I were on another call just a few minutes ago. So, he should be here any moment. Let me get our agenda ready here. Online. I realize I put an agenda together with topics but did not actually secure speakers. Richard, are you on and willing to just drive discussion as before? I don't believe we got any slides from you.

Richard Clayton: I didn't do any slides because I assumed that you were you had them under control because you had the agenda.

Murray Kucherawy: That's fine. I mean, more about the three topics that we've uh they've seemed like to be the three things that we didn't resolve last time that needed more time this time. Um, let's see here. Where did my agenda go? Um, so the let me, um, where did

Richard Clayton: The the first agenda item was header signing.

Murray Kucherawy: Yes, uh, I need to do the admin trivia bit first.

Richard Clayton: Oh, oh yes, just just in case we've had something.

Murray Kucherawy: Yes, or someone new as of as has appeared. Let me find. Materials. I can't find the slides that I Oh, here, okay, I'm going to borrow the slides from uh the previous interim since they are the same and then we'll just go into the topics. So, one moment, please, while I coordinate this. I will update these, but to be to have the correct date and number, but they are the same material. So, can anybody hear me?

Murray Kucherawy: Hey, Pete.

Pete Resnick: Hey.

Murray Kucherawy: I just realized that my upload of the chair slides didn't actually make it, so I just recycled the ones the just the the the introductory slides from the last one, since they are, of course, the same. So, please note the Note Well, as Barry likes to say. This uh there is this slide is a series of makes reference to a series of documents that describe your intellectual property rights and the IETF's intellectual property rights, guidelines for conduct and anti-harassment procedures, um everyone is expected to be familiar with and comport with these. Um, also if you're not familiar with them before, the general procedures we are going to follow are described in RFCs 2026 and 2418, uh noted toward the end. We should all be familiar with those as well. If you have questions about the process that we follow, they are generally described in there. Um, did we have a slide about um participation? Um, generally speaking, it doesn't look like that's here, but generally speaking, that was the wrong agenda. Generally speaking, um, please keep yourself muted unless you are speaking, keep your video off unless you are participating, uh queue to speak, we'll manage the queue, one of us will manage the queue, um can we have a note-taker volunteer? We're only an hour today, I believe, so this this shouldn't be too intense. And the main thing to capture is any action items. We've relied on, I think, Laurie before. I don't know if she's here today. No.

Pete Resnick: Yeah, Laurie is in the in the list. But I'll be I'll be in there and uh keep an eye on it.

Murray Kucherawy: Okay, thank you.

Pete Resnick: All right.

Murray Kucherawy: Uh, was there any agenda bashing for the agenda that was sent around? It's only a few topics. We can go with those, I think. And pull that back up. All right. So, um, we have three topics to discuss. If anyone wants to insert or reorder these: which header fields to sign, interaction with DMARC, I don't think we we settled with last time, and we wanted to talk about deleting MIME parts, and the the topic of Merkle trees came up, and then AOB at the end, if there's any time for that. Does anyone have want to bash this either the set or the order? Or should we just get into it? Okay, um, the minutes were posted. I didn't see any objections other than the one correction Pete and I found, so we'll consider those uh permanent, or done, or sealed. Um, is there any Richard, do you want to take it from here for any discussion that has um has been germane to the to the header fields to sign discussion since last time?

Richard Clayton: Okay. Um, basically, what the specification version 2 02 says is that we sign all header fields apart from Received lines, uh apart from Return-Path, uh which it turns out uh I always thought was unique, but there are people who write a Return-Path and then do forwarding. Uh, so it matters uh that that it is excluded. Uh, we also wish to exclude uh the and the reason for excluding those is to allow you to send email through very naive uh forwarding systems which know SMTP and nothing else, uh and therefore, they're just going to add Received header fields uh and uh not mess with uh any other headers, they're not going to reorder anything, they're not going to mess with the body. Uh, and people do use those uh often for uh moving workloads around, that sort of thing, or just internally uh for uh moving things from one side of their wall to another. Uh, the second set of things we exclude are DKIM-Signature header fields and ARC header fields. The reason for excluding these is because it is it gives a lot of freedom to people who are who will be implementing uh DKIM2 in parallel with their existing uh DKIM systems, and by saying that uh uh obviously DKIM1 is not going to sign DKIM2 fields, uh or it would be very foolish of you to do so, um and uh if we make it vice versa, then you can do everything in any order you want, uh and it uh considerably simplifies uh things and allows people to chuck DKIM2 into their pipeline wherever it is convenient for them to do so. Uh, the third thing we wish to exclude is X- header fields. Uh, the reason for excluding these is because uh in general, they are meaningless outside the org that adds them, um and uh they are not, almost by definition these days, they are not standardized, will never be standardized, and they are widely used by uh particularly big mailbox providers but I'm sure smaller shops as well, uh for recording stuff uh for their own purposes uh inside of headers, uh and there doesn't seem much point in signing them if they don't mean anything to anybody else. Uh, and uh because these X- headers tend to be added in uh some organizations as they move mail around from one side of their org to another, uh it is uh it was made pretty clear to us, um, that uh if we required them to be signed, then this would slow down adoption uh at some major providers uh because of the way in which uh they use X- headers. So, we've so we've thought about this and decided we didn't want to sign them, so they're excluded. Uh, the final thing which we added in 02, which was not in 01 and has come up since the last interim, is that uh uh people who've been doing interop experiments, people who are here today, uh and they found that it was uh rather inconvenient that that Authentication-Results was getting signed. Uh, Authentication-Results uh by uh as documented in the RFC, as I'm sure Murray knows because I think he wrote it, um are are only mean something to somebody who is downstream of you, it doesn't mean anything to any other org, almost by definition, uh and uh it turns out, uh when you read up about it, is uh some people consider it best practice to strip off Authentication-Results headers as they come into their org uh and then they add in their own, uh but and that way, there's only one uh there's only one header field and therefore, it's easier for their internal systems to find it and to parse it and to take note of what it says. Uh, so we've added that as an exclusion, uh and uh the other of the uh people doing implementers here here have sighed with relief that we have done this because it simplifies their code uh considerably. Uh, so, that those are of the exclusions. Now, there are people who say, "What happens if after 50 years, we suddenly invent a new trace header? Wouldn't that be terrible because you'd have to sign it?" Which the answer is, "Yes, it would be terrible. Does anybody really seriously think that's going to happen?" Uh, there are people who want to be able to say, uh to go with the old DKIM1 style of uh saying what you have signed, and we have a lot of experience uh to the effect that we uh that people uh produce rather strange lists, uh and uh miss out things which actually matter, uh and philosophically, the the point is that you cannot know what security whether or not a header has security properties unless you are the receiver who is applying those security properties, uh and therefore, it's rather arrogant of uh sendenders to decide uh they know better than you do as to which headers have security properties and which ones can be left for random people to forge. Uh, and uh then there was some suggestions as to, "Well, perhaps you could say, 'I am signing this as well' as a sort of an addition over over the top." So, if you want to sign your favorite X- header, then you could say, "I'm signing this," uh except that the semantics of that gets spectacularly complicated if people further along uh don't actually take any notice of that and don't do it as to whether or not they are correct. Uh, so, those are basically the positions, uh and at the moment, the document says "all but" and there's really good justifications for the "all but," uh and uh people seem to be able to implement this just fine. And I'll stop there because I see there's a queue.

Pete Resnick: So, I got in the queue for two reasons: one, with chair hat on, um I believe as part of the minutes of the last meeting, we posted a the the sense of the room was sign all except list of, and um have the ability to say, "I have signed something that is in the list." Um, now, um I don't believe I heard anyone on the list yell about that, although it sounds like Richard just uh said he's kind of icked out by the last part, but I do want to hear from anybody who thinks we should do other than sign all except with a possible ability to um sign something that is in the list of exceptions. Does anybody want to stand up for that? And then we can get back to whether the list of exceptions, uh you know, can be signed in some other way. Bron, Murray? No, go ahead, I was just going to moderate. Go ahead, Bron.

Bron Gondwana: I'm standing up for um something slightly different, actually, which is that we could very easily define a new header, which would be captured by the list of and hence signed, which specifies the extra headers that you're signing and signs them itself. So, it would take a hash of those extra headers and put it into its header, which would get signed, and then that would automatically roll into the hash and all would be good. So, we don't need to do anything else. This is something that can be added later and will just automatically get picked up by our existing mechanism.

Pete Resnick: Interesting. John?

John Levine: Um, I was mostly offering to agree with everybody. As I said in the chat, I think we should add Delivered-To to the except list because it is, in fact, a a trace header, and postfix postfix adds it every time it passes through a postfix system. And I think I think Bron's suggestion makes sense. Like, if you really want to sign an X-header, like, that's fine, but that's that's your problem, and here's how you can do it.

Steve Atkins: I I don't have a solution, but I don't see how generically signing everything works without doing something like what Bron suggested because the reality is, so I'm one of the weird people in the world that actually look at all headers. My email reader is actually configured to show me all headers except for the list that I have excluded because they are, you know, too voluminous or too numerous that I finally decided to regex match against them to not show them to me. Do you know how long my regular expression list is for matching all of the headers that I don't want to see? It's huge. Right? The instant that the X-headers like went away because the suggestion is just now remove the X and continue making up your own headers. Everything under the sun seems to do it. So, so, even mail readers or mail transport agents in the middle somewhere that replace some header with a new value, you know, are not going to match. I fail to see how that's not going to work without an intelligent agent knowing what is safe to sign.

Bron Gondwana: I don't think there's much that changes those headers in flight, maybe there is, um if you add them then you need to specify that in your message instance. If you don't add or change them at all, you don't have to do anything other than just sign all the headers that are not in the exclusion list, which is a very simple piece of software. The the hard bit is if you start messing around with those types of things or adding them. And if you're adding them, you need to know you added them unless they already existed, then it's very easy. Your recipe is just to remove all instances. So, the hard bit is if you're changing someone else's header they've added, and that should be hard. Go ahead, Richard. Jump in.

Pete Resnick: Richard, you're on mute.

Richard Clayton: Um, there is a I I see Murray mentioning the fact that there is a uh a registry which includes uh trace fields, uh and tells you which what are trace fields. We explicitly avoided uh saying that that registry existed because we don't want the no anybody to get the idea that um every Monday morning, they have to go and read that registry and then reconfigure their system uh if somebody's added a new trace field uh because A, that would be very bad uh and and would not to work because nobody else would have gone and read it, and secondly, uh the notion that you go and look at this registry uh for anything other than uh sort of writing encyclopedias, um and uh you you should be reading the specification to write the code. Just to be clear about what I mean there, um it's harmless for you to sign stuff for the signer and the verifier to disagree on what is what counts as a trace field. You're going to verify whatever got signed, right? But the um the problem is that if you if the verifier is going to insist that trace fields be signed, and one of them wasn't, and you're not agreeing on what the trace fields are, that's where the problem comes in, I think. At least that's that's certainly the case for DKIM1. If you you decide to sign Return-Path or something like that, and that's a trace field, as long as you signed it and it's present, the verifier will still do the right thing. It depends on what your local policy is.

Pete Resnick: Wait, I don't understand that in the context of what's currently in the document. Currently, if you sign something that um is not supposed to be signed, when the other person verifies it, they're going to get a different value and and it's going to the

Murray Kucherawy: Yeah, I'm sorry, I've I think Bron I think set me straight. I've I had forgotten the part where the whole list of of is not in the it's not visible in the header field.

Pete Resnick: That's right.

Murray Kucherawy: Right. So, my mistake.

Pete Resnick: Okay.

Murray Kucherawy: Disregard. Disregard the last minute of our existences.

Pete Resnick: So, Bron, is your proposal in addition to or instead of?

Bron Gondwana: My proposal is that we don't need to do anything to allow people to sign additional header fields that are in the list of excluded header fields because they can just create a header, and we can specify that in a separate document if we want, so there's a standard way of doing it, that says, "Here is a hash of the following named headers," and just have that be something that is automatically included because it's not an X-dash and it's not in the specified list, and then that just gets signed and it all works.

Pete Resnick: Got it. Anybody else want to jump in? I'm at least not hearing that we're going back to the sender specifies what it's signed. No one is jumping up and down and screaming for that.

Bron Gondwana: Sir, I wanted to add one additional part to that, which is that the recipes in message instance can include header fields which are not signed. There's nothing stopping you including them in the recipe, um and so long as we say that you have to actually do that, if we do a if you create a recipe for Received headers, then that recipe needs to be applied to get the previous message regardless of whether it changes the signature at all. And I think that that that's all, but we do need to make sure we include that. Okay.

Pete Resnick: And Bron may want to join us in the uh in the note-taking room as well. Murray, do you think we are close to settled in this room and we can minute it?

Murray Kucherawy: Um, that's kind of my read, um um, I don't I'm not hearing anything that says otherwise. I'm not hearing any strong indications otherwise, let's put it that way.

Pete Resnick: Richard, you were the one who was uh creeped out by other ideas of how to say, "I signed something that's in the exception list." Does Bron's proposal work for you?

Richard Clayton: Well, we've effectively, you you you've already created a new header and then signing it, so that that should be just fine. What what freaks me out is the notion that somebody halfway along the chain says, "I am signing Received." Right. Right. I've no idea I think that just creates A, it's a damn foolish thing to do, and secondly, it won't interwork, uh so, uh we we'd have to sort of say you couldn't do that, and so forth, so uh it just gets very complicated. I might say that um I think this about the fourth time we've actually discussed this issue. Um, nobody apart from Bron has ever raised the issue on the list uh seriously once we got past the initial, "My goodness me, what did you do with the H equals field?" Right, it appeared in the minutes and that was it. Um, people said a few things but nobody ever came through with actually anything sensible. We now have running code, it all works, um, so I would like to not see this on the agenda again.

Pete Resnick: Okay, so I'm hearing the consensus of the room, and we'll post this very clearly. The consensus of the room is sign everything except what is in the exception list, and we can go with the current exception list and people can, you know, that they can we can fuss about. Um, and if you want to sign something that is in the exception list, you add it as a header, and it is signed according to Bron's proposal. Wei?

Wei Chuang: Yeah, so, I guess we're getting to that part, uh so, basically, I I would like to fuss around Bron's proposal. Um, I think it's a good idea. Uh, there's details of how to do that that I think we probably should talk about a bit. I mean, you know, there's there's other approaches, you might do a prefix and then like basically maybe hash all the things that have a prefix um, and, you know, I don't know if we were going to get into the exclusion list and when you mentioned fussing about, I don't know if we got to that step of I think fussing about the exclusion list we can do reasonably straightforwardly on the mailing list. I don't think we need to use interim time for it, um, you know, I think if you think there is something additional that should be on the exclusion list or something that should be removed, post something to the list and and we can go with, you know, a discussion there. I, you know, unless that turns out to be exceedingly controversial, I'm not too worried about doing it during interim time. Um, but I, you know, maybe a little bit of discussion of Bron's proposal um, and make sure we're at least zeroing in on where we think we're going here. Bron, do you want to respond to this? Or, wait, go ahead, and I I just wanted to add, I mean, and how this gets discussed exactly, so Bron's proposal adds a capability mechanism to create an exception to sign for things outside of this fixed thing in the specification, right? And I think how we go about doing that, we should discuss here or on the list and uh find a way to do that. I mean, I, for one, would like to go use those authentication results. Um, you know, in in basically arc authentication results is another way of doing these things, I like those, but um, you know, as opposed to authentication results headers. So, having some capability to preserve that and sign and protect those, I think, is a good idea. And I like Bron's proposal for being able to do that. Exactly how to do that, of course, there are some things I'd like to tweak, um, and I just mentioned one alternative approach, which is a prefix idea, and, you know, maybe putting that into a hash into some specified tag that could be part of the DKIM2 signature or like, you know, the the message instance. But whatever, I mean, those are details, and I guess I I just propose we do that discussion somewhere and designate a place to go do that. That's all.

Pete Resnick: My take is, um, you know, Bron, you should write up, um, you know, an insertable piece so that people can see it on the list. And yeah. Then uh we can discuss it on the list. If we need to, we'll use um uh next interim time or WG time to do it. Um, and my guess is Yeah. Um, as far as the which things to put in the exclusion list, um, way I would say write up, you know, any objections you have to what's in the current document, um post that, just start a thread on the exclusion list, and then uh go from there.

Wei Chuang: That's good.

Pete Resnick: All right. Murray, next topic.

Murray Kucherawy: Okay, we have um an a continuing discussion of DKIM2's relationship to DMARC um at the end of the last interim, um this from the minutes, Pete was saying this seems like an ongoing open issue. We'll have to figure out how to guide this discussion. Um, I can prime some chatter for today by saying I think the thing that was that struck me the most is the whole notion of what are we going to do about reporting because people, if this is going to go to sweep DMARC aside, someone might lose the reports, and that reporting structure is interesting. Do we want to consider how we're going to how we could continue that if DKIM takes over DMARC? What's the what's the thinking there? Um, the but anyway, the in any event, this is a an unresolved area, and I wondered if there's been any discussion that uh people want to bring to the mic about this today. Have we have we moved the needle on this topic anywhere in the last month or so? Bron.

Bron Gondwana: All right, I just popped myself straight in because I figured I'd be first in the queue. Um, my thinking on this hasn't changed at all. Basically, it is the signed traffic, you can put the signal of how you want it treated to a message in the signed stream, and that's fine. I think that having a DMARC policy for unsigned traffic is still valuable, and we we still need to have something like that, and I think they are the two pathways. The signed traffic has all the information in the signed message, and the unsigned, the rules for handling unsigned are published in the DNS with DMARC. Would that be um so, if you're How would we word that? Would be if you are participating in DKIM2, then you only apply DMARC to unsigned messages.

Bron Gondwana: Yeah, I think that sounds right, and that you apply the DKIM2 rules um specified in the in the signed original DKIM2 signature to passing DKIM2 messages, which include the do not modify and the do not explode. Okay. Okay, Wei.

Wei Chuang: Yeah, so, basically, um, I wanted an additional clarity besides just, you know, reporting around the notion of what is this From header identity, and I think the challenge and the benefit of DKIM2 is that it actually has the capability of uh maintaining and and preserving that From header all the way back through a forwarding path that modifies the messages, modifies the From header. There's a lot of capability there, but it remains unspecified as to in some sense how to recover that, I think. Uh, especially with respect to what is considered, you know, a DMARC uh From identity. And I think it's so beyond just reporting, I think we we need to understand, you know, if there can be a way of of preserving that, and I think there's a lot of value in that actually, in authenticating traffic, um, you know, that identity is in some sense, you know, the the party that started the message that that got to you, uh it may have changed identities because of workarounds due to, you know, the the the old version of DMARC, and that's still that this version or the updated I don't remember the new RFC number, also still has that property. People are trying to work around that, and that actually breaks that identity quite a bit by rewriting the From. Uh, so, I think, you know, we do need to evaluate uh how DKIM2 affects uh DMARC, and I think there's a lot of value in that because, as I like I said, I think that identity is very important. Um, I think, yeah, it's also true that the reporting uh is affected by all this, and we should also specify that, and largely what I'm saying is that we do need to do a bit of work here to to do that, and I think it is valuable, and we should be pursuing it. Richard.

Richard Clayton: Okay. Um, the issue uh with reporting is that some people consider it quite valuable uh not just for the unsigned stuff but for the signed stuff because it allows them to track down rogue parts of their organization who have a key or whatever and are using it. Uh, so, uh I don't think uh there'll be a huge amount of enthusiasm across the industry for having the reporting only cover some aspects of the of the mail flows. That's first thing. Second thing is that uh in the fullness of time, and uh you you can talk to product people as to what that fullness might be, um then nobody is going to then large mailbox providers, the Yahoo, Google of this world, are not going to be interested in DKIM1 uh signatures at all. They're only going to be interested in DKIM2 signatures uh at which point all mail is inherently authenticated uh as it arrives uh in uh to those mailboxes, uh and from that point of view, uh there is less uh the one of the things that does is it means that SPF uh doesn't do what it does today, which is to allow people send from some other part of a cloud uh and impersonate people. Uh, so, uh I I think the world is going to change with DMARC. DMARC, uh as people said, is still going to have a a policy aspect in terms of what it says. I think that there may be some enthusiasm for uh revisiting uh reporting in general, uh in the light of the fact that DKIM2 does actually have a "I would like to receive reports" flag added into it, uh which is specific to the uh particular uh machines or systems, organizations, on that path which actually want to get the reporting. Because at the moment, uh in the sort of reporting that um Yahoo, for take one, an example, for reporting that does is to anybody who has put a valid DKIM signature onto the message uh and that is really expensive to do uh because you're sending reports to people who don't necessarily wish to receive them. Uh, so, I think that there will be much more uh interest in visiting the reporting side when we start seeing what feedback loops look like, and the specification documents specifically avoid saying anything about what a feedback loop is, uh but uh certainly the industry, the sending industry, is extremely interested in getting feedback from uh mailbox providers as to what happened to that mail. Not just whether or not it was delivered or whether it was seen, but where it was put uh and what the user thought of it. So, Richard, you you have a queue developing here, and I'll ask people to make more bite-size uh comments.

Richard Clayton: Okay, sorry. Um.

Pete Resnick: Can always come back in the queue.

Richard Clayton: I I didn't do slides for this, so I'm rambling.

Murray Kucherawy: Uh, Bron, go ahead.

Bron Gondwana: Ah, okay. I'll give you my face just just for a moment at least. Hi. Um, to for part of what Richard was saying there, yes, I think that's really valuable. The inline, um not the first hop, reporting request is something that DKIM2 will add that we don't have at the moment, but I do, I have been persuaded by the discussion in the chat that we do need to allow organizations who have such poor internal controls over who has keys that are published in their DNS that they can't tell who's sending email on their behalf to have a way to do a policy lookup and see who's sending email on their behalf still. Um, you could say some some mean things about their ability to to track their key management, but that's the world we live in. Um, so, I think we we still do need to accept that for the first hop.

Murray Kucherawy: Laura.

Laura A: That was basically what I was going to say is that, you know, if you're looking at a large university or if you're looking at a government organization, there are a lot of people who, you know, can go talk to the DNS folks and get something added to DNS, and then the person who's actually responsible for the mail doesn't know what's going on. So, if there is a way for an organization, and I think this does go back to the how are we going to track the initial that first From address, like, that source of the email, but I think that this is a discussion that we need to keep having and and develop a way to get those reports back. And maybe it is just to piggyback it off of what DMARC has done, or maybe it's another type of reporting that comes out because there are some messy organizations out there with, you know, a lot of different email streams, um and they're doing different DKIM signatures, you know, you can have different D equals, and you can have different domains, and so, we need to kind of figure that bit out because those reports are so valuable to folks inside the organization who are trying to manage the outbound mail.

Murray Kucherawy: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it uh accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: My take is, um, you know, Bron, you should write up, um, you know, an insertable piece so that people can see it on the list, and yeah. Then uh we can discuss it on the list. If we need to, we'll use um uh next interim time or WG time to do it. Um, and my guess is Yeah. Um, as far as the which things to put in the exclusion list, um, way I would say write up, you know, any objections you have to what's in the current document, um post that, just start a thread on the exclusion list, and then uh go from there.

Wei Chuang: That's good.

Pete Resnick: All right. Murray, next topic.

Murray Kucherawy: Okay, we have um an a continuing discussion of DKIM2's relationship to DMARC um at the end of the last interim, um this from the minutes, Pete was saying this seems like an ongoing open issue. We'll have to figure out how to guide this discussion. Um, I can prime some chatter for today by saying I think the thing that was that struck me the most is the whole notion of what are we going to do about reporting because people, if this is going to go to sweep DMARC aside, someone might lose the reports, and that reporting structure is interesting. Do we want to consider how we're going to how we could continue that if DKIM takes over DMARC? What's the thinking there? Um, the but anyway, the in any event, this is a an unresolved area, and I wondered if there's been any discussion that uh people want to bring to the mic about this today. Have we have we moved the needle on this topic anywhere in the last month or so? Bron.

Richard Clayton: Okay, sorry. Um.

Pete Resnick: Can always come back in the queue.

Richard Clayton: I I didn't do slides for this, so I'm rambling.

Murray Kucherawy: Uh, Bron, go ahead.

Murray Kucherawy: Laura.

Murray Kucherawy: Wei.

Pete Resnick: So, I'll take a quick chair interrupt since we've now get into a chartering issue and I want to drag Andy into this as well since he happens to be in the room. Um, you know, if we see that, okay, in order to use DKIM2, we're going to have DMARC around and we're going to want DMARC to be able to, as Wei said, say, "I use DKIM2 when I don't use SPF," that's going to require DMARC changes which are out of our scope, I believe.

Andy Newton: Well, I was already groaning on on that at this time. I heard it, even though you were muted. Uh, I I think at that point, we we recharter this working group. Uh, DMARC is it's we're trying to kill it. Um, and so it's got one last mission. Barry's working very hard on that last mission, and then we're trying to close it out.

Pete Resnick: Okay, so, we is your recommendation we put this in abeyance and then, uh after DMARC closes down, we then go to recharter this to add a little thing that says, "This group may also, um, you know, uh describe how, uh you know, describe changes to DMARC in order to accommodate the the new version of DKIM."

Andy Newton: That that is where I would go with this, and uh unless uh like, someone like Barry has a uh a better idea or a different idea, that's how I would do this.

Barry Leiba: No one like me exists, so what can I say? I have no better idea.

Murray Kucherawy: Uh, Bron.

Bron Gondwana: Yeah, I think that's really valuable, the inline, um not the first hop, reporting request is something that DKIM2 will add that we don't have at the moment, but I do, I have been persuaded by the discussion in the chat that we do need to allow organizations who have such poor internal controls over who has keys that are published in their DNS that they can't tell who's sending email on their behalf to have a way to do a policy lookup and see who's sending email on their behalf still. Um, you could say some some mean things about their ability to to track their key management, but that's the world we live in, um, so, I think we we still do need to accept that for the first hop.

Murray Kucherawy: Laura.

Murray Kucherawy: Wei.

Wei Chuang: That's good.

Pete Resnick: All right. Murray, next topic.

Murray Kucherawy: Okay, we have um an a continuing discussion of DKIM2's relationship to DMARC um at the end of the last interim, um this from the minutes, Pete was saying this seems like an ongoing open issue. We'll have to figure out how to guide this discussion. Um, I can prime some chatter for today by saying I think the thing that was that struck me the most is the whole notion of what are we going to do about reporting because people, if this is going to go to sweep DMARC aside, someone might lose the reports, and that reporting structure is interesting. Do we want to consider how we're going to how we could continue that if DKIM takes over DMARC? What's the thinking there? Um, the but anyway, the in any event, this is a an unresolved area, and I wondered if there's been any discussion that uh people want to bring to the mic about this today. Have we have we moved the needle on this topic anywhere in the last month or so? Bron.

Richard Clayton: Okay, sorry. Um.

Pete Resnick: Can always come back in the queue.

Richard Clayton: I I didn't do slides for this, so I'm rambling.

Murray Kucherawy: Uh, Bron, go ahead.

Murray Kucherawy: Laura.

Murray Kucherawy: Wei.

Andy Newton: That that is where I would go with this, and uh unless uh like, someone like Barry has a uh a better idea or a different idea, that's how I would do this.

Barry Leiba: No one like me exists, so what can I say? I have no better idea.

Murray Kucherawy: Uh, Bron.

Murray Kucherawy: Laura.

Murray Kucherawy: Wei.

Andy Newton: That that is where I would go with this, and uh unless uh like, someone like Barry has a uh a better idea or a different idea, that's how I would do this.

Barry Leiba: No one like me exists, so what can I say? I have no better idea.

Murray Kucherawy: Okay, so, we'll we'll summarize that to the list and I think, in addition to the minutes, um, you know, with each of these things that we now think are really kind of honing in on consensus, Murray or I will post an individual message to the list saying, "Okay, here here's what we're hearing in the interims and uh we need to have someone, in this case, take on writing up some use cases and convince everybody that it's worth the investment." Any other comments on this topic? No.

Murray Kucherawy: Um, we're up to AOB and I need to depart the call for another meeting, but the only thing I wanted to make sure we talked about is do we want to do another interim between now and Vienna? There's still a month or six weeks to go. It would be basically an interim three two or three weeks before the meeting. Yeah. If people think is it worth it, Bron?

Bron Gondwana: I was going to say yes, I think it is, that we've had enough new material come up from this. It would be good to give it another rinse before we get to Vienna. Sure.

Murray Kucherawy: Okay. Murray and I will try and pick a date. Yeah, I'll try and gray in the chat. I'll uh we'll figure out what the minimum allowable notice is and we'll we'll set the meeting up for that.

Pete Resnick: Yeah, as Andy says, we can always cancel. Okay, I'll take the call from here, but all we're going to do is check for any other business. Thanks for hanging on, Murray.

Murray Kucherawy: You bet.

Andy Newton: Try to make it try to make it two weeks.

Pete Resnick: What's that?

Andy Newton: The the two the minimum should be two weeks. Although, I think technically it's not, but whatever.

Pete Resnick: Okay, yeah. Um, okay, so, we will get, you know, pick a date, get an announcement out, and then we can always decide that we've run out of things uh, you know, that really need time before uh before Vienna and just move them onto there. Um, so, it is AOB time. Anybody have any other business? Go ahead, Wei.

Wei Chuang: Yeah, so, I put out something out on the list, um, basically about multiple uh supporting multiple domains in in a header. Um, basically, there's some scenarios where uh basically, for either enterprise signing or for uh bulk sending, uh basically, you may need to have multiple signers in an ADMD and uh I put out um, you know, some text. I mean, it was sent out relatively close to the interim, so I can understand why maybe not a lot of people saw it, and I'm happy also to just take this at the next interim too, but I figured it's worth discussing um and seeing if there is interest in updating the spec to account for these different approaches. So, basically, I put out two different approaches. Um, there's the one where you literally take the D equals and collapse it into the signature. Instead of having three parts to the signature, you also include now a domain part. Another way uh is to just strip off uh and this is a little bit in in practice is pretty simple, but I guess it's it's hard to describe actually, uh without writing it up, I think. But basically taking off the local part for what would be considered the uh header created to handle the multiple signatures. That's the way to link together this chain of custody. So, just wanted to see if we have time to discuss this here. Um, if not, we can wait to the next interim, and hopefully, I've discussed it well enough to actually have a discussion.

Pete Resnick: Anybody read Wei's stuff well enough to have comments here? Richard?

Richard Clayton: Um, Wei's message is entirely clear. Uh, the uh I'm I'm in favor of my simple solution rather than Wei's more complicated solution. In particular, uh what one should note is that the uh a registry which includes uh trace fields uh and tells you which what are trace fields, we explicitly avoided uh saying that that registry existed because we don't want the no anybody to get the idea that um every Monday morning, they have to go and read that registry and then reconfigure their system uh if somebody's added a new trace field uh because A, that would be very bad uh and and would not to work because nobody else would have gone and read it, and secondly, uh the notion that you go and look at this registry uh for any other thing than uh sort of writing encyclopedias, um and uh you you should be reading the specification to write the code. Just to be clear about what I mean there, um it's harmless for you to sign stuff for the signer and the verifier to disagree on what is what counts as a trace field. You're going to verify whatever got signed, right? But the um the problem is that if you if the verifier is going to insist that trace fields be signed, and one of them wasn't, and you're not agreeing on what the trace fields are, that's where the problem comes in, I think. At least that's that's certainly the case for DKIM1. If you you decide to sign Return-Path or something like that, and that's a trace field, as long as you signed it and it's present, the verifier will still do the right thing. It depends on what your local policy is.

Murray Kucherawy: Yeah, I'm sorry, I've I think Bron I think set me straight. I've I had forgotten the part where the whole list of of is not in the it's not visible in the header field.

Pete Resnick: That's right.

Murray Kucherawy: Right. So, my mistake.

Pete Resnick: Okay.

Murray Kucherawy: Disregard. Disregard the last minute of our existences.

Pete Resnick: So, Bron, is your proposal in addition to or instead of?

Pete Resnick: Got it. Anybody else want to jump in? I'm at least not hearing that we're going back to the sender specifies what it's signed. No one is jumping up and down and screaming for that.

Pete Resnick: And Bron may want to join us in the uh in the note-taking room as well. Murray, do you think we are close to settled in this room and we can minute it?

Murray Kucherawy: Um, that's kind of my read, um um, I don't I'm not hearing anything that says otherwise. I'm not hearing any strong indications otherwise, let's put it that way.

Pete Resnick: Richard, you were the one who was uh creeped out by other ideas of how to say, "I signed something that's in the exception list." Does Bron's proposal work for you?

Pete Resnick: Okay, so i'm hearing the consensus of the room, and we'll post this very clearly. The consensus of the room is sign everything except what is in the exception list, and we can go with the current exception list and people can, you know, that they can we can fuss about. Um, and if you want to sign something that is in the exception list, you add it as a header, and it is signed according to Bron's proposal. Wei?

Wei Chuang: That's good.

Pete Resnick: All right. Murray, next topic.

Murray Kucherawy: Okay, we have um an a continuing discussion of DKIM2's relationship to DMARC um at the end of the last interim, um this from the minutes, Pete was saying this seems like an ongoing open issue. We'll have to figure out how to guide this discussion. Um, I can prime some chatter for today by saying I think the thing that was that struck me the most is the whole notion of what are we going to do about reporting because people, if this is going to go to sweep DMARC aside, someone might lose the reports, and that reporting structure is interesting. Do we want to consider how we're going to how we could continue that if DKIM takes over DMARC? What's the thinking there? Um, the but anyway, the in any event, this is a an unresolved area, and I wondered if there's been any discussion that uh people want to bring to the mic about this today. Have we have we moved the needle on this topic anywhere in the last month or so? Bron.

Richard Clayton: Okay, sorry. Um.

Pete Resnick: Can always come back in the queue.

Richard Clayton: I I didn't do slides for this, so I'm rambling.

Murray Kucherawy: Uh, Bron, go ahead.

Bron Gondwana: Ah, okay. I'll give you my face just just for a moment at least. Hi. Um, to for part of what Richard was saying there, yes, I think that's really valuable. The inline, um not the first hop, reporting request is something that DKIM2 will add that we don't have at the moment, but I do, I have been persuaded by the discussion in the chat that we do need to allow organizations who have such poor internal controls over who has keys that are published in their DNS that they can't tell who's sending email on their behalf to have a way to do a policy lookup and see who's sending email on their behalf still. Um, you could say some some mean things about their ability to to track their key management, but that's the world we live in, um, so, I think we we still do need to accept that for the first hop.

Murray Kucherawy: Laura.

Murray Kucherawy: Wei.

Andy Newton: That that is where I would go with this, and uh unless uh like, someone like Barry has a uh a better idea or a different idea, that's how I would do this.

Barry Leiba: No one like me exists, so what can I say? I have no better idea.

Pete Resnick: Okay, so we'll we'll summarize that to the list and I think, in addition to the minutes, um, you know, with each of these things that we now think are really kind of honing in on consensus, Murray or I will post an individual message to the list saying, "Okay, here here's what we're hearing in the interims and uh we need to have some in this case, take on writing up some use cases and convince everybody that it's worth the investment." Any other comments on this topic? No.

Bron Gondwana: I was going to say yes, I think it is, that we've had enough new material come up from this. It would be good to give it another rinse before we get to Vienna. Sure.

Pete Resnick: Yeah, as Andy says, we can always cancel. Okay, I'll take the call from here, but all we're going to do is check for any other business. Thanks for hanging on, Murray.

Murray Kucherawy: You bet.

Andy Newton: Try to make it try to make it two weeks.

Pete Resnick: What's that?

Andy Newton: The the two the minimum should be two weeks. Although, I think technically it's not, but whatever.

Pete Resnick: Okay, yeah. Um, okay, so, we will get, you know, pick a date, get an announcement out, and then we can always decide that we've run out of things uh, you know, that really need time before uh before Vienna and just move them on to there. Um, so, it is AOB time. Anybody have any other business? Go ahead, Wei.

Pete Resnick: Anybody read Wei's stuff well enough to have comments here? Richard?

Richard Clayton: Um, Wei's message is entirely clear. Uh, the uh I'm I'm in favor of my simple solution rather than Wei's more complicated solution. In particular, uh what one should note is that the uh when we write down the uh when we check a domain, the domain which is for the signature uh is required to match with the domain or a subdomain of the mail From, and when you're doing two signatures in a row, there is of course no SMTP link between those two events, and there's no From and therefore the local part is actually uh useless, uh so, uh allowing people to remove it uh will avoid people thinking that um it is a real mail email address and means something, uh so, uh that would be quite convenient to do. The other thing which we do with these things is we check these things match up more generally uh for the From, uh and uh if you have two signatures sitting there, then it's not clear to me if there is no mail From because it is a bounce whether or not uh which one you have to which one you match with, um and I think there's a hole there through which uh badness might happen. So, I much rather stick with the simple scheme of one one at each stage, and then there's no question of asking which one comes first and whether or not it has slightly more better properties than the other one. Bron?

Bron Gondwana: Yeah, I I think we do need to solve this, and I I'm moving towards the you just don't say a Receipt-To, you just don't say From for the connected signatures, and you know that you're the next signature the next signer on there. I guess, the issue there is the you don't someone could falsify that. They could pretend that they had been the next signature in that case. Um, but we need to figure out some way to combine them together. I don't have a good answer to it other than we should work on it.

Wei Chuang: That's good.

Pete Resnick: All right. Murray, next topic.

Murray Kucherawy: Okay, we have um an a continuing discussion of DKIM2's relationship to DMARC um at the end of the last interim, um this from the minutes, Pete was saying this seems like an ongoing open issue. We'll have to figure out how to guide this discussion. Um, I can prime some chatter for today by saying I think the thing that was that struck me the most is the whole notion of what are we going to do about reporting because people, if this is going to go to sweep DMARC aside, someone might lose the reports, and that reporting structure is interesting. Do we want to consider how we're going to how we could continue that if DKIM takes over DMARC? What's the thinking there? Um, the but anyway, the in any event, this is a an unresolved area, and I wondered if there's been any discussion that uh people want to bring to the mic about this today. Have we have we moved the needle on this topic anywhere in the last month or so? Bron.

Richard Clayton: Okay, sorry. Um.

Pete Resnick: Can always come back in the queue.

Richard Clayton: I I didn't do slides for this, so I'm rambling.

Murray Kucherawy: Uh, Bron, go ahead.

Bron Gondwana: Ah, okay. I'll give you my face just just for a moment at least. Hi. Um, to for part of what Richard was saying there, yes, I think that's really valuable. The inline, um not the first hop, reporting request is something that DKIM2 will add that we don't have at the moment, but I do, I have been persuaded by the discussion in the chat that we do need to allow organizations who have such poor internal controls over who has keys that are published in their DNS that they can't tell who's sending email on their behalf to have a way to do a policy lookup and see who's sending email on their behalf still. Um, you could say some some mean things about their ability to to track their key management, but that's the world we live in, um, so, I think we we still do need to accept that for the first hop.

Murray Kucherawy: Laura.

Murray Kucherawy: Wei.

Andy Newton: That that is where I would go with this, and uh unless uh like, someone like Barry has a uh a better idea or a different idea, that's how I would do this.

Barry Leiba: No one like me exists, so what can I say? I have no better idea.

Bron Gondwana: I was going to say yes, I think it is, that we've had enough new material come up from this. It would be good to give it another rinse before we get to Vienna. Sure.

Pete Resnick: Yeah, as Andy says, we can always cancel. Okay, I'll take the call from here, but all we're going to do is check for any other business. Thanks for hanging on, Murray.

Murray Kucherawy: You bet.

Andy Newton: Try to make it try to make it two weeks.

Pete Resnick: What's that?

Andy Newton: The the two the minimum should be two weeks. Although, I think technically it's not, but whatever.

Pete Resnick: Okay, yeah. Um, okay, so, we will get, you know, pick a date, get an announcement out, and then we can always decide that we've run out of things uh, you know, that really need time before uh before Vienna and just move them on to there. Um, so, it is AOB time. Anybody have any other business? Go ahead, Wei.

Pete Resnick: Anybody read Wei's stuff well enough to have comments here? Richard?

Richard Clayton: Um, Wei's message is entirely clear. Uh, the uh I'm I'm in favor of my simple solution rather than Wei's more complicated solution. In particular, uh what one should note is that the uh when we write down the uh when we check a domain, the domain which is for the signature uh is required to match with the domain or a subdomain of the mail From, and when you're doing two signatures in a row, there is of course no SMTP link between those two events, and there's no From and therefore the local part is actually uh useless, uh so, uh allowing people to remove it uh will avoid people thinking that um it is a real mail email address and means something, uh so, uh that would be quite convenient to do. The other thing which we do with these things is we check these things match up more generally uh for the From, uh and uh if you have two signatures sitting there, then it's not clear to me if there is no mail From because it is a bounce whether or not uh which one you have to which one you match with, um and I think there's a hole there through which uh badness might happen. So, I much rather stick with the simple scheme of one one at each stage, and then there's no question of asking which one comes first and whether or not it has slightly more better properties than the other one. Bron?

Wei Chuang: That's good.

Pete Resnick: All right. Murray, next topic.

Murray Kucherawy: Okay, we have um an a continuing discussion of DKIM2's relationship to DMARC um at the end of the last interim, um this from the minutes, Pete was saying this seems like an ongoing open issue. We'll have to figure out how to guide this discussion. Um, I can prime some chatter for today by saying I think the thing that was that struck me the most is the whole notion of what are we going to do about reporting because people, if this is going to go to sweep DMARC aside, someone might lose the reports, and that reporting structure is interesting. Do we want to consider how we're going to how we could continue that if DKIM takes over DMARC? What's the thinking there? Um, the but anyway, the in any event, this is a an unresolved area, and I wondered if there's been any discussion that uh people want to bring to the mic about this today. Have we have we moved the needle on this topic anywhere in the last month or so? Bron.

Richard Clayton: Okay, sorry. Um.

Pete Resnick: Can always come back in the queue.

Richard Clayton: I I didn't do slides for this, so I'm rambling.

Murray Kucherawy: Uh, Bron, go ahead.

Bron Gondwana: Ah, okay. I'll give you my face just just for a moment at least. Hi. Um, to for part of what Richard was saying there, yes, I think that's really valuable. The inline, um not the first hop, reporting request is something that DKIM2 will add that we don't have at the moment, but I do, I have been persuaded by the discussion in the chat that we do need to allow organizations who have such poor internal controls over who has keys that are published in their DNS that they can't tell who's sending email on their behalf to have a way to do a policy lookup and see who's sending email on their behalf still. Um, you could say some some mean things about their ability to to track their key management, but that's the world we live in, um, so, I think we we still do need to accept that for the first hop.

Murray Kucherawy: Laura.

Andy Newton: That that is where I would go with this, and uh unless uh like, someone like Barry has a uh a better idea or a different idea, that's how I would do this.

Barry Leiba: No one like me exists, so what can I say? I have no better idea.

Bron Gondwana: I was going to say yes, I think it is, that we've had enough new material come up from this. It would be good to give it another rinse before we get to Vienna. Sure.

Pete Resnick: Yeah, as Andy says, we can always cancel. Okay, I'll take the call from here, but all we're going to do is check for any other business. Thanks for hanging on, Murray.

Murray Kucherawy: You bet.

Andy Newton: Try to make it try to make it two weeks.

Pete Resnick: What's that?

Andy Newton: The the two the minimum should be two weeks. Although, I think technically it's not, but whatever.

Pete Resnick: Okay, yeah. Um, okay, so, we will get, you know, pick a date, get an announcement out, and then we can always decide that we've run out of things uh, you know, that really need time before uh before Vienna and just move them on to there. Um, so, it is AOB time. Anybody have any other business? Go ahead, Wei.

Pete Resnick: Anybody read Wei's stuff well enough to have comments here? Richard?

Richard Clayton: Um, Wei's message is entirely clear. Uh, the uh I'm I'm in favor of my simple solution rather than Wei's more complicated solution. In particular, uh what one should note is that the uh when we write down the uh when we check a domain, the domain which is for the signature uh is required to match with the domain or a subdomain of the mail From, and when you're doing two signatures in a row, there is of course no SMTP link between those two events, and there's no From and therefore the local part is actually uh useless, uh so, uh allowing people to remove it uh will avoid people thinking that um it is a real mail email address and means something, uh so, uh that would be quite convenient to do. The other thing which we do with these things is we check these things match up more generally uh for the From, uh and uh if you have two signatures sitting there, then it's not clear to me if there is no mail From because it is a bounce whether or not uh which one you have to which one you match with, um and I think there's a hole there through which uh badness might happen. So, I much rather stick with the simple scheme of one one at each stage, and then there's no question of asking which one comes first and whether or not it has slightly more better properties than the other one. Bron?

Wei Chuang: That's good.

Pete Resnick: All right. Murray, next topic.

Murray Kucherawy: Okay, we have um an a continuing discussion of DKIM2's relationship to DMARC um at the end of the last interim, um this from the minutes, Pete was saying this seems like an ongoing open issue. We'll have to figure out how to guide this discussion. Um, I can prime some chatter for today by saying I think the thing that was that struck me the most is the whole notion of what are we going to do about reporting because people, if this is going to go to sweep DMARC aside, someone might lose the reports, and that reporting structure is interesting. Do we want to consider how we're going to how we could continue that if DKIM takes over DMARC? What's the thinking there? Um, the but anyway, the in any event, this is a an unresolved area, and I wondered if there's been any discussion that uh people want to bring to the mic about this today. Have we have we moved the needle on this topic anywhere in the last month or so? Bron.

Richard Clayton: Okay, sorry. Um.

Pete Resnick: Can always come back in the queue.

Richard Clayton: I I didn't do slides for this, so I'm rambling.

Murray Kucherawy: Uh, Bron, go ahead.

Bron Gondwana: Ah, okay. I'll give you my face just just for a moment at least. Hi. Um, to for part of what Richard was saying there, yes, I think that's really valuable. The inline, um not the first hop, reporting request is something that DKIM2 will add that we don't have at the moment, but I do, I have been persuaded by the discussion in the chat that we do need to allow organizations who have such poor internal controls over who has keys that are published in their DNS that they can't tell who's sending email on their behalf to have a way to do a policy lookup and see who's sending email on their behalf still. Um, you could say some some mean things about their ability to to track their key management, but that's the world we live in, um, so, I think we we still do need to accept that for the first hop.

Murray Kucherawy: Laura.

Andy Newton: That that is where I would go with this, and uh unless uh like, someone like Barry has a uh a better idea or a different idea, that's how I would do this.

Barry Leiba: No one like me exists, so what can I say? I have no better idea.

Bron Gondwana: I was going to say yes, I think it is, that we've had enough new material come up from this. It would be good to give it another rinse before we get to Vienna. Sure.

Pete Resnick: Yeah, as Andy says, we can always cancel. Okay, I'll take the call from here, but all we're going to do is check for any other business. Thanks for hanging on, Murray.

Murray Kucherawy: You bet.

Andy Newton: Try to make it try to make it two weeks.

Pete Resnick: What's that?

Andy Newton: The the two the minimum should be two weeks. Although, I think technically it's not, but whatever.

Pete Resnick: Okay, yeah. Um, okay, so, we will get, you know, pick a date, get an announcement out, and then we can always decide that we've run out of things uh, you know, that really need time before uh before Vienna and just move them on to there. Um, so, it is AOB time. Anybody have any other business? Go ahead, Wei.

**Wei Chuang:**Wei Chuang: Yeah, so I put out some text, I mean it was sent out relatively close to the interim, so I can understand why maybe not a lot of people saw it, and I'm happy also to just take this at the next interim too, but I figured it's worth discussing, um, and seeing if there is interest in updating the spec to account for these different approaches. So basically I put out two different approaches. Um, there's the one where you literally take the d-equals and collapse it into the signature. Instead of having three parts to the signature, you also include now a domain part. Another way, uh, is to just strip off, uh, and this is a little bit, in, in practice is pretty simple, but I guess it's, it's hard to describe actually, uh, without writing it up, I think. But basically taking off the local part for what would be considered the, uh, header created to handle the multiple signatures. That's the way to link together this chain of custody. So just wanted to see if we have time to discuss this here. Um, if not, we can wait to the next interim, and hopefully I've discussed it well enough to actually have a discussion.

Pete Resnick: Anybody read Wei's stuff well enough to have comments here? Richard?

Richard Clayton: Um, Wei's message is entirely clear. Uh, the, uh, I'm, i'm in favor of my simple solution rather than Wei's more complicated solution. In particular, uh, what one should note is that the, uh, when we write down the, uh, when we check a domain, the domain which is for the signature, uh, is required to match with the domain or a subdomain of the Mail From, and when you're doing two signatures in a row, there is of course no SMTP link between those two events, and there's no From, and therefore the local part is actually, uh, useless. Uh, so, uh, allowing people to remove it, uh, will avoid people thinking that, um, it is a real mail, email address, and means something. Uh, so, uh, that would be quite convenient to do. The other thing which we do with these things is we check these things match up more generally, uh, for the From. Uh, and, uh, if you have two signatures sitting there, then it's not clear to me if there is no Mail From because it is a bounce, whether or not, uh, which one you have to, which one you match with, um, and I think there's a hole there through which, uh, badness might happen, so I much rather stick with the simple scheme of one, one at each stage, and then there's no question of asking which one comes first and whether or not it has slightly more better properties than the other one.

Pete Resnick: Bron?

Bron Gondwana: Yeah, I, I think we do need to solve this, and I, i'm moving towards the, you just don't say a Receipt-To, you just don't say From for the connected signatures, and you know that you're the next signature, the next signer on there. I guess the issue there is the, you don't, someone could falsify that. They could pretend that they had been the next signature in that case. Um, but we need to figure out some way to combine them together. I don't have a good answer to it other than we should work on it.

Pete Resnick: Go ahead, Richard, just jump in.

Pete Resnick: Richard, you're on mute.

Richard Clayton: Um, with my day job hat on, I spend my life staring at mail which has come through intermediaries, uh, I pay a lot of attention to whether or not, uh, there are DKIM passes, uh, DMARC passes, and so forth. Uh, but if I want to know whether or not, uh, what when email is handed off to me, I pay a great deal of attention to the IP address which gave it to me because that tells me who, who gave it to me, and I have a look-up table which allows me to map that IP address to an ESP or to, um, uh, people like SpamExperts and so forth, who pro- um, who provide filtering services to customers and that sort of thing. And I pay a lot of attention to that. I'm not interested in the slightest in reading DKIM signatures for that, and I'm not interested in what the, uh, what the actual contractual relationship is between, uh, uh, Mailgun or a SendGrid of this world, uh, or, or, a SpamExperts or whatever, uh, and the, and the brand. I'm just interested in whether or not it was good email and whether or not, uh, the person give it to me is giving it to me in a reputable way.

Pete Resnick: So, so that is to answer Brian by saying, "I don't have any need for it."

Richard Clayton: Yeah, I, I have no need to know what Bron's relationship is, and i think Bron, in fact, is often sitting as a third hop, uh, because the ESP is contracting out their actual sending to, uh, to him, and then, I may be misrepresenting his, I've talked to him for, for years now, and i'm not really sure.

Pete Resnick: Go ahead, Bron.

Bron Gondwana: Yeah, Bron. It gets confusing. I think, and that's why you might not be able to determine what that relationship means, right? By having multiple domains that sign together may or may not mean something more. Um, I can see the theoretical value, uh, in making that determination. I guess, Wei, can to go back and, and to ask you a question, Wei, is there was some enterprise for- like other cases besides the bulk sender case, can, um, you review those a little bit more, and explain that, possibly?

Pete Resnick: Go ahead and jump in, Wei, and then we'll go to Tara after that.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, i suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Tara Whalen: Ah, can you hear me? Uh, oh, okay. Um, just to respond to what Richard said, um, I find it interesting that there's, there's no necessity to know what the relationship is, but isn't it important just to know that there is a relationship? That this one entity is saying that they are responsible for the mail of another entity. I mean, I, I know the whole reason why we double signed or over-signed or whatever you want to call it, um, originally, was so that the email service provider could get feedback loops for their customers because they can't depend on having their customers send them the feedback that might incriminate them. Um, so, is it important just to know that there is a relationship there?

Pete Resnick: Richard.

Richard Clayton: No, uh, the, the lawyers said they don't care about the relationship, they just know that you saw the mail as it went past you, uh, because you have put a signature on it, therefore you must have seen the body of the, the whole of the email, uh, because otherwise you couldn't create the signature, hence you know all about it already, and therefore, there is no privacy breach in telling you information about what happened to the mail thereafter. So, it's not a relationship, it's the fact that you saw it.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Richard Clayton: Yeah, um, going back to the, the forwarding stuff, um, uh, I would agree with, uh, what happens in, in the real world is people have a Google account, uh, and then they, they decide to read all their email at Yahoo, so they get set up their Google account to forward everything automatically to Yahoo, uh, and then they set up their Yahoo account to forward everything automatically to, uh, Outlook, or, or to Hotmail, uh, and then they arrange for Hotmail to forward it all to Google, and it goes round in a circle for the rest of the day, uh, until it accumulates enough Received lines to be blocked. Um, and, and i'm not joking, people do that. Um, and, uh, this actually does produce a problem for, uh, the DSNs because, uh, when you get the DSN back, unless you concentrate moderately hard, uh, you may short-circuit that loop which may not be what, what the right thing to do. Um, so, uh, a little bit of thought needs to go into exactly how you handle, uh, incoming DSNs and exactly what you strip off, uh, and you don't just go looking for your own signature at any level, you have to look for it at the correct level. Uh, but since we don't requ- since we, uh, encourage people to put all the headers in, uh, it may be hard to tell at what level, uh, which layer of the stack of, uh, going round in a loop you, you actually occurred, you occurred more than once. So, that may be an issue which we have to, uh, set up, try, and see whether or not anything really bad goes wrong, uh, if people short-circuit the loop.

Pete Resnick: Um, just a quick thought on this group modifying DMARC, whatever the chartering stuff aside, um, i'm, the way that it was discussed just now, makes me feel a little bit like as soon as we change it, we are coupling DKIM2 and DMARC in a way that we might not like in the long term, so I think we should be very careful about the way we go about modifying it. Note for the future, I suppose. Um, there's nobody behind me in the queue as to, uh, as far as we want to go on this topic today. Do we feel like we reached any decisions? Is everybody comfortable putting all the DMARC stuff on hold until we get a little further along and until the existing DMARC working group closes down? Because that sounded like, you know, at least Andy's recommendation.

Murray Kucherawy: Yeah, i think that's a good idea.

Bron Gondwana: Yeah, i, for the second question, yes, I agree we should put it on hold. Um, and for the question of has anything been agreed, I think we have agreed that we should be adding a flag that says "don't send any feedback for this message when you're a later hop," with "I'm handling it all." So, if you want feedback, let me know. A flag in, in DKIM2 specifically, right? A flag in DKIM2, yeah. Um, so, that would be a flag that would be added to the DKIM2 header at, uh, hop N.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Murray Kucherawy: And I think, uh, tabling this till a little bit later after things have evolved a bit is also a good idea. Okay. Moving on then to our last, I think it's our last topic. We were talking about removing MIME parts and, um, I mentioned Merkle trees. Um, so, the, i'm just consulting the minutes from before to make sure that I didn't miss anything that we decided. Um, yeah, this, this doesn't seem to have resolved last time. We were just talking about it. Um, I was, Pete and I were talking about, uh, in one of our coordination meetings, whether the creation of the tree is a problem, and what a broken tree actually tells you. Um, but Richard had a, one of Richard's concerns, uh, that I, that I heard before, first of all, has, has there been any further discussion on the topic that we want to bring to the microphone here? Or are we just going to start hashing on it a little bit? Bron, go ahead.

Bron Gondwana: Uh, as I commented, uh, way back in the chat, I think this answer is the same. It is, add yet another header, uh, which has the hashes of each MIME part, and then use the standard message instance mechanism to replace it when you change the hashes, if you want to change the hashes. Um, or you can just leave it there and some people can unwind back to the start and back until it, it works. I think it's fine. Um, that, that gets you, not the parts where the start

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: So, you will give the hashes of all the parts, all the MIME parts that were in the original message, and then, including the one you're removing, uh, and then you, you pass the message on and anyone else can rewind back to you, and can check that the bits that you specified how to do rewind back still. So, i guess, there's, what if, suppose something removes a binary part? Yeah. What we don't have, and maybe we should add to the recipe, is basically a, "I removed a chunk of lines here, and i'm not telling you what they were, but here's how to do all the other bits." Here's, here's the other changes that i'm also making, and that would allow you to, to still keep the other parts consistent while throwing away a part. I think that might be worth it.

Pete Resnick: I think another distinction that you've made is that you, we, you were talking about, um, produced- can- generating the the set of hashes for each part, which is different from the Merkle tree, because the tree, uh, the tree actually creates- every subtree gets its own hash as well. But I think you're talking about just basically hashing the, what amount to the leaf nodes in the MIME tree as a sequence of some kind.

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Of the end nodes. So, like, you don't, you'd never remove a sub- like a, a subtree of it. MIME is basically a tree, right? So, okay, um, I think I see what you're talking about. Um, okay, anything else from Bron, or going, shall i go to the queue? We've got like five now. Um, um

Pete Resnick: Okay, Richard.

Richard Clayton: Okay, um, just to set some context here, uh, we've always understood that security devices and so forth remove or add MIME parts, uh, they tend to add MIME parts, uh, by adding standard signatures, uh, or legal disclaimers as stuff goes out of your org, uh, and the solution to that is that you should sign as the stuff goes out of your org, uh, not before the security device, because, uh, the security device is not going to be able to do anything. It, it is just much simpler if you sign after you've done all your modifications. Uh, the second case was the security device coming into your organization which is going to remove malware, that sort of thing, uh, and there, uh, we've argued that, uh, if you need a DKIM2 signature to work after that, then you have to add a null recipe which says, "I have changed things, but you can't undo it, and the reason you can't undo it, so, and you trust me because, uh, you have bought, uh, con- you, this security device has cost you real money, you have a contract with the people running it who say that they're going to behave themselves, uh, and therefore you trust them." Uh, so, uh, that was all just fine, everybody was going along, and then people pointed out that there are mailing lists out in this world, which remove MIME parts. Notably they remove images, uh, that sort of thing, uh, and the, the main reason they do this, as far as anybody can tell, is that, uh, it seemed like a good idea in 1997 because people were all using modems, uh, and therefore stopping people sending very large binaries through mailing lists was a good idea, and therefore if they were stripped out, then you couldn't do that. Now, today, uh, uh, such mailing lists still exist, uh, though modern mailing list software doesn't actually provide the facility to do this because there's no call for it, uh, because everybody wants their, uh, Twitter logos and that sort of thing to survive in their signatures, uh, and they want those to work through mailing lists as well, and if the mailing list stripped them out, everybody would shout and scream, and the mailing list, uh, admin would fix it, uh, and, uh, if a mailing list wishes to remove these, uh, then, uh, or doesn't think this binary makes any sense, then, uh, the most sensible thing for the mailing list to do is to reject the message and tell the, the sender to remove, uh, the binaries because this is a binary, this is a binary-free mailing list, and stop trying to, uh, stop trying to cheat and send binaries through it, rather than having the mailing list software do it. At which point, the problem entirely disappears. If you're really determined to document, uh, "this is the same message as it was before, except here's the hash of something which has disappeared, and I can't tell you what it is, and you can't tell what it is because all you've got is the hash in your hand," then i'm not sure how you're going to trust that message or take a view of it, uh, because, uh, you may have removed a very important, uh, image which says "NOT" in very large letters over the top of it or something like that, or "DRAFT" or etc. So, um, I, this is not a problem we need to solve in my personal view, um, and, uh, let's just move on and stop trying to, uh, invent something very complicated for something we don't need to do.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, uh, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it uh accepts or uses is SPF and DKIM, I guess, the problem is, yeah, there would have to be at some point an update or revision to to say DKIM2's part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Wei Chuang: That's good.

Pete Resnick: All right. Murray, next topic.

Murray Kucherawy: Okay, we have um an a continuing discussion of DKIM2's relationship to DMARC um at the end of the last interim, um this from the minutes, Pete was saying this seems like an ongoing open issue. We'll have to figure out how to guide this discussion. Um, I can prime some chatter for today by saying I think the thing that was that struck me the most is the whole notion of what are we going to do about reporting because people, if this is going to go to sweep DMARC aside, someone might lose the reports, and that reporting structure is interesting. Do we want to consider how we're going to how we could continue that if DKIM takes over DMARC? What's the thinking there? Um, the but anyway, the in any event, this is a an unresolved area, and I wondered if there's been any discussion that uh people want to bring to the mic about this today. Have we have we moved the needle on this topic anywhere in the last month or so? Bron.

Richard Clayton: Okay, sorry. Um.

Pete Resnick: Can always come back in the queue.

Richard Clayton: I I didn't do slides for this, so I'm rambling.

Murray Kucherawy: Uh, Bron, go ahead.

Bron Gondwana: Ah, okay. I'll give you my face just just for a moment at least. Hi. Um, to for part of what Richard was saying there, yes, I think that's really valuable. The inline, um not the first hop, reporting request is something that DKIM2 will add that we don't have at the moment, but I do, I have been persuaded by the discussion in the chat that we do need to allow organizations who have such poor internal controls over who has keys that are published in their DNS that they can't tell who's sending email on their behalf to have a way to do a policy lookup and see who's sending email on their behalf still. Um, you could say some some mean things about their ability to to track their key management, but that's the world we live in, um, so, I think we we still do need to accept that for the first hop.

Murray Kucherawy: Laura.

Murray Kucherawy: Wei.

Andy Newton: That that is where I would go with this, and uh unless uh like, someone like Barry has a uh a better idea or a different idea, that's how I would do this.

Barry Leiba: No one like me exists, so what can I say? I have no better idea.

Bron Gondwana: I was going to say yes, I think it is, that we've had enough new material come up from this. It would be good to give it another rinse before we get to Vienna. Sure.

Pete Resnick: Yeah, as Andy says, we can always cancel. Okay, I'll take the call from here, but all we're going to do is check for any other business. Thanks for hanging on, Murray.

Murray Kucherawy: You bet.

Andy Newton: Try to make it try to make it two weeks.

Pete Resnick: What's that?

Andy Newton: The the two the minimum should be two weeks. Although, I think technically it's not, but whatever.

Pete Resnick: Okay, yeah. Um, okay, so, we will get, you know, pick a date, get an announcement out, and then we can always decide that we've run out of things uh, you know, that really need time before uh before Vienna and just move them on to there. Um, so, it is AOB time. Anybody have any other business? Go ahead, Wei.

Wei Chuang: Yeah, so, I put out some text, I mean it was sent out relatively close to the interim, so I can understand why maybe not a lot of people saw it, and I'm happy also to just take this at the next interim too, but I figured it's worth discussing, um, and seeing if there is interest in updating the spec to account for these different approaches. So basically I put out two different approaches. Um, there's the one where you literally take the d-equals and collapse it into the signature. Instead of having three parts to the signature, you also include now a domain part. Another way, uh, is to just strip off, uh, and this is a little bit, in, in practice is pretty simple, but I guess it's, it's hard to describe actually, uh, without writing it up, I think. But basically taking off the local part for what would be considered the, uh, header created to handle the multiple signatures. That's the way to link together this chain of custody. So just wanted to see if we have time to discuss this here. Um, if not, we can wait to the next interim, and hopefully I've discussed it well enough to actually have a discussion.

Pete Resnick: Anybody read Wei's stuff well enough to have comments here? Richard?

Pete Resnick: Bron?

Pete Resnick: Go ahead, Richard, just jump in.

Pete Resnick: Richard, you're on mute.

Pete Resnick: So, so that is to answer Brian by saying, "I don't have any need for it."

Pete Resnick: Go ahead, Bron.

Pete Resnick: Go ahead and jump in, Wei, and then we'll go to Tara after that.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Richard Clayton: Okay, um, just to set some context here, uh, we've always understood that security devices and so forth remove or add MIME parts; uh, they tend to add MIME parts, uh, by adding standard signatures, uh, or legal disclaimers as stuff goes out of your org, uh, and the solution to that is that you should sign as the stuff goes out of your org, uh, not before the security device, because, uh, the security device is not going to be able to do anything. It, it is just much simpler if you sign after you've done all your modifications. Uh, the second case was the security device coming into your organization which is going to remove malware, that sort of thing, uh, and there, uh, we've argued that, uh, if you need a DKIM2 signature to work after that, then you have to add a null recipe which says, "I have changed things, but you can't undo it, and the reason you can't undo it, so, and you trust me because, uh, you have bought, uh, con- you, this security device has cost you real money, you have a contract with the people running it who say that they're going to behave themselves, uh, and therefore you trust them." Uh, so, uh, that was all just fine, everybody was going along, and then people pointed out that there are mailing lists out in this world, which remove MIME parts. Notably they remove images, uh, that sort of thing, uh, and the, the main reason they do this, as far as anybody can tell, is that, uh, it seemed like a good idea in 1997 because people were all using modems, uh, and therefore stopping people sending very large binaries through mailing lists was a good idea, and therefore if they were stripped out, then you couldn't do that. Now, today, uh, uh, such mailing lists still exist, uh, though modern mailing list software doesn't actually provide the facility to do this because there's no call for it, uh, because everybody wants their, uh, Twitter logos and that sort of thing to survive in their signatures, uh, and they want those to work through mailing lists as well, and if the mailing list stripped them out, everybody would shout and scream, and the mailing list, uh, admin would fix it, uh, and, uh, if a mailing list wishes to remove these, uh, then, uh, or doesn't think this binary makes any sense, then, uh, the most sensible thing for the mailing list to do is to reject the message and tell the, the sender to remove, uh, the binaries because this is a binary, this is a binary-free mailing list, and stop trying to, uh, stop trying to cheat and send binaries through it, rather than having the mailing list software do it. At which point, the problem entirely disappears. If you're really determined to document, uh, "this is the same message as it was before, except here's the hash of something which has disappeared, and I can't tell you what it is, and you can't tell what it is because all you've got is the hash in your hand," then i'm not sure how you're going to trust that message or take a view of it, uh, because, uh, you may have removed a very important, uh, image which says "NOT" in very large letters over the top of it or something like that, or "DRAFT" or etc. So, um, I, this is not a problem we need to solve in my personal view, um, and, uh, let's just move on and stop trying to, uh, invent something very complicated for something we don't need to do.

Pete Resnick: Wei.

Wei Chuang: That's good.

Pete Resnick: All right. Murray, next topic.

Murray Kucherawy: Okay, we have um an a continuing discussion of DKIM2's relationship to DMARC um at the end of the last interim, um this from the minutes, Pete was saying this seems like an ongoing open issue. We'll have to figure out how to guide this discussion. Um, I can prime some chatter for today by saying I think the thing that was that struck me the most is the whole notion of what are we going to do about reporting because people, if this is going to go to sweep DMARC aside, someone might lose the reports, and that reporting structure is interesting. Do we want to consider how we're going to how we could continue that if DKIM takes over DMARC? What's the thinking there? Um, the but anyway, the in any event, this is a an unresolved area, and I wondered if there's been any discussion that uh people want to bring to the mic about this today. Have we have we moved the needle on this topic anywhere in the last month or so? Bron.

Richard Clayton: Okay, sorry. Um.

Pete Resnick: Can always come back in the queue.

Richard Clayton: I I didn't do slides for this, so I'm rambling.

Murray Kucherawy: Uh, Bron, go ahead.

Bron Gondwana: Ah, okay. I'll give you my face just just for a moment at least. Hi. Um, to for part of what Richard was saying there, yes, I think thats really valuable. The inline, um not the first hop, reporting request is something that DKIM2 will add that we don't have at the moment, but I do, I have been persuaded by the discussion in the chat that we do need to allow organizations who have such poor internal controls over who has keys that are published in their DNS that they can't tell who's sending email on their behalf to have a way to do a policy lookup and see who's sending email on their behalf still. Um, you could say some some mean things about their ability to to track their key management, but that's the world we live in, um, so, I think we we still do need to accept that for the first hop.

Murray Kucherawy: Laura.

Murray Kucherawy: Wei.

Andy Newton: That that is where I would go with this, and uh unless uh like, someone like Barry has a uh a better idea or a different idea, that's how I would do this.

Barry Leiba: No one like me exists, so what can I say? I have no better idea.

Bron Gondwana: I was going to say yes, I think it is, that we've had enough new material come up from this. It would be good to give it another rinse before we get to Vienna. Sure.

Pete Resnick: Yeah, as Andy says, we can always cancel. Okay, I'll take the call from here, but all we're going to do is check for any other business. Thanks for hanging on, Murray.

Murray Kucherawy: You bet.

Andy Newton: Try to make it try to make it two weeks.

Pete Resnick: What's that?

Andy Newton: The the two the minimum should be two weeks. Although, I think technically it's not, but whatever.

Pete Resnick: Okay, yeah. Um, okay, so, we will get, you know, pick a date, get an announcement out, and then we can always decide that we've run out of things uh, you know, that really need time before uh before Vienna and just move them on to there. Um, so, it is AOB time. Anybody have any other business? Go ahead, Wei.

Pete Resnick: Anybody read Wei's stuff well enough to have comments here? Richard?

Pete Resnick: Bron?

Pete Resnick: Laura A?

Laura A: That was basically what I was going to say is that, you know, if you're looking at a large university or if you're looking at a government organization, there are a lot of people who, you know, can go talk to the DNS folks and get something added to DNS, and then the person who's actually responsible for the mail doesn't know what's going on. So, if there is a way for an organization, and I think this does go back to the how are we going to track the initial, that first From address, like, that source of the email, but I think that this is a discussion that we need to keep having and and develop a way to get those reports back. And maybe it is just to piggyback it off of what DMARC has done, or maybe it's another type of reporting that comes out because there are some messy organizations out there with, you know, a lot of different email streams, um, and they're doing different DKIM signatures, you know, you can have different D equals, and you can have different domains, and so, we need to kind of figure that bit out because those reports are so valuable to folks inside the organization who are trying to manage the outbound mail.

Pete Resnick: Wei?

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Andy Newton: Well, I was already groaning on, on that at this time. I heard it, even though you were muted. Uh, I, I think at that point, we, we recharter this working group. Uh, DMARC is, it's, we're trying to kill it. Um, and so it's got one last mission. Barry's working very hard on that last mission, and then we're trying to close it out.

Pete Resnick: Okay, so, we is your recommendation we put this in abeyance and then, uh, after DMARC closes down, we then go to recharter this to add a little thing that says, "This group may also, um, you know, uh, describe how, uh, you know, describe changes to DMARC in order to accommodate the the new version of DKIM."

Andy Newton: That, that is where I would go with this, and uh, unless, uh, like, someone like Barry has a, uh, a better idea or a different idea, that's how I would do this.

Barry Leiba: No one like me exists, so what can I say? I have no better idea.

Pete Resnick: Okay, so we'll, we'll summarize that to the list and I think, in addition to the minutes, um, you know, with each of these things that we now think are really kind of honing in on consensus, Murray or I will post an individual message to the list saying, "Okay, here, here's what we're hearing in the interims and uh, we need to have some, in this case, take on writing up some use cases and convince everybody that it's worth the investment." Any other comments on this topic? No.

Murray Kucherawy: Um, we're up to AOB and I need to depart the call for another meeting, but the only thing I wanted to make sure we talked about is do we want to do another interim between now and Vienna? There's still a month or six weeks to go. It would be basically an interim three, two, or three weeks before the meeting. Yeah. If people think is it worth it, Bron?

Bron Gondwana: I was going to say yes, I think it is, that we've had enough new material come up from this. It would be good to give it another rinse before we get to Vienna. Sure.

Murray Kucherawy: Okay. Murray and I will try and pick a date. Yeah, I'll try and gray in the chat. I'll uh, we'll figure out what the minimum allowable notice is and we'll, we'll set the meeting up for that.

Pete Resnick: Yeah, as Andy says, we can always cancel. Okay, I'll take the call from here, but all we're going to do is check for any other business. Thanks for hanging on, Murray.

Murray Kucherawy: You bet.

Andy Newton: Try to make it, try to make it two weeks.

Pete Resnick: What's that?

Andy Newton: The, the two, the minimum should be two weeks. Although, I think technically it's not, but whatever.

Pete Resnick: Okay, yeah. Um, okay, so, we will get, you know, pick a date, get an announcement out, and then we can always decide that we've run out of things, uh, you know, that really need time before, uh, before Vienna and just move them on to there. Um, so, it is AOB time. Anybody have any other business? Go ahead, Wei.

Wei Chuang: Yeah, so I put out something out on the list, um, basically about multiple, uh, supporting multiple domains in, in a header. Um, basically, there's some scenarios where, uh, basically, for either enterprise signing or for, uh, bulk sending, uh, basically, you may need to have multiple signers in an ADMD and, uh, I put out, um, you know, some text. I mean, it was sent out relatively close to the interim, so I can understand why maybe not a lot of people saw it, and I'm happy also to just take this at the next interim too, but I figured it's worth discussing, um, and seeing if there is interest in updating the spec to account for these different approaches. So, basically, I put out two different approaches. Um, there's the one where you literally take the d-equals and collapse it into the signature. Instead of having three parts to the signature, you also include now a domain part. Another way, uh, is to just strip off, uh, and this is a little bit, in, in practice is pretty simple, but I guess it's, it's hard to describe actually, uh, without writing it up, I think. But basically taking off the local part for what would be considered the, uh, header created to handle the multiple signatures. That's the way to link together this chain of custody. So, just wanted to see if we have time to discuss this here. Um, if not, we can wait to the next interim, and hopefully I've discussed it well enough to actually have a discussion.

Pete Resnick: Anybody read Wei's stuff well enough to have comments here? Richard?

Pete Resnick: Bron?

Pete Resnick: Go ahead, Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, WeiWei Chuang: —and then we'll go to Tara after that.

Tara Whalen: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Pete Resnick: Go ahead and jump in, Wei, and then we'll go to Tara after that.

Wei Chuang: Oh, okay. Um, so I guess to your point, Richard, what happens with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei, and then we'll go to Tara after that.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei, and then we'll go to Tara after that.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.

Pete Resnick: Wei.

Wei Chuang: Yeah, so, uh, just, um, from Richard's point about, uh, the sort of the problem with existing DMARC, right now, it specifies that, you know, the authentication methods that it, uh, accepts or uses is SPF and DKIM. I guess, the problem is, yeah, there would have to be at some point an update or revision to, to say DKIM2 is part of this mix, I think. Uh, the then, the next problem is, yeah, so, particularly for SPF, I, it is very vulnerable, and there needs to be a way of saying, "Hey, uh, don't use SPF for my domain," uh, and there, you know, that can be specified in DNS, I think, um, that there's basically a policy decision by that particular domain. Um, I think there's what I'm proposing is basically we need to do another revision of, of DMARC. I know it just got published, but still, one that says this is what DMARC, sorry, this is what DKIM2 says about DMARC, and I think the framework DMARC provides is very good, is so, basically, I would propose that we basically do an update of DMARC, specifically for DKIM2, and then some of the new properties that it introduces. These are a lot of good benefits because DKIM2, in some sense, a lot of it is meant to go fix some of those DMARC problems that we've had. Anyways, that's my proposal.

Pete Resnick: Go ahead and jump in, Wei.

Wei Chuang: Okay. So, what happens, uh, with some of these enterprise forwarding cases is it comes in, uh, for a particular address, uh, at some domain, and then the customer may want to then send it out as a completely different domain because there might be, you know, some other domain that they control that they want to forward from. And when that happens, then with the current DKIM2 spec, you have to create this synthetic hop, basically, that, I suspect, you know, a processing system that's trying to go figure out how to handle bounces and that type of stuff, is going to see that and going to get confused by. So, and it's also, like, it's basically an unnecessary processing step. And so I think it would be better to just say, understand from our perspective, this was one ADMD, basically, there was a synthetic step inserted, we don't have to process anything for that, just go back to the, you know, forward back as necessary, uh, skipping that intermediary step.

Pete Resnick: Tara, go ahead.

Pete Resnick: Richard.

Tara Whalen: Okay, that's a different way of putting it. Okay, that makes sense. Thank you.

Murray Kucherawy: Yeah, i think that's a good idea.

Murray Kucherawy: Okay.

Bron Gondwana: And I think that was the only thing that we, we agreed on.

Pete Resnick: So, Bron, you're saying, if you're going to remove a part, then you take the original message, do the Merkle tree for it. Well, how does this work?

Bron Gondwana: Yep, just here's all the hashes of them in order.

Pete Resnick: Okay, Richard.