IETF 122: DKIM WG Meeting
21 March 2025 09:30-11:30
Bangkok, Thailand
Barry: How do those last two bullets reconcile?
Pete, Murray: The email system may not come crashing down as a result of this WG’s output. Interoperability with older things is great, but the way things are running needs to continue until we consciously decide to migrate to something new.
Jim: If we have two approaches to a problem, one compatible with existing DKIM and one not, how do we decide?
Pete: That’s partly a WG decision, but we were chartered to solve a certain set of things so we plan to rely on that to break such ties wherever possible.
Bron: It also depends on how much interest there is in implementation.
Jim: We should cover abuse-resistant techniques. See “l=”, for example. This effort should address maintaining validation while also being careful about exposing new vulnerabilities.
Chairs: We think that’s understood.
Tero: Concerned that the planned approach is going to cause fragmentation of the email infrastructure. “No, DKIM, no entry.” This is very bad. We should seek to prevent this.
Pete: That ship may have already sailed. We should consider as “good” anything that reduces this.
Bron: Sending email is somewhat of a privilege. Nobody has to accept what you send. Think of it as “If you don’t contribute to fixing the problems, your deliverability will be reduced”, and that’s OK.
Tero: I’d like to have reduced fragmentation as a goal. End user deliverability problems means you have to fold.
John: I run my own mail server, I’m a DKIM signer. There’s a certain amount of negotiation with the parties involved. I don’t think it’s practical for us to describe all modifications, but a specific set is more practical. We do need to talk to Mailman and Sympa.
Murray: Does any of this (fragmentation discussion) rise to tweaking the charter? (no response) OK, we assume we’re OK as-is.
Jim: This slide mentions DMARC, but I haven’t seen anything in DKIM2 about policy. I think about it as existing at a different layer.
Pete: I agree there’s probably a desire to publish policy about DKIM2, but I agree it’s not core to what we’re doing, but there’s probably some interaction.
Jim: The charter doesn’t mandate a policy mechanism, right?
Pete concurred.
Todd: My understanding is that under DKIM2, a message that fails to validate is just rejected, correct?
Jim: I saw something about this in the problem statement document, which seemed to imply that a non-validating message would be rejected. This wasn’t explicit though.
Richard: The intent of DKIM2 is that it’s local policy what you do with a non-validating message. There’s no reason to believe the purported author has ever seen the message at all. This wanders into DMARC space in its policy aspects. It was not a design aim of DKIM2 to sweep up DMARC, ARC, greylisting, etc.; it’s meant to be a cleaner solution.
Todd: I hear what Richard is saying; this seems to be more about putting control at the receiver rather than at the sender, which was DMARC’s thing. I’m not bullish on DMARC having a very large role in a DKIM2 world, but we’ll see.
Richard: Quite a number of mailbox providers have made it clear that they believe unauthenticated mail won’t be accepted in the future, and that group seems to be growing. But it’s your server, you decide what to do with it.
Bron presented an overview of the three documents that are proposed for adoption. (See slides.)
Jim (“Goals” slide): There are a lot of goals here that aren’t in the charter, like crypto agility. Do we need to change the charter?
Bron: We’re going to have to deal with this at some stage. Others on this slide all roll up under other chartered goals.
Murray (“Eliminating replay” slide): The slide mentions “lack of clarity”, but we do have a definition for “replay” that survived chartering, so maybe this has been resolved.
Todd (“A way for hops to ask for feedback” slide): My common understanding of the relationship between a signature and a feedback loop involves signing in order to get any spam feedback. I’m aware of Alex Brotman’s draft about this.
Bron: This could be easily tacked on after all the prior goals and we’d still be successful. This feedback is a bonus, and doesn’t require the same level of crypto protection.
Pete: That’s all the motivations in the document. Have we missed any, any other feedback? (None.)
Bron: (discussion about single recipient)
Murray: The one thing we have to deal with is that RFC 5321 says you “should” use multiple recipients on a single transaction whenever possible. Whatever we do here, we will need to explain why we’re deviating from that advice.
Tero: This isn’t just about Bcc, it’s also about forwarding, secret addresses, etc. We don’t always know which ones are secret.
Wes: If I understand this correctly, you’re going to make one connection per recipient?
Bron: Not necessarily one connection, but a new transaction with its own signature.
Wes: Does anyone know what that bandwidth explosion will be, especially given stuff like large attachments?
Bron: Data from Yahoo! says that number is close to zero, because nearly all mail is already single-recipient. Generally bandwidth and compute are cheap, and rather than large objects, most people mail links around. Mailing lists already do stuff like VERP which forces single recipients.
Wes: I assume this will carve out delivery by client?
Bron: Yes. If the client isn’t DKIM-signing, then you’re not doing a DKIM2 signature either. This is more of an SMTP profile: We’re restricting what you can do in this profile, not changing the underlying transport protocols.
Pete: This is an interesting 30-year-old discussion; Dan Bernstein complained about the SHOULD long ago, and he’s been doing single recipient in qmail for a long time.
Barry: It seems an unfortunate timing issue that we’re about to issue an update to RFC5321bis that says you SHOULD group recipients as much as possible during a single transaction and this is now saying that the future is MUST NOT.
Bron: I would assert that DKIM2 messages to separate recipients are distinct emails.
Barry: The reality is that what 5321bis says is wrong for the future, and that future is not very far away. Maybe EMAILCORE should take this as input to the applicability statement.
Pete: There is a way in which what 5321bis says is still true; if you could do a pure pipeline of a bunch of recipients all on the same server, all on the To line, …
Barry: The reality is that “Yahoogle” is saying “don’t do that in the future”.
Bron: Being able to put multiple recipient addresses in the signature would make DKIM2 more complex than the savings is worth.
Tero: Is that “1%” statistic about SMTP transactions or recipient addresses? Some MTAs always split down to single recipients, meaning the statistics you get are very different versus other environments where recipient gathering is considered an optimization. From my own mail server’s \~4000 sent messages over the last few years, 6% of them had multiple envelope recipients. This doesn’t count Cc: fields, just multiple To: fields.
Bron: How much more compute would’ve been used if they had been split?
Tero: I think postfix does that automatically.
Bron: Splitting helps a lot for delivery management as well; more reliable delivery.
Barry: Just to clarify, I’m talking about updating the applicability statement in EMAILCORE, not 5321bis.
Wei: I support the point Richard made for Yahoo; Gmail’s data concurs, showing over 99% of outbound traffic is to a single recipient. I don’t think DKIM2 is going to significantly change email flow.
Tero: Was that only one To or Cc, or one envelope recipient?
Wei: This is an SMTP level evaluation, didn’t look at headers.
Richard: Almost every message is unique as well, because we require things like unique unsubscribe URIs, even people sending in bulk send unique messages. The exception to this is spammers who are typically trying to send the same identical message to thousands of recipients. About a year ago, when we were first looking at DKIM2, it looked like around 1% had multiple recipients, but more modern numbers are even less than that. I think the technology stacks have changed, result in more unique messages. Many spam classification systems now consider multiple recipients to be spam. I don’t really care if spammers are efficient.
Bron: AI will be generating all messages soon anyway.
Bron: The corporate email case might deserve further consideration, but I don’t think so. I think we should test the single recipient case first and then re-evaluate.
Bron: (discussing putting the single recipient in the signature somewhere)
Jim: I’m concerned with the fact that forwarding is indistinguishable from lists. The case I’m thinking about is sending a message to a list I’m not subscribed to, and then the list goes away afterwards. I’m wondering if this is a complete solution to that problem; I’m not sure this is effective against that attack.
Bron: If you’re on the list, you’ll get the message. If you’re not, it won’t sign a copy of the message with you identified as a recipient, and you can reject it.
Jim: That requires the system to know which lists I’m subscribed to.
Bron: Yeah, that’s a different issue. I don’t think we can solve that here. If the sending system thinks you’re subscribed, it will send you a copy. Lists should confirm your subscriptions; if they don’t, that can be reported as a problem.
Jim: But that does happen.
Bron: There’s some separate work about storing your subscriptions at the receiver via a token.
Jim: I’m not sure this is a solvable problem, but it’s something that we might note in Security Considerations somewhere down the road.
Bron: All this protocol does is attest that a signing domain intended to send this message to you, or to the next address, and you can’t replay to anyone that the signer didn’t intend to send to.
Richard: According to the proposal, if you have exploded the message (now want to send it to N people), you have to mark it “exploded” in the signature, so that recipients are not surprised to receive multiple copies. A local policy decision could decide to do something with such a notation. There’s also a provision to tag a message as “not to be exploded”.
Jim: Some of those mechanisms are available to large operators and not small ones.
Richard: It is certainly the case that if you’re solo on a mail server, you’ll only ever see your own copy and can’t tell whether a replay occurred. You can also see upstream “I exploded this” claims.
Jim (on the “Why DKIM2 rather than extending DKIM?” slide): DKIM handles multiple signatures just fine. I like the idea of having an ordering tag in the signature, but existing compliant DKIM verifiers will ignore unknown tags, so that seems like it might be backward compatible.
Bron: The “yes, but” here: Suppose I send a signed message via a list that breaks my signature. DKIM will fail even if it has tags that alter the way the signature is meant to be processed, making it not backward compatible. Trying to overload that into DKIM would probably make things worse. There might be alignment implications as well.
Jim: DKIM doesn’t have the notion of “alignment” so I think you’re talking about compatibility with DMARC.
Bron: Potentially, yes, but also there will be lots of invalid signatures.
Jim: That’s true now. Maybe that’s the thing we need to work: The DMARC angle on all of this, since alignment is a factor and you mentioned the alignment of the signing domain.
Jim: As for the temporary header field name, there was the whole “X-” thing we deprecated, because they never die.
Pete: Experimental header field names turn out to be a bad idea almost all of the time because they don’t go away. Now you have two things out in the wild, and you have to deal with both of them. Instead, start with what you think you’re going to end up with. If that gets bad, pick another one.
Barry: Yes (to Pete) if you’re talking about DKIM2 tech. There’s some history of doing this as an ongoing development tool if you give it a sufficiently obvious and mutating name to indicate it’s part of an experiment.
Pete: Any examples in email?
Barry: Not in email.
Pete: Oh, I agree in other contexts that this has worked. Just not email.
Murray (on the “Why a powerful body modification algorithm?” slide): How does this interact with canonicalization? And didn’t DKIM2 reduce the options there?
Bron: This is for the WG to sort out.
Murray: Previously we were concerned about mutations weird MTAs might make. Any such mutation even by a byte would render a generic body modification expression unusable. Do we think those have stopped?
Bron: Lots of those intermediaries these days are signing or verifying, so they’ve become sensitive to unnecessary mutations.
John (on the “Open Questions” slide): This reinforces that we should call this something other than DKIM. In practice, most of the time you’ll know whether the recipient system handles DKIM2 or not because you’ve talked to them before. If not, put both signatures on and see if the next hop chains it or not.
Bron: The lightweight version of this is a tag that says “may do DKIM2 at the next hop”, and change that later to “must do DKIM2 at the next hop”. I see some value in, over time, being able to assert the latter.
John: We need to do some experimentation.
Murray: This is yet another way we’re reaching up from message content space into transport space. I understand why, but we should plan to explain these decisions in our documents.
Tero: If you actually cache that an operator is doing DKIM2 but then they stop, there’s no way to notify the ecosystem that they’ve stopped. Hints might be workable but this needs development.
Bron: We should definitely try to learn from DNSSEC which has faced issues like this before. But I think there’s definite value in a tag that says “this should not go outside DKIM2”.
Richard: Given how long the community has been doing this, we should have solid guidance about which header fields should be signed. There are problems with some header fields, like list-specific ones when a message goes from one list to another, causing header field replacement. People also sign things that don’t make sense or have no security properties. Since we should be able to produce a consensus statement about what fields should be signed, we should agree on some ground rules about what’s in (e.g., is it in an RFC?), but most things in RFCs should be there. Some of them are quite exotic though.
Richard: On canonicalization, the vast majority appears to use “relaxed/relaxed”. The large providers have decided on this because they are very cautious and think it’s clear that only “relaxed” makes sense for headers since so many mutations are possible. However, loading bodies into memory to do the mutation algebra works easier when there’s no canonicalization happening in the body. [MSK: Should that be “relaxed/simple” then?]
Bron: Concur with Richard.
Wei: Regarding interop between DKIM and DKIM2. There’s an opportunity for DKIM2 to better support DKIM. Assuming we get reversible transformations, could this not help DKIM? Maybe this allows for authentication by DKIM when DKIM2 fails. This might be something we can try out in initial testing, rather than waiting for broad deployment.
Wei: How do we know something will be compatible with DKIM2 as a sender? It’s not only that the receiver has to support DKIM2, but that they also have the right keys. There’s a notion of receiver-side alignment, so the hosting provider might provide that service while the customer doesn’t have the keys. The capability mechanism is obviously very important which we should tackle early on.
Bron: Forward looking is difficult without knowing the selector the signer will use.
ACTION: Calls for adoption for the three proposed documents will be conducted.
Barry: Everyone should remember that adopting a document means it’s a starting point, not a final product, and everything is on the table.
Pete: Concurs regarding early adoption and iteration.
Murray: Even an adopted document can be abandoned.
Jim: We should ask the original authors when they want it to be adopted, given they’re ceding change control to the WG.
Pete: I think Bron is fine with any time.
Bron: I’m happy for adoption.
Murray: Do we want to do an interim, or what other next steps do people suggest?
Bron: Suggest an interim before the Madrid meeting. I’m going to be putting a lot of energy into this.
Barry: I think we should plan interims but we don’t need to schedule them today.
Wei: Question for the chairs: If we were to do interim meetings, how frequent would the Chairs be willing to do them?
Pete: No weekly calls, thanks, unless and until there’s a wild amount of work going on. If we want to do some between now and Madrid, let’s start that discussion on the list and see when people think they’re worth doing.
Murray: I suggest we do a first one in the second half of April.
Meeting adjourned at 11:17.