Session Date/Time: 19 Mar 2026 06:00
Ken Murchison: ... so we always—all the dads would always say it that way, even the coach, to make fun of him. And it took me a good long time to stop saying it incorrectly.
Bron Gondwana: See, this is—I taught my kids not to fucking say "buckle" at home, so they wouldn't be able to stop doing it when they were in a situation where they—
Ken Murchison: So I have this problem now that—
Bron Gondwana: Yeah.
Ken Murchison: That when I visit her, I'm not supposed to say that word, but I mean she's right, she's pretty verbal now. She's going to soak it right up, so it's sort of, "Get used to it now, so..." And I fucking can't do it.
Bron Gondwana: It's just a word, right?
Ken Murchison: It's like a comma. You've got to learn. All right. On that note, I believe—yes, the bell has tolled for 2:00. So, welcome to Mailmaint IETF 125. We are rounding the fourth turn here for this meeting. So let's get started.
Ken Murchison: Here's your Note Well. You should have all seen it by now. You've agreed to it when you registered for the event. This covers conduct, privacy, and IPR that we deal with here at IETF. If you haven't read it already, please click on the QR code and read it. I'll give people a few seconds to click that if they need to.
Barry Leiba: You'll need this.
Ken Murchison: Oh, yes. Meeting tips. Thank you, Barry. Please make sure you've signed in through Data Tracker. If you are remote, please stay muted until it is your turn to talk. Please use the queue if you have any input. And what else have I missed here? Yes, if you have a headset, please use a headset so we don't get any feedback here. Next up: all the resources. You've probably seen this already, unless this is your first meeting, but I doubt it is.
Ken Murchison: And our agenda. Going through the minutiae right now. I've already asked Bron to take notes, so that is taken care of. Thank you very much, Bron. Briefly going to go over some of our drafts that are nearing the end or are blocked on other things. We're going to have a few probably short presentations of our active drafts in that particular order. If there's any agenda bashing, anybody want to change the order of the presentations? Hearing none, let's move on.
Ken Murchison: All right, so stuff that is pretty much done or blocking. So, IMAP-JMAP Keywords and Mailbox Attributes is at the editor. Congratulations to Neil and Daniel. Also with the editor is IMAP UID BATCH. Congratulations to Daniel. A quick side note on UID BATCH: it's actually in production at Apple and at Fastmail. And I asked my boss to do a little bit of research for me, so over the last seven days there's been over 28,000 separate users that have logged in and used UID BATCH with Apple clients. So that's pretty cool. We know it works and, yeah, clients are happy with it.
Ken Murchison: Moving along: Expires message header field. That has been submitted to the IESG, so we will see what kind of feedback we get there. My co-chair Mary thinks that could be somewhat exciting, but we shall see. draft-ietf-mailmaint-wrong-recipient: we are still waiting on some implementations. If folks have one, please submit it to the list so we can keep track of where we are with that. It's probably going to be a lot easier for clients to implement it. We're waiting mostly on senders to actually do that, so we've got something to test against.
Ken Murchison: draft-ietf-mailmaint-imap-extensions-suggestions: Rick thinks he's pretty close to being done. He's got a co-author that's interested in helping with that, but he'd like to wait on the draft-ietf-mailmaint-imap-objectid-bis work because he'd like to include that in suggestions. So we're going to park that and wait for OBJECTID-bis.
Ken Murchison: draft-ietf-mailmaint-oauth-public: Neil posted an update this morning, mostly editorial. Last I talked to him, he feels the technical aspects are pretty much done. Per the agreement that we had with the OAuth chairs, I've asked that group to do a review to make sure we're not totally off in the weeds. One member of the group said they would try to review it, but I did not get any review before this meeting. Hopefully someone else will also volunteer, but I will poke them over the next few weeks to see what we can get.
Ken Murchison: draft-ietf-mailmaint-autoconfig: the XML-based one, which we're calling "Legacy." I don't know if Ben is on with us. I don't see Ben. My co-chair had posted some comments—who's also going to be the shepherd on that document—posted some comments after Montreal, and I don't believe those have been addressed yet, so I'll have to reach out to Ben and get that moving along. Any questions on those seven drafts or any further input? I'm seeing nobody in the queue, nobody in the room, so let's move on. And that is going to be Arnt.
Presentation 2: SMTPUTF8 draft duo
Arnt Gulbrandsen: I would like to see my slides. Next slide. Do you need me to pick it up? Masterful use of technology. Cool. We have a couple of new people. These are two documents to restrict the use of SMTP, of UTF-8 addresses in email a little bit, because there's been some implementer feedback that supporting complete UTF-8 in email addresses is not safe, pretty much.
Arnt Gulbrandsen: One of them—draft-ietf-mailmaint-smtputf8-syntax—is more lenient, is intended to be very, very easy to implement, but still strict enough that you can render it on screen and not have bad guys rendering in the wrong place. So you can do string concatenation, show a list of addresses, things like that. The other one—draft-ietf-mailmaint-interoperable-addresses—is more strict, is intended for provisioning, is intended to describe the kind of email addresses that might conceivably be on somebody's business card. Next slide.
Arnt Gulbrandsen: Right. In Montreal, we decided to use Precised instead of two—instead of two competing standards for the character repertoire. We made a couple of minor decisions. Yep. Thanks. That I wrote without much trouble. It appeared John Klensin pointed out that this needs to wait for email-core publication-wise, just to have the right RFC number. That's not serious. Since then, I have been gathering tests for a test suite. It's becoming obscure. You'll hear about that on the next slide. Another issue appeared and is open. We decided on length limits. We decided on accents appearing in where they shouldn't, like Motörhead. Yeah.
Arnt Gulbrandsen: Nobody felt any enthusiasm for making rules regarding mixed direction domains. Mixed direction domains are mostly blocked by registries, but not completely. Just blocking them here seems good to me because nobody—well, hardly anyone—mixes direction, and that which is actually used is permitted. And then the new issue: what to do about the Zero Width Joiner, 200D, which it turns out—I learned this a couple of weeks ago—has been used to defeat spam filters, has been used to confuse recipients, but is also necessary in three writing systems that I know of and maybe more. For example, the city of Islamabad needs a Zero Width Joiner to be written properly.
Arnt Gulbrandsen: I don't expect a lot of comments about 200D. It's obscure. I'll go back to the guy who brought this up to me and to somebody else and work out a compromise that makes this simple to implement. Probably my opinion will be that Zero Width Joiner is required for some writing systems and not permitted for others. But I haven't made up my mind. I have to look and see how the code goes. And... since last time, I have implemented something like this. Unicode has a new document coming which is called UTS 58, "Linkification." This is about recognizing links in text, typically just a domain on social media. They are writing a comprehensive specification for what to recognize. That includes an email syntax. Of course, I want the RFC and their specification to match perfectly. I have contributed the patch to ICU, which will be effectively the reference implementation. Still have not done my own implementation of this... but when I have, I shall be able to do careful diffs automatically. There is also another implementation ongoing. After IETF, I'm going to visit that company and look at it. We'll see what comes out, but it's after IETF, not before. I just kept the last line, "Review please," because it looked sensible. Anyone who really cares about Zero Width Joiners and such, very, very welcome. Barry?
Barry Leiba: Excuse me, this is Barry Leiba. I have two questions. One—the easier one—is about the: why does this have to wait for 5321bis? Doesn't this have a normative reference to 5321? If you make sure this has a normative reference to 5321bis, we can go ahead and finish processing this, and it will wait for 5321bis anyway because it will be part of the cluster.
Arnt Gulbrandsen: Well, as I remember, someone told me that it had to wait in order to have the correct RFC number. I don't recall checking it myself, so I may have picked it up wrong.
Barry Leiba: It's a minor thing, but, you know, I'd like to see us chuck it out and let the IESG have it rather than waiting. But I don't really care that much, so I just wanted to bring that up.
Arnt Gulbrandsen: Right. Thanks. So my understanding is that we can do Working Group Last Call and sometime later in the process it has to be blocked. Happy to be proved wrong, I don't really care. I do think that this needs to block until I have sent about a million generated email addresses through UTS 58, ICU, and this, and seen what differs and hopefully gotten the differences down to zero.
Barry Leiba: Okay, that's substantive. The other, probably more challenging question is about the BIDI issue. Are you talking about mixed left-to-right/right-to-left within the same label, or are you talking about an address where one label is left-to-right and another label is right-to-left?
Arnt Gulbrandsen: As I understand it, the worry concerns mixed left-to-right, except Arabic numbers, in the email address in general.
Barry Leiba: Right. Because if you play around with it, you can do such things as @local-part-domain, which is going to look terribly confusing. Right. I just—yeah, I'm just thinking of needs for that to happen in, say, an Israeli email address, where somebody might have an ASCII name and a Hebrew surname or something like that. But, yeah, now that you remind me what we're talking about, probably leaving it as "we're not going to worry about that" is the right answer. Okay, thanks.
Arnt Gulbrandsen: I have walked around trying to find these things and found that combining ASCII and non-ASCII is done only in a couple of locales that use left-to-right anyway. When people print something on their business cards, it's either all Hebrew or all ASCII. They don't mix so much in one address.
Ken Murchison: Okay, John, go ahead.
John Klensin: Hi John. Yeah, two things, one of which is that whoever told you to wait for email-core probably wasn't me, because the way email-core is going, well, it could be a long time. But that reflects the comment Barry made. The other I mentioned on the list—I said several things on the list—but the one that most concerns me is that with these two documents, in combination with the email-core documents, we're in danger of creating three separate standards which seem to contradict each other. And that is not a good state to be in. So I strongly suggest you carefully rethink whether these should actually update the existing SMTPUTF8 documents or otherwise make clear what the relationships are among the three. And I think there are several ways of doing that, but just ignoring that and having these three standards exist in parallel is probably not a good look. There's some other things in my note that I'd appreciate you looking at in the after-the-meeting time today.
Arnt Gulbrandsen: John, could you just refresh my memory: what is the relationship between RFC 6532 and the SMTP documents?
John Klensin: I can't even remember what 6532 was.
Arnt Gulbrandsen: That's the base SMTPUTF8.
John Klensin: Oh, okay.
Arnt Gulbrandsen: And that's the—that's going to be the address format one, isn't it? Or that's going to be the overall—that's going to be the headers one. Pretty much. I mean, this—it seems to me that these documents go in the cluster together with 6530, 32, and have the same relationship with the general SMTP documents that those documents have. Does that not make sense?
John Klensin: It does up to a point, but the difficulty is that those documents explicitly expanded what was allowed in the base email documents. And the base email documents say that at this point—if we ever get around to approving the email-core stuff. By contrast, what this does is to narrow what's permitted by the base SMTPUTF8 documents without in any way acknowledging that as updates or things like that. And that would seem to create conflicting or overlapping standards.
Arnt Gulbrandsen: Right, I see what you mean. Just for the record, the restriction is that it's in these documents; it's not legal to send XN-- in the domain part of an address. The rest is extension. So if you want to send an IDN, you have to send the UTF-8 form, not the XN evil form.
John Klensin: Well, so yes, that is a restriction. Could you suggest what the relationship should be? First of all, I'm certainly in favor of banning Punycode on the left-hand side. Allowing it is stupid, and we should have caught that with the SMTPUTF8 documents. This is one of the cases that I think I mentioned in my note, where I think the document would be more clear if you simply separated the discussion of the local part from the domain part. My email made it more clear. Sorry, too many VRs are working here. The email comment mentioned this. I think the document would be more clear if you simply separated the discussion of the local part from the domain part, which is exactly what 5321bis and 5322bis does. And I'm noticing Pete nodding.
John Klensin: But the other is that this is a restriction. It doesn't say you can't do that, but this is a restriction on the base SMTPUTF8 syntax because it says "use these addresses" and, by extension, "don't use any other addresses." And that is classic applicability statement stuff and classic BCP stuff, but not standards track stuff unless you're updating the core documents.
Ken Murchison: So can I follow up on what John's saying, because he's going in the same direction I am. My big concern here is these sound like closer to BCP in the sense that—and maybe AS—you're giving operational guidance to folks, right? You're saying, "Look, the base spec allows you to put all sorts of crap in here. And in order to have sane interoperability, it behooves you to—if you're creating email addresses, not if you're sending or receiving them, but in the actual creation of account names, this is what you should limit things to." Right? That's basically where these documents are going.
John Klensin: Yeah.
Ken Murchison: I think Pete and I are exactly on the same page.
Pete Resnick: Makes sense to me.
Ken Murchison: Pete and John, do you think that saying intended publication status BCP would solve the—or would put these in a sensible relationship to 5322?
Pete Resnick: That's what I'm wondering. And so, you know, there's this question of: is this syntactic requirement, or is this recommendation for how to formulate email addresses? And I think right now it's mushy between the two. And I think if you tighten them up, like John recommended and Barry thumbed up, getting rid of the right-hand side discussion almost entirely—getting rid of the domain name discussion—because the domain name discussion comes down to: stop using Punycoded right-hand side, you're supposed to use that one—you're supposed to use the U-labels, period. Right? You're squinting at me like you're not sure.
Arnt Gulbrandsen: Oh, no. I was wondering whether I could reword this to leave just the restriction on the domain and then reword the rest as... the local part must have such-and-such relationship with the domains. So the—I'm wondering whether that—I'm not sure what the answer is.
Pete Resnick: I guess what I'm pushing toward is: this is implementation guidance, not for people who are doing email clients, not for people who are doing email servers; this is implementation guidance for people who are setting up accounts. Right?
Arnt Gulbrandsen: More than that. Explain how. That's where I got—I lost the thread. Okay. There are evil addresses on the net. People will do things that you as recipient maybe don't want to do. So one of the questions is: can I display this email address? What's the rule set for "can I display this email address?" Or similarly, if I'm a spam filter, can I set the evil bit on this address? And then the spam filter will probably do something appropriate.
Pete Resnick: Right. Okay. So this is the end system after delivery, after it's gotten to where it's going and all that. This is the end system, whether displaying to the user, whether you're—right. Whether you're setting up a spam filter, whether you're creating an account. These are safe addresses versus these are probably unsafe addresses, either for simply handling or for the user to be seeing and all that. All of that sounds like implementation advice to not things that are interoperating on the network, but things on the ends. Right? You're giving advice to MUAs, you're giving advice to spam filters, you're giving advice to things that are not actually in the transport system at all. Right. So framing this more as "this is not so much a standard, this is advice, operational advice for if you're running an email system, these are things you're going to have to do"—that makes much more sense to me and gets you out of the John's issue, which is: where does this land, sort of, in the framework of the standards? John, do you agree?
John Klensin: Yeah, I think Pete and I are saying the same thing in slightly different directions. But I think we're saying the same thing. And I want to stress that I think these documents are a good idea. And we could quibble about some of the specifics of what's included or not included, but I think this is a good idea. The problem is that, as written right now, they create confusion. And that part of that is inevitable because you are going somewhere where the IETF for the last 30 years has carefully avoided going, which is talking about formulation and pre-delivery and things which don't affect the standard. I'm not objecting to that, but if you're going to venture into that turf, you need to be very careful. The document isn't careful enough right now. And that's got a bunch of different aspects. I don't think this is a hard problem. I think if we can get agreement in principle, you and Pete and I could work together on this—at the risk of volunteering him—you and Pete and I could work together on this and sort it out rather quickly, but it's a matter of agreeing on the principle and the problem.
Pete Resnick: Yeah. Yep. The other thing I would say, just with regard to the reference thing and holding it up for whatever: instead of right now the document has a normative reference to 5322. Just change that to a normative reference to 5322bis. There's a way to refer to the draft. Once that happens, go on with this document however we decide to go on with it, and magic will happen at the RFC editor level where they go, "Oh, well, we have to wait for this to happen," and all the little gears will grind.
Arnt Gulbrandsen: Fine. Fine. Pete, would you actually suggest wording for—
Pete Resnick: Let's sit down today or tomorrow, go over a little bit of stuff and then we can do it offline later with John. And yeah. Cool. Later today. I will try to help you later today and then by email we can include John and maybe set up a little meeting if we need to later. Okay.
John Klensin: That sounds right to me. My one qualification is that if we can avoid a normative dependency—we may not be able to—but if we can avoid a normative dependency on 5321bis or 5322bis, we will be better off because at the rate that email-core is moving right now, it could be years. Now, I hope we can solve that problem, but if we can get these documents, which I think are potentially useful, out there without having to depend on email-core situation speeding up, it could probably be a good thing.
Pete Resnick: Wait, wait, sorry. Which one's going to be years away? Any of email-core. No. No. Glad to hear it, but the amount of progress—sorry.
Ken Murchison: John, I'm just Jabber-scribe jumping in here. There's a bit of—this sounds more normative and stronger than just advice from a couple of people in chat. One of those was Jim and he's in the queue, so we can let Jim—Victor, why don't you go ahead?
Victor: Sure. Just a few things while we're talking about IDNA. I've recently observed that there's an awful lot of discord out there even amidst core DNS libraries—BIND and so on—seem to allow underscores in A-labels and U-labels, which is weird because the RFCs, IDNA, talk about A-labels and U-labels as part of NR-LDH, or at least for the A-label case, and underscores definitely aren't NR-LDH. I don't know if that overlaps with questions about defining syntax here or not, but there's sort of fundamental disagreements even on ignoring even questions about which exact Unicode characters are allowed. There's a question of which ASCII is allowed in an A-label that ought to be settled somewhere, I hope.
Victor: Also, since we're talking about email headers in 6532, I don't know who remembers, but the question did come up in some meeting some time ago that really Message-Global is a mistake. It's a—it runs counter to the design of MIME. Ned Freed at the time agreed that Message-Global is a disaster and we never should have had multiple layers of MIME encoding. I don't know where that should be tackled. I'm only raising it, you know, in this, with this presentation, simply because it's on the topic of internationalization and email. I don't know if others will be talking about the sort of the transmission and message representation rather than these external operational issues. Maybe my question's misplaced, but I really think we should at some point revisit the design of the internationalized email headers because it made a profound mistake and it should be undone at some point. So sorry, it's a soapbox rather than a question to the presenter.
Arnt Gulbrandsen: Well, I have a question to you then. Could you send me email basically telling me what you know about the differences, particularly regarding underscore?
Victor: Absolutely. I can send you lots of examples. I'm in the middle of implementing IDNA support in a stub resolver and so testing various implementations and I'm seeing just vast divergence from what's written in the specs and what actually is done in practice. You know, even things like whether dash-dash are allowed in the third and fourth characters should only apply to LDH labels, but implementations apply it even to labels that are, you know, Unicode, where it doesn't make sense to apply that rule. So there's all kinds of deviations where random implementers seem to have done popular things that don't match the specs that we may want to start thinking about at some point. Anyway, yeah. No comment on Message-Global except that I too hate it.
Ken Murchison: We would need somebody to take on that work or bring it to us. Thank you, Victor. Jim, go ahead.
Jim Fenton: Yeah, thanks. Is my audio coming through okay?
Ken Murchison: Yep, we can hear you fine.
Jim Fenton: Okay, great. Thanks. I'm concerned that—I don't understand all of the issues with Unicode, but what Arnt was saying earlier was that there are some combinations of Unicode characters that would actually be harmful. And if that's the case, I think we need to do something stronger than implementation guidance. And I think the way to structure this—sorry John, this makes a normative reference, but I think the way to structure this is to make this document be an updates RFC 6530 as well as having the normative reference so that it recognizes the fact that it is actually normatively saying that you should not do these things, that you must not do these things. One—right.
Arnt Gulbrandsen: One comment from me there: the danger that I know about is user confusion. You can usually—bad guys have this habit of leveraging user confusion to achieve things the users don't want. So the question becomes: are the ways to leverage that limited to addresses or do they apply to, for example, subject, which this document doesn't touch at all? And I'm not sure. I suspect it wouldn't touch subject. I'm really not sure.
Jim Fenton: Well, there are lots more ways that subject can be deceptive without even going to Unicode. I mean, it can just be deceptive. So I would tend to constrain this to addresses.
Arnt Gulbrandsen: Right. Is—I see what you're saying. I have no opinion.
John Klensin: Maybe I can step in here to help with this, as I said a bit of this in the chat. First of all, you don't want to try to update 5322bis because 5322bis basically says that if you've got non-ASCII characters in there, it's some other document's problem. And Pete can confirm that if he feels like getting up, but that's in essence where we are. There's an argument to be made that the things which have motivated these documents, especially the less restrictive one, are things which we just did not get right when we did the base SMTPUTF8 documents. And those things in a more perfect world, we might go in and update or replace those SMTPUTF8 documents to narrow the language and the permitted syntax as a matter of those base standards. I don't think anybody's proposed that because I don't think anybody's got the energy to do it. But we're treading into that area in which some of the things which this stuff says are in the "you really, really should not consider doing that if you want these things to interoperate" category, and the others are much more in the implementation guidance, best practice, applicability statement area.
John Klensin: I think if you want to get these documents finished in finite time, the best thing to do is to ignore that boundary, but the language can be more or less directive and deliver stronger or weaker warnings in different areas. And again, this is even more of a problem with the more general document than the more restrictive one. But you don't need to touch 5322bis or 5321bis for that matter, because what they say is there are basically other standards out there which deal with non-ASCII and these documents don't. With regard to the fussiness about XN-- in an all-ASCII name, those are decisions we made and documented in the original SMTPUTF8 documents and not only the SMTPUTF8 documents but the original IDNA documents. I think even IDNA 2003 as distinct from 2008.
John Klensin: And I think again, if you revise the language to really separate local parts and domain parts and talk about them separately and make the domain parts conformant to IDNA, these problems will basically vanish in any practical sense. The other piece of that with conformance to IDNA standpoint is that what this draft seems to say—I don't think it intends to—but what it seems to say is that if you're using—that you don't use A-labels on the domain part, but if you're going to use non-ASCII labels in the domain part, it's open season. And you really want to talk about U-labels there, because U-labels impose a whole series of restrictions about what you can do with the domain part, some of which interact with what we were just talking about.
Arnt Gulbrandsen: Do we have an RFC-able reference to U-labels?
John Klensin: Yeah. The basic IDNA UTF-8—basic IDNA 2008 documents. Cool. And again, I can help straighten the language out on this as long as we're all headed in the same direction about what we want.
Ken Murchison: Yeah, I think we are. I'm going to give Victor a quick last word here, and then I'm going to summarize where I think we're at.
Arnt Gulbrandsen: Give me a last word as well.
Ken Murchison: Go ahead, Victor.
Victor: Okay. So one thing about forbidding the use of XN-- in domain parts, I think that's a terrible mistake in terms of practical realities. There are lots of mail clients which simply don't do anything sensible if you try and use an IDNA domain instead of an ASCII domain. Some of them will automatically turn the—any UTF-8 that you type—automatically into the XN form before sending. It's a real mess out there. And sometimes you have no choice but to send the XN forms, and then they might even get through because of lack of support for SMTPUTF8 in the receiving HELO, despite the fact that it's a Punycoded domain. So I think forbidding it is a strong deviation from real-world practice. Also, I don't know how many might recall that in certificates, if your local part is ASCII, then the domain part is actually required to be Punycoded in order to fit into an RFC 822 name in the certificate. So you'll certainly see email addresses that have the domain Punycoded in certificates and might create confusion if you then disallow the same form on the wire. Not all the mail clients will necessarily handle that correctly. So I'm really concerned when I'm hearing that Punycode is to be forbidden in the domain part. I think that would be a mistake. Um, yeah. That's all for now.
Arnt Gulbrandsen: While John was thinking, I made up my mind. I agree with John and Pete. There are lots of ways to be deceptive in the wider email syntax, and using strong language to tighten up specification of one small part of it is not worthwhile, is my opinion. Victor, I'll answer you on the mailing list, okay?
Ken Murchison: Thank you. So what I'm hearing is—I think there's a consensus here that this will not be a proposed standard. It'll be more BCP/Informative. Arnt, Pete, and John are going to work together to rework the wording to that effect. And once it's posted, we can read it and see if we're all in agreement. Right. All right, thank you, Arnt.
Ken Murchison: Okay, next up, Alexey or Hans-Jörg, would either one of you want to give us a quick update on where PDI Archive is at this point?
[Presentation 3: draft-ietf-mailmaint-pacc]
Alexey Melnikov: Um, yes, I can try. Can you hear me?
Ken Murchison: We can.
Alexey Melnikov: Um, yeah, so, Lisa made a good effort to update the document. It's still, I think, as a personal draft name and we'll need to post a 00 in the working group. Main things are editorial clarifications and fixing examples. At this point, I think we want to get into various specific decisions that need to be made, like if we want—do we want to require compression formats? If we want compression, then which ones from a various myriad in use, like tar and gzip and, you know, zip and 7zip, etc., etc. So if people have opinions, please let us know. I don't know what's the best way of getting this sort of information. Maybe we should start a thread on the mailing list and have a discussion.
Ken Murchison: Yep. Yep. Ask the question on the list and hopefully we'll get some feedback.
Alexey Melnikov: Um, the other thing—the other thing we would like to know, which is probably a new issue, is for incremental exports. Do we want tombstones for deleted, like, messages or calendar entries, etc.? So, again, we might need to decide this by any particular type included in the export, but if people have an opinion. I think Lisa prefers to go with requiring tombstones and that have some form of UIDs. I think this will work for email messages themselves in particular because we already do this in other places like in Quick-Sync, for example. So any opinions on this? Doesn't look like any right now. Well, actually, Bron, do you have an opinion?
Bron Gondwana: Yeah, hang on. Sorry, I managed to click close on my tab switching from the notes to the tool, so I couldn't put myself in the queue. Um, I'm currently doing some stuff over in JMAP land around history of objects, being able to see the previous revisions of them, so I think it would be worth catching up with you on that and trying to coordinate so that what we do in history there is something that works well with the archive format as well.
Alexey Melnikov: Sounds good.
Ken Murchison: All right, anything else, Alexey or Hans-Jörg?
Alexey Melnikov: No, I think that's it.
Ken Murchison: Okay. Yeah, again, any open issues that you see, please start a thread on the mailing list. And whoever currently has the pen, if you could upload this as a working group document, the 00 document, that would be great.
Alexey Melnikov: Okay, noted. Thank you.
Ken Murchison: All right. Thanks, Alexey. Matt, you want to give us a quick update on PACC?
[Presentation 4: draft-ietf-mailmaint-pacc]
Matt: Hello. We've made one change since Montreal, which is to remove the MX configuration option. So there were previously two ways to configure PACC for a domain, and one of them was meant as a convenience for people whose email was hosted somewhere else. But because the security requirements for both the MX and for the primary method ended up being the same and requiring the same amount of work, it no longer felt more convenient. And so we've just removed that second option. Apart from that, I think the document's in a near-final state and is just waiting on some implementers. Mauro, did you have a comment?
Mauro: Yes. Go ahead. Hi. Yeah, I started implementing PACC and overall the specification is really clean. But while integrating it with other identity providers, I noticed that not all of them expose the OAuth well-known path and instead they use the OpenID one. So there's some providers—Keycloak and they're quite popular—that only expose OpenID. I know OpenID is not an IETF standard, but—and I don't know if we can reference non-IETF documents from an IETF document—but something to consider would be to offer like a—yeah, OpenID as a discovery option because the mail server cannot control what the identity provider offers. So that was my only comment.
Ken Murchison: We can certainly reference something outside IETF as long as there's a stable reference or link to it, if we think it's useful.
Mauro: Yeah, I will check in detail which are the ones. But I didn't know that while doing some research I noticed that not all of them expose the OAuth public-the-profile and instead they expose the OpenID discovery endpoint, which is very similar. So it's not a lot of work to implementers, but it would be nice that in addition to OAuth to also allow as an option an OpenID discovery endpoint.
Ken Murchison: Mauro, would you be willing to craft some text and send it to the list that can be incorporated?
Mauro: Sure. Yeah, I can do that.
Ken Murchison: Okay, great. All set then? Yep. All right. Thank you, Matt. Mauro, while you're still there, I will get you're up next with Object ID, so let me get your slides.
Ken Murchison: Do you want control or do you want me to control the slides?
Mauro: Yeah, please. I'd like control.
Ken Murchison: All right, let me... Okay, you should be all set.
Mauro: Okay. It should say "Object ID Plus" on the top. I see some blur, but I hope you can see it properly. Anyway, this is the revision 2 that I uploaded right before the session started. It has a few changes. It still needs some editorial changes that Bron is going to make, but this is so you get an idea of the latest version, how it works. So, what is new in Object ID Plus?
Mauro: So we got rid of the separate mailboxId, emailId, threadId, and so on. And now we have a single compound identifier called objectId, which contains as items the mailboxId, emailId, threadId, and so on. So these objectIds are different. What is inside an objectId compound identifier depends on what you're looking at. If it's a mailbox, it will have only accountId and mailboxId. And if you're looking as a message, it will contain only emailId and threadId. The distinction here is everything is optional. So the server can compose this objectId identifier with what they support. Even an empty compound objectId is valid.
Mauro: Object ID Plus also adds accountId for the account-level context. It also adds a response code to rename and it allows you to select mailboxes using objectIds. Okay, since Object ID Plus has a grammar that is not compatible with the previous specs, with the standard ABNF, it requires ENABLE. This detection has to be enabled. But it supports an implicit activation. You can either use the ENABLE command or by selecting a folder using objectId, also using STATUS or FETCH by passing objectId as a parameter. Yeah, and the server replies with the untagged response ENABLED.
Mauro: Well, this is just an example of SELECT and EXAMINE with objectId. Basically, yeah, you select the folder, objectId, and the server returns the compound identifier objectId with the items—with the IDs it supports. You can also select a folder using objectId but you also have to specify the folder name, which is worked as a fallback. Then, CREATE, also similar idea, similar concept. When the station is enabled—when the Object ID Plus extension is enabled and you create a folder—it will return the objectId of that folder. This is RENAME. It's new in Object ID Plus. It has a response: when you rename a folder, it will tell you—the server will let you know what is the objectId identifier for that folder. This is—here are two examples: visually renaming a folder will maintain the same identifier, unless you're moving the folder across accounts. In the second example shows that how the folder was assigned a new accountId. And, well, a mailboxId probably also will be used.
Mauro: Similar concept with STATUS: you include objectId, you get the—you include the objectId parameter and you obtain the objectId information and you can also enable the extension by doing that. FETCH, also the same: objectId is a parameter, it returns the emailId and threadId properties of the messages. The mailboxId and accountId are not returned because those are—you already know that when you select the folder, so that is not included in the response. As mentioned previously, the identifiers are optional. For example, a server that does not support threadIds will just return emailId. And if, let's say, it's a virtual message or something like that, it's also possible to receive an empty objectId identifier. Well, SEARCH, yeah, you can search by emailId, threadId. Also works with MULTISEARCH. And that's it, basically. So I'd like to hear your comments and questions.
Ken Murchison: Arnt, go ahead. Actually, before Arnt gets up here, I just want to say, Mauro, I like the new design. It borrows on what we've done with Quick-Sync with the implicit enable, which I think is a very nice feature.
Mauro: Yeah, yeah, I really like the way it looks now.
Ken Murchison: Okay, go ahead, Arnt.
Arnt Gulbrandsen: Sometime this morning, well, an opinion formed itself in my head regarding threadIds, which might change in either this document or in OBJECTID. I think that if threadId changes, then there should be a MUST somewhere in the server that the server pushes that to the client. Because in IMAP right now—well, in IMAP for the past 30 years—clients can cache things forever. If a server assigns new different threadIds, then that's its decision really. It should then have the burden of updating the client's cache offensively.
Mauro: Yeah, that's—so the IDs are basically static, so they follow the way that JMAP works. So if it breaks—yeah, if the server changes, it also will change the emailId and you should—yeah, basically also on when you're using IMAP, you should be using the CONDSTORE Quick-Sync synchronization. So I'm not sure how that will affect the synchronization, but in any case, if they want, they can—if they notice that the objectId changed, they can treat that as a new message and delete the old one and add it again to the cache.
Arnt Gulbrandsen: Sorry. As I recall, objectId, an emailId, a mailboxId, blah blah, is forever. It can be cached much like the content. It's not like flags, which change on a whim. Not cacheable.
Bron Gondwana: I might pop up to this microphone if that's okay, as the co-author on this. You have to have an escape hatch for when things—when things fall out of synchronization. And so there is a very strong guarantee one way and there's a slightly weaker guarantee the other way. The strong guarantee is that if you use the same mailboxId, the same emailId, not threadId—threadId can move—but the same mailboxId or emailId, you're guaranteed to get the same mailbox or the same email content. The other way is not true. For the same UID, you are not guaranteed to have the same emailId. Almost certainly will, but it could change. And that is an issue with client caching and forcing things. I think saying the server MUST is tricky, but certainly SHOULD push an invalidation is reasonable. At the moment, you already get an unsolicited update if a message has been updated when you're in CONDSTORE land. And saying that the server SHOULD, anywhere from SHOULD to MUST, include the emailId and threadId if they have changed is perfectly reasonable.
Arnt Gulbrandsen: That's what I would like, with an example.
Bron Gondwana: Yeah, I think that sounds good. You agree, Mauro? That the server already pushes these things, it adds them if it needs—if they've changed.
Mauro: Yeah, sure. Yeah, yeah, I agree.
Barry Leiba: What are the exceptions for the SHOULD?
Bron Gondwana: Yeah, what are the reasons for a SHOULD rather than a MUST? Basically, you can't—if you can't tell. We could say you always include them once it's enabled, unless you know they haven't changed. That could be reasonable. It's not much more to include the objectId data in changed items unless you have done something like a flag update on every single message in a mailbox, in which case you're going to get a flood of updates anyway once you're in CONDSTORE land. The problem with MUSTs is that then when the server doesn't do it, everyone gets confused. And with SHOULDs, the client knows that they—it's worth just doing a check every so often, just in case. And clients already have to deal with bullshit like servers getting confused about things that are supposed to be invariant. But the less strong you make it, the more they'll note to check.
Ken Murchison: Are we talking about the case where a server decides to change the algorithm it's using for IDs, or are we talking about a one-off edge case where...
Bron Gondwana: Either.
Ken Murchison: Okay.
Bron Gondwana: Yeah. I saw Mauro's comment about the idea of changing the UIDVALIDITY if you've changed emailIds. I wrote something 15 years ago or so on this, which I should send a link to on the mailing list. I hate changing UIDVALIDITY. It causes old clients that don't know what's going on to re-download everything. They throw away their entire cache. Which in some respects, great, you get a clean new read. In other respects, this client's downloading gigabytes of email that hasn't changed, and that's—I see some people who work on large servers in this room saying "No, do not ever change the UIDVALIDITY because it sucks for everyone."
Matt: Overall really like the design. I think one thing needs to be addressed is the interaction with JMAP access. So right now the JMAP access spec says that if you support JMAP access, you must also support objectId, which means that anyone who wanted to do Object ID Plus would also need to do just regular objectId and have all of those IDs for everything all of the time if they want to do JMAP access. There's also, I think, a lot of room for clarification within the Object ID Plus document about the interactions with JMAP access, because if you're looking at one, there's a lot of back and forth between them right now.
Matt: And then lastly, the JMAP access document specifies that any objectIds need to be the same between IMAP and JMAP if you support JMAP access. But it has some very weakly worded language about servers are encouraged to have the same flags between messages if they have—in both IMAP and JMAP. And it would be really nice if that was a much stronger guarantee. Basically, if a server supporting both JMAP access and objectId—if it was required to have the same flags between IMAP and JMAP, then you would be able to know from the IMAP side whether the server was following a Gmail model of having the same email in multiple mailboxes with the same flags, or you would just be in the IMAP regular world where you don't know if there's any connection between those flags of those emails. And it's really nice as a client to know that.
Mauro: Okay, yeah, yeah, I agree. JMAP access should be updated so it references the new Object ID Plus. And I'm fine with those. I think Arnt's author—of that JMAP access. Yeah, it was Arnt. So I don't know what's the right way to do this from a—from the IETF point of view. Like, should we reference the—in objectId, add like a section for JMAP access clarifying all this, or if we should create like a JMAP Access Plus or something like that? The problem with JMAP access as it is, is that it relies on objectId, which does not support accountIds, so it won't—in a—it won't work properly, basically, like in a multi-account scenario. So, yeah, it needs to be updated. But I'm not sure what's the best way to do this: either from the same document, Object ID Plus, or if we need to update JMAP access somehow.
Ken Murchison: This is Ken, with no hats on. Since we expect Object ID Plus to supersede objectId—and I doubt there's a ton of JMAP access deployment out there that's referencing objectId—personally I'd like to see one document that updates both. But that's up to the working group.
Mauro: Okay. I'd like to do one document that obsoletes both and says this is the one thing to implement, get rid of all the others. Keep supporting mailboxId for a bit until clients stop using it, but otherwise get everyone to just switch to the new unified working world.
Ken Murchison: Anybody in the room or online opposed to rolling in a JMAP access update in the same document? Or do people think they should be two separate with a reference? What do you think, Arnt?
Arnt Gulbrandsen: Go ahead, do it. The reason that JMAP access doesn't talk much about flags is that the flag semantics are not quite the same between the two and... I did not want to get into that corner of the world. Some IMAP servers have per-mailbox flags, some have per-message flags with hard-linked messages, things like that. It varies a little bit. I just did not want to nail that down. If someone wants to update it and deal with the problem, I'm their best friend in Albia.
Ken Murchison: One other point on the JMAP access: because it refers to objectId, any IMAP server that allows for shared mailboxes across users, the—someone trying to use JMAP access has no idea where the particular mailbox is because they can't get the accountId. So in order for JMAP access to be fully functional, it needs to have the accountId and the mailboxId.
Arnt Gulbrandsen: I don't see as—doesn't it effectively require that the IDs are unique on the JMAP side? Meaning that—
Mauro: No, the IDs are only unique within a single account. So you could have the same—you could have two mailboxes in two different accounts have the exact same ID.
Arnt Gulbrandsen: Yeah, but JMAP access is written such that the view that you have in this IMAP account is equivalent to the view that you have in one JMAP account. It just doesn't get into other accounts, either on JMAP or IMAP side.
Ken Murchison: If that was the intent, that's all it can do because it doesn't have an accountId that it can use. So if we update JMAP access to use Object ID Plus, then a JMAP client can find all mailboxes regardless of the account.
Arnt Gulbrandsen: But in that case, you also open—are you opposed to doing that? Well, there was a discussion outside the room in London where we decided to focus on the simple common case and leave out all the cases that a particular IMAP server can be configured to support but that complicate the whole thing. I'm not opposed, but I don't—I wouldn't want to edit such a document.
Ken Murchison: Okay, let's—I'll take the question of whether or not we're going to roll a JMAP access update into this document to the list, and we can hash out any details there. Bron, you were in the queue. Did you already say your bit? Pete?
Pete Resnick: No, oh shit. Hopefully you've got more of a comment than that. No, I—but enough of it's in the chat. We'll just—I'll take it off. Do you want to—do you want to hash—book in the chat. Okay. Alexey.
Alexey Melnikov: I think I did a quick scan and this is just a little thing. I think ENABLED responses caused by implicit enabling should include all other extensions that were enabled earlier. So, I can send an email on this, just to be consistent with enabled extensions, basically.
Ken Murchison: Yeah, I think you're right. I saw that when you put it in the—in the chat. But, yeah, that's—that's easily worked out. Yeah.
Ken Murchison: Arnt, are you back in the queue, or did you forget to take yourself out? Oh, I took myself out. Probably touched twice. Okay. Any other questions or input on Object ID Plus and/or JMAP access? Seeing none. Okay. Kai, do you want to give us a quick update on draft-ietf-mailmaint-unobtrusive-signatures?
[Presentation 6: draft-ietf-mailmaint-unobtrusive-signatures]
Kai: Yeah, hello. So regarding the draft, changes since last meeting: as announced on the list, guidance was added for CMS messages, but I'm not aware of any implementations yet. Kai, any chance you could either speak louder or up your...
Kai: Okay. Does this work better?
Ken Murchison: Yes, yes.
Kai: Okay. Okay. Should I repeat?
Ken Murchison: If you want to start from scratch, yeah.
Kai: Okay. So regarding the draft, changes since the last meeting: as announced on the list, guidance was added for CMS messages, but I'm not aware of any implementations yet. There have been discussions on canonicalization. Last time Bron had suggested to use the DKIM Simple for the message body. As I understand our group of editors agree this makes sense, but we haven't yet added that to the draft, so that's a to-do. However, the Thunderbird code has been added—has been updated to implement it. And regarding implementation, we made progress with the implementation in Thunderbird. Since yesterday, the Thunderbird Daily release channel for testing contains the initial implementation for OpenPGP messages and it's ready for public testing.
Kai: What does it do? For received or stored messages, Thunderbird will automatically verify and render a signature status of a message if it's a good signature. A limitation here of the implementation: it does not yet implement the header checks for protected headers. That's another to-do. And when producing signed messages, by default Thunderbird still uses the traditional multipart signed message structure. So if you want to use it, there's a preference that you have to enable to enable the new signatures for outgoing messages. Yeah, and we are still discussing when and how this default could change in the future. That's it from me.
Ken Murchison: Great, thank you Kai. Any questions or comments? Okay, good. Thank you very much. Thank you. That is the last presentation on our drafts. Any other business? Any proposal for new work? All right, don't see any. Thank you everyone. A reminder to when new drafts are posted, please review at least look at the diffs. Oh, Victor, sorry, go ahead.
Victor: Right. Well, new work, I would actually like to see, even though it might be hard work, to do something about Message-Global in MIME. I think it's maybe time to tackle that. Definitely if anybody would like to work out it with me or without me, but I think it should be done.
Ken Murchison: If you've got something you want to put down in text, we can certainly take a look at it.
Victor: Right. I mean, in the room are people, you know, think it's a terrible idea, you know, I mean, if it's going to go nowhere I'd like to be.
Ken Murchison: Well, I mean, when you first mentioned it, there was a lot of people nodding their heads that it was a horrible idea to begin with and it needs to die a quick death.
Victor: Okay. All right. Okay. Good. Thanks.
Ken Murchison: May I sneak in before? Well, if it's directly related to—Yeah, well, Victor, I would write it with you. I wouldn't take it on on my own. This is Arnt.
Ken Murchison: Thank you Arnt. Okay, Martin, go ahead.
Martin: Yes, I have a long-time plan to update the RFC 6068, that's the mailto URI scheme. But I was just waiting because the working group was busy with all kinds of other drafts, but I might start with a first draft. There's not too much in terms of content. I will make sure that we can have actual Unicode examples. I also plan—there's some wording there that says use UTF-8 for internationalized mail addresses and so on, but it's written in a forward-looking, hopeful way rather than saying it with a MUST or SHOULD, and so that should change. And I also plan to do some testing.
Ken Murchison: Sounds great. My only concern is whether or not that falls under our charter. I'd have to go back and read our charter.
Martin: Oh, okay. I was assuming that... I'm not thinking about, does it fall under the charter, I'm just thinking which group would it work best in.
Ken Murchison: That's what I'm thinking as well, and I'm looking over Barry and Pete to see if they have any suggestions. Does URL stuff have its own—
Barry Leiba: No, not at the moment. No, no.
Ken Murchison: Martin, I'll look at our charter and talk to Mary about it to see if it's something we can take on, and if not, it'll probably have to go to DISPATCH. But we'll let you know.
Barry Leiba: Sorry, I already logged off the thingy but... I don't think everything has to go to DISPATCH. I mean, if we think that tweaking our charter to include something is the right answer, we could just do that. But yeah, I'd have to look this over and see what—
Ken Murchison: Yeah, my only concern was that, you know, if there's URL police out there that want to have this, that, you know—
Barry Leiba: Yeah, well... so URI, first, URI, not URL. W3C calls them URLs, we call them URIs. But yeah, we need to look this over and see what—whether it's a good idea and whether it's within our scope.
Ken Murchison: Right. Anything else? All right, thank you all. A reminder: please read the drafts when they're posted, and authors please try to respond to any feedback in a timely fashion so we can move some of our documents along. If there's nothing else, we will see everybody in Vienna. Thank you.
Bron Gondwana: Beautiful place, Vienna.
Ken Murchison: You've already looked?
Bron Gondwana: It would be okay in the charter. DISPATCH is just going to send it here anyway.
Barry Leiba: Let's be proactive. Oh, I think it's fine. It's to do with internationalization. Yeah. Yeah, that certainly sounds like it. I mean, our charter is pretty broad for it—mail related. What does the area director think? Might as well stick with this. Our charter's pretty broad about dealing with mail-related things. It's arguable whether the mailto URI is a mail thing or a web thing. So, you know, but what we should do is look over what he wants to do, talk to Mark Nottingham about it, and see whether that end of things cares, and then make a decision from there what we should recommend that we do.
Ken Murchison: Yeah. If it was IMAP URIs, then I'd say it's definitely here.
Barry Leiba: Yeah, that's different. Right. But those are definitely IMAP things.
Ken Murchison: Yes. mailto is not really a mail thing. It's... nor is it a female thing. And there's kind of a section on—not mailto URIs specifically, but the AS in email-core talks about, you know, the addresses and what you should and shouldn't do. How was mailto not a mail thing? It does get used in email messages and points—it's an email address. You have to put it into an email.
Pete Resnick: But it—okay. So now we're going to go up into UA-land in a mail UA. When you click on a mailto URI, it does not go out to the web browser. It stays in the mail UA and generates a new message. It is the equivalent of "New Message To:".
Barry Leiba: I would buy that. That doesn't necessarily...
Pete Resnick: I mean, I think it's not an issue if we just check with the web side of things. I think so the it describes the headers of the email message to which you want to send a message. Yes. And when we have a mailto URI in DMARC or any of the DNS records where we have—I think they have mailto URIs, bits. It's not a web thing. So it really—
Ken Murchison: I say URIs are not web things, but we should check with the webby people and make sure there's no conflict. Oh, yeah, no, that's a good idea.
Pete Resnick: Yeah. And then I think—I think it is within our charter.
Ken Murchison: Sounds like it. As long as the web people don't think that we're stepping on them. That's all. Just check. That's easy to do. Yeah. It avoids—you don't want to fight with our friends over there. I don't think they'll want anything to do with email if they can avoid it. I don't think they're going to care. But, I think they'd probably care enough without saying "Oh, yes, thank you, please." I was going to say that DISPATCH is just going to send it back here. Right. There's no point in going to DISPATCH. Yeah. I don't think there's anywhere else that's going to want to do it. No, this is the sensible place. As I said, I—there's no harm in talking with the HTTP working group. Right. And if they want to somehow claim ownership of all URIs, but I don't think they're going to. I think it would just be a good thing to do to check in. It's a point.
Ken Murchison: As—as—might be—
[82:04] [End of recording]