[{"author": "Dave Crocker", "text": "

Did the in-person audience size just increasee by 25%?

", "time": "2025-11-03T22:01:16.000Z"}, {"author": "Murray Kucherawy", "text": "

16 plus the chairs

", "time": "2025-11-03T22:01:51.000Z"}, {"author": "Bron Gondwana", "text": "

@Dave Crocker we just base64 encoded the room contents

", "time": "2025-11-03T22:03:36.000Z"}, {"author": "Dave Crocker", "text": "

@Bron, new mime type for digitally capturing humans?

", "time": "2025-11-03T22:04:13.000Z"}, {"author": "Murray Kucherawy", "text": "

@Dave: RFC1437

", "time": "2025-11-03T22:04:49.000Z"}, {"author": "Bron Gondwana", "text": "

@Dave Crocker we're just going to encoded it in JSON:

\n
{\n   "status": "404 Not Found",\n   "error": "200 OK",\n}\n
", "time": "2025-11-03T22:05:07.000Z"}, {"author": "Dave Crocker", "text": "

(I'm working in a vote center in California. So input, if I can make any, will be by chat only.)

", "time": "2025-11-03T22:06:20.000Z"}, {"author": "Eliot Lear", "text": "

{ \"DaveCrockerOnLine\" : 200 }

", "time": "2025-11-03T22:06:51.000Z"}, {"author": "R. Latimer", "text": "

I requested time to discuss alternate approaches to rt= and nd=/pp=

", "time": "2025-11-03T22:06:59.000Z"}, {"author": "Dave Crocker", "text": "

Primary wg work is supposed to be on the mailing list, not in meetings.

", "time": "2025-11-03T22:08:18.000Z"}, {"author": "Trent Adams", "text": "

+1 to monthly interim meetings

", "time": "2025-11-03T22:08:23.000Z"}, {"author": "Kenneth Murchison", "text": "

@meetecho the mic camera is showing nothing

", "time": "2025-11-03T22:08:38.000Z"}, {"author": "Jim Fenton", "text": "

I'm supportive especially if it improves the transparency of the design process.

", "time": "2025-11-03T22:08:58.000Z"}, {"author": "Trent Adams", "text": "

I'd vote for monthly 60-minute meetings (90 is harder to work)

", "time": "2025-11-03T22:09:07.000Z"}, {"author": "Bron Gondwana", "text": "

@Trent we need the extra time to base64 the work

", "time": "2025-11-03T22:09:42.000Z"}, {"author": "Trent Adams", "text": "

LOL

", "time": "2025-11-03T22:09:49.000Z"}, {"author": "Dave Crocker", "text": "

Wait. You can base64 Trent???

", "time": "2025-11-03T22:10:10.000Z"}, {"author": "Trent Adams", "text": "

Mwahaahahhahaaa

", "time": "2025-11-03T22:10:37.000Z"}, {"author": "Murray Kucherawy", "text": "

We can base64 anyone. We have the will.

", "time": "2025-11-03T22:10:39.000Z"}, {"author": "Trent Adams", "text": "

Base128, please.

", "time": "2025-11-03T22:10:43.000Z"}, {"author": "Dave Crocker", "text": "

You also have the won't. Full Telnet option mechanism.

", "time": "2025-11-03T22:11:03.000Z"}, {"author": "Jim Fenton", "text": "

'mailversion'? Sounds confusing to me

", "time": "2025-11-03T22:11:53.000Z"}, {"author": "Daniel Gillmor", "text": "

congrats!

", "time": "2025-11-03T22:12:42.000Z"}, {"author": "Al Iverson", "text": "

Congrats!

", "time": "2025-11-03T22:12:47.000Z"}, {"author": "Pete Resnick", "text": "

@Jim: As with all, better names are welcome.

", "time": "2025-11-03T22:13:11.000Z"}, {"author": "Daniel Gillmor", "text": "

Mail-Version smells very similar to MIME-Version (but completely different semantics)

", "time": "2025-11-03T22:13:56.000Z"}, {"author": "Jim Fenton", "text": "

@pete I need to understand it first!

", "time": "2025-11-03T22:14:09.000Z"}, {"author": "Pete Resnick", "text": "

@DKG: Yeah, I had that reaction, but I'm an e-mail header geek.

", "time": "2025-11-03T22:14:23.000Z"}, {"author": "Kenneth Murchison", "text": "

sounds to me like Mail-History might work better

", "time": "2025-11-03T22:14:38.000Z"}, {"author": "Pete Resnick", "text": "

@Jim: It's the document-formally-known-as-the-message-change-algebra aka delta aka...

", "time": "2025-11-03T22:14:52.000Z"}, {"author": "Daniel Gillmor", "text": "

Message-Revision

", "time": "2025-11-03T22:14:52.000Z"}, {"author": "Trent Adams", "text": "

Heh - validation failure == sucessful experiment! :)

", "time": "2025-11-03T22:14:58.000Z"}, {"author": "Kenneth Murchison", "text": "

@dkg +1

", "time": "2025-11-03T22:15:01.000Z"}, {"author": "Pete Resnick", "text": "

Message-Delta

", "time": "2025-11-03T22:15:19.000Z"}, {"author": "Jim Fenton", "text": "

Yeah, that sounds more descriptive

", "time": "2025-11-03T22:15:22.000Z"}, {"author": "Murray Kucherawy", "text": "

The second version of his draft is in the tracker awaiting approval but I'm not presented with an \"Approve\" button.

", "time": "2025-11-03T22:15:22.000Z"}, {"author": "Murray Kucherawy", "text": "

...or link.

", "time": "2025-11-03T22:15:27.000Z"}, {"author": "Dave Crocker", "text": "

While it is silly to worry about small savings of characters, I will lobby for msg rather than message.

\n

msg-delta.

", "time": "2025-11-03T22:16:59.000Z"}, {"author": "Daniel Gillmor", "text": "

newlines -- your 30-year-old technical debt

", "time": "2025-11-03T22:17:08.000Z"}, {"author": "Daniel Gillmor", "text": "

I could live with msg-delta

", "time": "2025-11-03T22:18:50.000Z"}, {"author": "R. Latimer", "text": "

@Richard - I agree. It's essential for the success of the standard that the scope of change tracking be limited.

", "time": "2025-11-03T22:19:04.000Z"}, {"author": "Daniel Gillmor", "text": "

serioiusly, nice progress for Bron and Allen

", "time": "2025-11-03T22:20:50.000Z"}, {"author": "Dave Crocker", "text": "

Hmmm.... how about...

\n

msg-diff : ??

", "time": "2025-11-03T22:21:34.000Z"}, {"author": "Pete Resnick", "text": "

:-) Saving as many bytes as humanly possible!

", "time": "2025-11-03T22:21:59.000Z"}, {"author": "Daniel Gillmor", "text": "

diff is better than delta, imho

", "time": "2025-11-03T22:22:00.000Z"}, {"author": "Daniel Gillmor", "text": "

Pete that would be msg-dif:

", "time": "2025-11-03T22:22:23.000Z"}, {"author": "Daniel Gillmor", "text": "

(the second f is implied)

", "time": "2025-11-03T22:22:38.000Z"}, {"author": "Pete Resnick", "text": "

heh

", "time": "2025-11-03T22:23:27.000Z"}, {"author": "Dave Crocker", "text": "

the redundancy avoids the effort of confusing it with gif.

", "time": "2025-11-03T22:23:45.000Z"}, {"author": "Murray Kucherawy", "text": "

The \"mailversion\" draft's submission is stuck behind a datatracker bug. The tools team has been advised.

", "time": "2025-11-03T22:24:38.000Z"}, {"author": "Pete Resnick", "text": "

Maybe Bron can rename the header before the tools team fixes the bug.

", "time": "2025-11-03T22:25:04.000Z"}, {"author": "Murray Kucherawy", "text": "

It's not the name that's the problem, it's an individual submission replacing an individual submission, I'm told.

", "time": "2025-11-03T22:25:19.000Z"}, {"author": "Dave Crocker", "text": "

Expert required is a VERY high bar. It makes sense for things that can kill a system. This case isn't that.

", "time": "2025-11-03T22:25:53.000Z"}, {"author": "Dave Crocker", "text": "

high bar = expensive and slow.

", "time": "2025-11-03T22:26:10.000Z"}, {"author": "Dave Crocker", "text": "

Hence it is a disincentive to registration.

", "time": "2025-11-03T22:26:23.000Z"}, {"author": "Dave Crocker", "text": "

Registration is not the time to enforce protocol conformance (unless system operations are threatened.)

", "time": "2025-11-03T22:26:47.000Z"}, {"author": "Dave Crocker", "text": "

//

", "time": "2025-11-03T22:26:48.000Z"}, {"author": "Pete Resnick", "text": "

Yeah, I think FCFS seems fine for this. Shall I relay your comment Dave?

", "time": "2025-11-03T22:27:20.000Z"}, {"author": "Dave Crocker", "text": "

@pete, yes please.

", "time": "2025-11-03T22:27:36.000Z"}, {"author": "Pete Resnick", "text": "

ack. I'll do so at the end. 2 more slides.

", "time": "2025-11-03T22:28:04.000Z"}, {"author": "Murray Kucherawy", "text": "

Document unstuck.

", "time": "2025-11-03T22:28:07.000Z"}, {"author": "Dave Crocker", "text": "

There is a natural tendency to want to impose serious quality control at the time of registration. It has turned out to be counterproductive.

", "time": "2025-11-03T22:28:12.000Z"}, {"author": "Pete Resnick", "text": "

Go ahead and raise your hand if you want and I'll speak for you.

", "time": "2025-11-03T22:28:22.000Z"}, {"author": "Murray Kucherawy", "text": "

Wow I thought \"Received-SPF\" had faded away

", "time": "2025-11-03T22:28:51.000Z"}, {"author": "Dave Crocker", "text": "

:nauseated:

", "time": "2025-11-03T22:30:54.000Z"}, {"author": "Daniel Gillmor", "text": "

ok, msg-revision

", "time": "2025-11-03T22:32:02.000Z"}, {"author": "Eliot Lear", "text": "

Message-version?

", "time": "2025-11-03T22:32:03.000Z"}, {"author": "Andrew Newton", "text": "

msg-rvsn

", "time": "2025-11-03T22:32:16.000Z"}, {"author": "Phillip Tao", "text": "

I like \"revision\" over \"version\"

", "time": "2025-11-03T22:32:34.000Z"}, {"author": "Sam Sargeant", "text": "

\"revision\" > \"version\"

", "time": "2025-11-03T22:32:36.000Z"}, {"author": "Daniel Gillmor", "text": "

i also prefer \"revision\" over \"version\"

", "time": "2025-11-03T22:33:04.000Z"}, {"author": "Murray Kucherawy", "text": "

998 is 1000 (a reasonable limit at some point in the distant past) minus CRLF, and it's never been changed because backward compatibility

", "time": "2025-11-03T22:34:23.000Z"}, {"author": "Daniel Gillmor", "text": "

Richard Clayton: do you have any data to refer to the 64KiB limit you mentioned?

", "time": "2025-11-03T22:34:28.000Z"}, {"author": "Murray Kucherawy", "text": "

\"revision\" sounds good to me

", "time": "2025-11-03T22:34:53.000Z"}, {"author": "Dave Crocker", "text": "

msg was the first UA to support a reply function.

", "time": "2025-11-03T22:36:41.000Z"}, {"author": "Trent Adams", "text": "

Nothing about verfication + signing says anything about whether content is malicious or not.

", "time": "2025-11-03T22:37:36.000Z"}, {"author": "Trent Adams", "text": "

+1 to Bron's comment about signing... it's just the way to hang an identifier on who's handling a message.

", "time": "2025-11-03T22:38:20.000Z"}, {"author": "Eliot Lear", "text": "

There is actually a contributor to aipref with a username of \"sauron\"

", "time": "2025-11-03T22:38:26.000Z"}, {"author": "Murray Kucherawy", "text": "

I think this is just like the debate about the value of the valid signature: There's secret sauce here that we can't possibly specify.

", "time": "2025-11-03T22:38:37.000Z"}, {"author": "Dave Crocker", "text": "

When creating small amount of mechanism that is cheap to implement and use, it can be ok to not fully specify, ahead of time, how it will be used. DKIM actually qualified for that, IMO.

\n

When there a larger, more complex thing, it is not a good idea to be unclear how it will be used.

", "time": "2025-11-03T22:39:00.000Z"}, {"author": "Phillip Tao", "text": "

Signers can still attach two signatures, right? For the algorithmic agility comment, if the signer is not sure whether validators will support some new hash algorithm, they could sign with both the old and new, right?

", "time": "2025-11-03T22:39:17.000Z"}, {"author": "Wei Chuang", "text": "

+1 to Bron. l= doesn't identify who did modification while DKIM2 does.

", "time": "2025-11-03T22:39:19.000Z"}, {"author": "Jim Fenton", "text": "

There should at lease be some algorithms that are MUST implement

", "time": "2025-11-03T22:40:30.000Z"}, {"author": "R. Latimer", "text": "

DKIM allows the sender to claim responsibility. The user should always know if a 'fuzzy' decision has been made and if versioning is present, be able to see the changes themselves.

", "time": "2025-11-03T22:40:30.000Z"}, {"author": "Murray Kucherawy", "text": "

@Jim: That part is fine I think.

", "time": "2025-11-03T22:40:45.000Z"}, {"author": "Murray Kucherawy", "text": "

@Latimer: I fear that's wandering into user presentation territory, from which this audience has typically disqualified itself.

", "time": "2025-11-03T22:41:28.000Z"}, {"author": "Murray Kucherawy", "text": "

What about two actors in the handling chain, one adding something bad, and another removing it? Is this a case we should care about?

", "time": "2025-11-03T22:42:55.000Z"}, {"author": "Dave Crocker", "text": "

@murray, only if there is concern for a Victim In the Middle attack.

", "time": "2025-11-03T22:43:52.000Z"}, {"author": "Murray Kucherawy", "text": "

I guess it allows you to identify a bad actor and a good actor. But the complexity ...

", "time": "2025-11-03T22:44:59.000Z"}, {"author": "Daniel Gillmor", "text": "

sha256 is post-quantum!

", "time": "2025-11-03T22:47:01.000Z"}, {"author": "Trent Adams", "text": "

Would it all boil down to \"what I've received\" and attribute the reputation back to who I can? ... meaning, I'd simply \"trust\" the most recent handler (and whoever mishandled it before is treated as \"not being caught by the later hanlder\")?

", "time": "2025-11-03T22:47:22.000Z"}, {"author": "Jim Fenton", "text": "

I'm not clear on what the issue is on this. Maybe there are two modifications that cancel out; why does that matter?

", "time": "2025-11-03T22:48:01.000Z"}, {"author": "Eliot Lear", "text": "

For the minutes, \"Richard tempts fate\".

", "time": "2025-11-03T22:49:04.000Z"}, {"author": "Daniel Gillmor", "text": "

agreed, nation states are indeed a fiction.

", "time": "2025-11-03T22:49:16.000Z"}, {"author": "Jim Fenton", "text": "

Do you mean \"DKIM2-Signature header field?

", "time": "2025-11-03T22:50:25.000Z"}, {"author": "Murray Kucherawy", "text": "

@Jim: It could matter if you're trying to identify bad actors and tweak their reputations.

", "time": "2025-11-03T22:51:10.000Z"}, {"author": "Murray Kucherawy", "text": "

This message is clean!

\n

Yeah well at one point it wasn't. Do you want to know where?

", "time": "2025-11-03T22:51:52.000Z"}, {"author": "Dave Crocker", "text": "

@murray, is the site that removes the breakage also a bad actor, since it is seeking to hide the original offense?

", "time": "2025-11-03T22:51:55.000Z"}, {"author": "Murray Kucherawy", "text": "

@Dave: Also a good question.

", "time": "2025-11-03T22:52:09.000Z"}, {"author": "Jim Fenton", "text": "

Many recipient domains are happy if their customer doesn't complain.

", "time": "2025-11-03T22:52:34.000Z"}, {"author": "Dave Crocker", "text": "

@murray, my serious point from this and an earlier comment is that this seems an interesting but excessive concern. Fun for geeks and irrelevant for email operations.

", "time": "2025-11-03T22:53:13.000Z"}, {"author": "Murray Kucherawy", "text": "

Might be an attractive nuisance, I agree.

", "time": "2025-11-03T22:53:43.000Z"}, {"author": "Dave Crocker", "text": "

@jim, you mean there are some domains that are unhappy if their customers don't complain?

", "time": "2025-11-03T22:53:59.000Z"}, {"author": "Jim Fenton", "text": "

No, did I say that backwards? I meant that lack of complaints is sufficient to make the mail operator happy.

", "time": "2025-11-03T22:56:41.000Z"}, {"author": "Dave Crocker", "text": "

SMTP is not where message separations occur for BCC. It happens during submission.

", "time": "2025-11-03T22:58:04.000Z"}, {"author": "Dave Crocker", "text": "

The UA decides to submit differentially,

", "time": "2025-11-03T22:58:25.000Z"}, {"author": "Jim Fenton", "text": "

Hashing the recipient list isn't sufficient to satisfy privacy concerns. If I just wanted to see if my boss was bcc'ed on a message I received, it would be easy to try a few address combinations and see if any of them hash to the right thing.

", "time": "2025-11-03T22:59:32.000Z"}, {"author": "Daniel Gillmor", "text": "

Jim++

", "time": "2025-11-03T23:00:42.000Z"}, {"author": "Dave Crocker", "text": "

@eliott++

", "time": "2025-11-03T23:02:46.000Z"}, {"author": "Pete Resnick", "text": "

And replay protection is in our charter.

", "time": "2025-11-03T23:04:26.000Z"}, {"author": "Murray Kucherawy", "text": "

What's the concern with milter? SMTP extensions?

", "time": "2025-11-03T23:04:56.000Z"}, {"author": "Jim Fenton", "text": "

Can a milter accept a message for multiple recipients and break it into individual messages?

", "time": "2025-11-03T23:05:39.000Z"}, {"author": "Murray Kucherawy", "text": "

Yes,

", "time": "2025-11-03T23:05:45.000Z"}, {"author": "Murray Kucherawy", "text": "

It's not pretty but yes.

", "time": "2025-11-03T23:06:01.000Z"}, {"author": "Jim Fenton", "text": "

thanks

", "time": "2025-11-03T23:06:12.000Z"}, {"author": "Murray Kucherawy", "text": "

You end up doing individual injections for the broken out messages.

", "time": "2025-11-03T23:06:23.000Z"}, {"author": "Eliot Lear", "text": "

If I understand what is being proffered, this would be a new capability that would have to be invoked by the milter signaling to the mailer in some way.

", "time": "2025-11-03T23:06:47.000Z"}, {"author": "Eliot Lear", "text": "

That is, if you're trying to provide additional information in what is effectively an additional attribute of an envelope.

", "time": "2025-11-03T23:07:43.000Z"}, {"author": "Murray Kucherawy", "text": "

Yeah milter itself can't do this. What you end up doing is accepting the message for N recipients and discarding it, then doing new injections with the split-out message, one per recipient.

", "time": "2025-11-03T23:08:26.000Z"}, {"author": "Jim Fenton", "text": "

How does #2 work for an end user who expects bcc to be private but it's not really?

", "time": "2025-11-03T23:08:41.000Z"}, {"author": "Murray Kucherawy", "text": "

But to the MTA talking to milter, that works.

", "time": "2025-11-03T23:08:46.000Z"}, {"author": "Dave Crocker", "text": "

BCCs are sent separate from To/CC recipients.

", "time": "2025-11-03T23:09:43.000Z"}, {"author": "Murray Kucherawy", "text": "

As in different envelopes?

", "time": "2025-11-03T23:09:56.000Z"}, {"author": "Dave Crocker", "text": "

Yes.

", "time": "2025-11-03T23:10:04.000Z"}, {"author": "Murray Kucherawy", "text": "

That's not how sendmail works at least.

", "time": "2025-11-03T23:10:05.000Z"}, {"author": "Jim Fenton", "text": "

Do we otherwise try to correlate To: addresses with envelope To or is this the first time?

", "time": "2025-11-03T23:10:15.000Z"}, {"author": "Pete Resnick", "text": "

It would have to be completely separate messages.

", "time": "2025-11-03T23:10:19.000Z"}, {"author": "Daniel Gillmor", "text": "

Pete: semantically not completely separate, right? you wouldn't vary the Message-ID, for example.

", "time": "2025-11-03T23:10:42.000Z"}, {"author": "Dave Crocker", "text": "

@murray, you think sendmail sends BCC copies in the same posting as 'public' recipients???

", "time": "2025-11-03T23:10:48.000Z"}, {"author": "Murray Kucherawy", "text": "

I know it does.

", "time": "2025-11-03T23:10:56.000Z"}, {"author": "Pete Resnick", "text": "

@dkg: Yes, correct.

", "time": "2025-11-03T23:11:23.000Z"}, {"author": "Murray Kucherawy", "text": "

The Bcc recipients are not visible in the header fields, but they are present in the envelope.

", "time": "2025-11-03T23:11:25.000Z"}, {"author": "Murray Kucherawy", "text": "

(assuming the visible and not-visible recipients are behind the same next hop)

", "time": "2025-11-03T23:12:06.000Z"}, {"author": "Murray Kucherawy", "text": "

It's pretty true to the RFC and tries to minimize the number of transactions per message.

", "time": "2025-11-03T23:12:58.000Z"}, {"author": "Dave Crocker", "text": "

If you are talking about sendmail taking just the message and then formulating the SMTP side of things, that is a local (non-standard) implementation convention.

\n

If you are saying that mail goes out in a single, standardizeed SMTP session, with a RCPT-TO list that include public and bcc addresses, please explain..

", "time": "2025-11-03T23:14:00.000Z"}, {"author": "Jim Fenton", "text": "

Wouldn't #1be a problem for email incoming security service providers? Recipient domains wouldn't necessarily want to delegate a signing key to them.

", "time": "2025-11-03T23:14:56.000Z"}, {"author": "Murray Kucherawy", "text": "

I think again if the intermediary SMTP server receives both visible and invisible recipients in one session and it determines that they're going to relay to the same place, it continues to happen in a single transaction.

", "time": "2025-11-03T23:14:59.000Z"}, {"author": "Dave Crocker", "text": "

ohhh, wait. You mean that bcc recipients do not get a copy that indicates that it is a bcc copy. So they have no clear indication of why they got a copy. sigh.

", "time": "2025-11-03T23:15:06.000Z"}, {"author": "Pete Resnick", "text": "

The assumption is that the downstream SMTP will not create a Received field with all of the Bcc receipients revealed, but as Richard said, sometimes they don't do that very well.

", "time": "2025-11-03T23:15:13.000Z"}, {"author": "Murray Kucherawy", "text": "

Correct.

", "time": "2025-11-03T23:15:15.000Z"}, {"author": "Murray Kucherawy", "text": "

There's a feature(?) of sendmail that will add the \"for\" clause to a Received field only if there's a single recipient.

", "time": "2025-11-03T23:15:46.000Z"}, {"author": "Jim Fenton", "text": "

I thought that feature was more-or-less universally implemented.

", "time": "2025-11-03T23:16:17.000Z"}, {"author": "Murray Kucherawy", "text": "

Anything else could reveal something you're not supposed to know.

", "time": "2025-11-03T23:16:21.000Z"}, {"author": "Dave Crocker", "text": "

:weary:

", "time": "2025-11-03T23:16:26.000Z"}, {"author": "Murray Kucherawy", "text": "

@Jim: Might be. I only know sendmail. :)

", "time": "2025-11-03T23:16:35.000Z"}, {"author": "Daniel Gillmor", "text": "

seems like the problem around Bcc is that it is congruent (by some measures) with a replay attack, right?

", "time": "2025-11-03T23:16:38.000Z"}, {"author": "Murray Kucherawy", "text": "

@dkg: Yup.

", "time": "2025-11-03T23:16:49.000Z"}, {"author": "Jim Fenton", "text": "

@murray as in, I thought it was in a standard somewhere

", "time": "2025-11-03T23:16:55.000Z"}, {"author": "Pete Resnick", "text": "

Which is why the current version basically says, \"Send a separate message for each Bcc\"

", "time": "2025-11-03T23:17:13.000Z"}, {"author": "Murray Kucherawy", "text": "

@Jim: You're right, 5321 S4.4

", "time": "2025-11-03T23:19:26.000Z"}, {"author": "Daniel Gillmor", "text": "

https://datatracker.ietf.org/doc/html/rfc5321#section-7.2

", "time": "2025-11-03T23:21:55.000Z"}, {"author": "Daniel Gillmor", "text": "

\"Since this rule is often violated in
\n practice, and cannot be enforced, sending SMTP systems that are aware
\n of \"bcc\" use MAY find it helpful to send each blind copy as a
\n separate message transaction containing only a single RCPT command.\"

", "time": "2025-11-03T23:22:15.000Z"}, {"author": "Jim Fenton", "text": "

aha

", "time": "2025-11-03T23:22:48.000Z"}, {"author": "Dave Crocker", "text": "

DKIM 'interoperability'. What Wei is describing is not really interoperability. It sounds like a form a gatewaying (translating) between heterogeneous services.

", "time": "2025-11-03T23:22:56.000Z"}, {"author": "Pete Resnick", "text": "

@Dave: I have yet to hear a good story of what they mean to figure out what the right word is.

", "time": "2025-11-03T23:24:23.000Z"}, {"author": "Pete Resnick", "text": "

I suspect you are correct.

", "time": "2025-11-03T23:24:55.000Z"}, {"author": "Dave Crocker", "text": "

@Pete, my concern is that it not be called interoperability, since the difference is important, and implies 'transition' that won't happen.

", "time": "2025-11-03T23:25:23.000Z"}, {"author": "Murray Kucherawy", "text": "

@Dave: \"Backward\" compatibility of some kind?

", "time": "2025-11-03T23:25:32.000Z"}, {"author": "Daniel Gillmor", "text": "

\u2026or not 2b

", "time": "2025-11-03T23:26:08.000Z"}, {"author": "Jim Fenton", "text": "

that is the question

", "time": "2025-11-03T23:26:39.000Z"}, {"author": "Dave Crocker", "text": "

@murray, it is definitely NOT backward compatibility. The current design is a fully-separate service. Like IPv4 vs. IPv6.

", "time": "2025-11-03T23:26:56.000Z"}, {"author": "Pete Resnick", "text": "

No speaking in iambic pentameter during WG sessions.

", "time": "2025-11-03T23:27:01.000Z"}, {"author": "Jim Fenton", "text": "

haiku only, then?

", "time": "2025-11-03T23:27:15.000Z"}, {"author": "Murray Kucherawy", "text": "

Sign all header fields.

\n

We know that's complicated.

\n

DKIM is like that.

", "time": "2025-11-03T23:27:33.000Z"}, {"author": "Murray Kucherawy", "text": "

(@Jim: ask and ye shall receive)

", "time": "2025-11-03T23:27:53.000Z"}, {"author": "Daniel Gillmor", "text": "

i think those systems need to be dealt with because they're blocking our ability to evolve the mailsystem

", "time": "2025-11-03T23:28:57.000Z"}, {"author": "Murray Kucherawy", "text": "

Perl?!
\nThere's yer problem.

", "time": "2025-11-03T23:29:09.000Z"}, {"author": "Dave Crocker", "text": "

The fields that need to be signed need to be because they entail some security/privacy/abuse issues.

\n

That requires an analysis of the field and documentation of the meaningful threat.

\n

Hence, there should be a registry of fields that must be signed.

", "time": "2025-11-03T23:29:10.000Z"}, {"author": "Murray Kucherawy", "text": "

@Dave: Or sign 'em all.

", "time": "2025-11-03T23:29:31.000Z"}, {"author": "Dave Crocker", "text": "

No.

", "time": "2025-11-03T23:29:41.000Z"}, {"author": "Pete Resnick", "text": "

@dkg: I think I noticed your first sentence was da-dah-da-dah-da-dah-da-dah-da-dah... Well played.

", "time": "2025-11-03T23:29:53.000Z"}, {"author": "Murray Kucherawy", "text": "

That some operators need guidance about what fields need signing is a recurring source of concern for me.

", "time": "2025-11-03T23:29:58.000Z"}, {"author": "Daniel Gillmor", "text": "

Pete: :innocent:

", "time": "2025-11-03T23:30:06.000Z"}, {"author": "Dave Crocker", "text": "

Given the real messiness of global email operations, 'sign all' is going to cause problems. So, simplistic design does not produce simplistic operations.

", "time": "2025-11-03T23:30:26.000Z"}, {"author": "Daniel Gillmor", "text": "

Dave: what problems?

", "time": "2025-11-03T23:31:00.000Z"}, {"author": "Dave Crocker", "text": "

Excluding X- is an examplle of not signing 'all' fields. There will be more.

", "time": "2025-11-03T23:31:15.000Z"}, {"author": "R. Latimer", "text": "

Sign only headers that are visible to users of on which users or their agents may base their decisions. This keeps change tracking to specialist software (forwarders and mailing lists) where some guarantees can be given that the process will be carried out correctly. Don't impose this requirement on every hop.

", "time": "2025-11-03T23:31:25.000Z"}, {"author": "Dave Crocker", "text": "

@latimer, what is the list of fields that are visible to users. Please document that this list is valid. (Hint, there isn't one, so you won't be able to, because different systems show different fields.)

", "time": "2025-11-03T23:32:30.000Z"}, {"author": "Murray Kucherawy", "text": "

R. Latimer: That guidance is probably quite correct, but the problem is that some operators/implementers don't know which ones those are.

", "time": "2025-11-03T23:32:37.000Z"}, {"author": "Dave Crocker", "text": "

@dan, breakage.

", "time": "2025-11-03T23:32:55.000Z"}, {"author": "Pete Resnick", "text": "

The \"or their agents\" is doing a lot of work.

", "time": "2025-11-03T23:33:18.000Z"}, {"author": "Murray Kucherawy", "text": "

Yep

", "time": "2025-11-03T23:33:29.000Z"}, {"author": "Daniel Gillmor", "text": "

Dave, i don't think that's an answer

", "time": "2025-11-03T23:33:50.000Z"}, {"author": "Dave Crocker", "text": "

@dan, eg, the list of 'all' varies as a message transits, so signer and validator might use a different list of fields.

", "time": "2025-11-03T23:33:51.000Z"}, {"author": "Dave Crocker", "text": "

Again: register the fields that must be signed and justify why they must be signed.

", "time": "2025-11-03T23:34:46.000Z"}, {"author": "Murray Kucherawy", "text": "

When the registry changes, how do operators get notified to update their stuff?

", "time": "2025-11-03T23:35:06.000Z"}, {"author": "Dave Crocker", "text": "

@murray, yeah. That was in the PHL discussion with Bron. I think I came up with an answer but am not recalling the detail right now.

", "time": "2025-11-03T23:35:42.000Z"}, {"author": "Murray Kucherawy", "text": "

We could publish it in the DNS.

", "time": "2025-11-03T23:35:59.000Z"}, {"author": "Murray Kucherawy", "text": "

(hides)

", "time": "2025-11-03T23:36:01.000Z"}, {"author": "Jim Fenton", "text": "

Microsoft Exchange adds all sorts of opaque header fields to the mail going to my alumni address. If it then passed through another Exchange instance, would it just add more or would it replace the opaque stuff? I don't know, but that leads to a little concern about signing everything.

", "time": "2025-11-03T23:36:20.000Z"}, {"author": "Pete Resnick", "text": "

(Wes snuck into the queue. He shall be quick!)

", "time": "2025-11-03T23:36:22.000Z"}, {"author": "Murray Kucherawy", "text": "

(Removes Wes from queue)

", "time": "2025-11-03T23:36:31.000Z"}, {"author": "Murray Kucherawy", "text": "

(ok not really)

", "time": "2025-11-03T23:36:39.000Z"}, {"author": "Wei Chuang", "text": "

+1 to what dkg said which is to avoid gaps

", "time": "2025-11-03T23:37:22.000Z"}, {"author": "Dave Crocker", "text": "

@murray, I think the answer was: look in the registry when signing and sign the ones you have whenb doing the signing.

\n

Validator also looks in registry and does the same.

\n

Deal with potential changes to registry, between the time of signing and validating by time-stamping the registry entries...

", "time": "2025-11-03T23:38:21.000Z"}, {"author": "Murray Kucherawy", "text": "

The registry has to be queryable; do we have a way to do that?

", "time": "2025-11-03T23:38:52.000Z"}, {"author": "R. Latimer", "text": "

Unix timestamps.

", "time": "2025-11-03T23:39:04.000Z"}, {"author": "Murray Kucherawy", "text": "

Keep using what works.

", "time": "2025-11-03T23:39:52.000Z"}, {"author": "Daniel Gillmor", "text": "

unix timestamps are fine

", "time": "2025-11-03T23:40:27.000Z"}, {"author": "Dave Crocker", "text": "

@murray, perhaps have registry use a version number, incrementing for each registry addition, and signer includes the highest registry version number is uses. (This avoids a possible timestamp race.)

", "time": "2025-11-03T23:44:48.000Z"}, {"author": "Dave Crocker", "text": "

The flags are generally trying to impose enterprise level controls on the global email service.

", "time": "2025-11-03T23:45:36.000Z"}, {"author": "Murray Kucherawy", "text": "

It does use the usual \"It's just a request\" language.

", "time": "2025-11-03T23:46:15.000Z"}, {"author": "Murray Kucherawy", "text": "

(\"it's wafer thin!\")

", "time": "2025-11-03T23:46:19.000Z"}, {"author": "Pete Resnick", "text": "

@Dave: Yep. Exploded is at best a polite hint. The rest are the \"Please do what I want\" flags.

", "time": "2025-11-03T23:46:28.000Z"}, {"author": "John Levine", "text": "

FOSDEM CfP https://github.com/modern-email/FOSDEM-26

", "time": "2025-11-03T23:53:35.000Z"}, {"author": "Stefan Ubbink", "text": "

https://fosdem.org/2026/ (31 jan + 1 feb 2026)

", "time": "2025-11-03T23:53:43.000Z"}, {"author": "Bron Gondwana", "text": "

I have also been to FOSDEM - I think three times now

", "time": "2025-11-03T23:53:52.000Z"}, {"author": "Bron Gondwana", "text": "

but I dont think I can do this next one

", "time": "2025-11-03T23:54:07.000Z"}, {"author": "Dave Crocker", "text": "

\"It will be much easier\" always has a strong appeal to designers. What it tends to miss is \"it works now and making a change incurs risk\"

", "time": "2025-11-03T23:56:39.000Z"}, {"author": "R. Latimer", "text": "

Sensible simplification.

", "time": "2025-11-03T23:56:49.000Z"}, {"author": "Murray Kucherawy", "text": "

I recall wrapping on semicolons, colons within h=, and anywhere in the b=

", "time": "2025-11-03T23:57:37.000Z"}, {"author": "Bron Gondwana", "text": "

@Murray yes you can split after the = sign because they tag-value format says it strips leading whitespace

", "time": "2025-11-03T23:59:11.000Z"}, {"author": "Dave Crocker", "text": "

@pete, moving polite hings to a separate header field permits them to be specified and consider independently of the sig/authentication task.

", "time": "2025-11-03T23:59:34.000Z"}, {"author": "Dave Crocker", "text": "

btw, are people clear that these new signatures are by mediators, rather than MTAs?

", "time": "2025-11-04T00:00:24.000Z"}, {"author": "Kenneth Murchison", "text": "

enjoy dinner folks!

", "time": "2025-11-04T00:01:24.000Z"}, {"author": "Bron Gondwana", "text": "

I am clear :)

", "time": "2025-11-04T00:01:28.000Z"}, {"author": "Daniel Gillmor", "text": "

:clap:

", "time": "2025-11-04T00:01:50.000Z"}, {"author": "Pete Resnick", "text": "

Thank you all!

", "time": "2025-11-04T00:01:54.000Z"}, {"author": "R. Latimer", "text": "

Thank you.

", "time": "2025-11-04T00:02:01.000Z"}]