[{"author": "John Levine", "text": "

Welcome to sunny Dublin

", "time": "2024-11-07T17:33:11Z"}, {"author": "Lisa Dusseault", "text": "

good morning from California

", "time": "2024-11-07T17:33:34Z"}, {"author": "Pete Resnick", "text": "

I think that doing nothing was the sense of the room some minutes ago.

", "time": "2024-11-07T17:37:51Z"}, {"author": "John Levine", "text": "

This is not a new problem, there are other full standards that have been obsoleted and it is for the IESG or RSE or some combination thereof.

", "time": "2024-11-07T17:40:03Z"}, {"author": "Pete Resnick", "text": "

I sent the IESG some email about the whole \"obsoleted Standard\" issue. It sounds like it is being dealt with (or at least thought about).

", "time": "2024-11-07T17:40:04Z"}, {"author": "Murray Kucherawy", "text": "

Is there any chance in H-E-double-hockey-sticks that a resolver in the future might notice an MX points to a CNAME and return an error rather than giving you the MX?

", "time": "2024-11-07T17:41:50Z"}, {"author": "Jim Fenton", "text": "

Do resolvers get into that level of detail about individual protocols? I think not.

", "time": "2024-11-07T17:52:19Z"}, {"author": "Murray Kucherawy", "text": "

I don't think they ever have, no, but nothing precludes them.

", "time": "2024-11-07T17:52:51Z"}, {"author": "Murray Kucherawy", "text": "

Just trying to make the text bulletproof.

", "time": "2024-11-07T17:52:57Z"}, {"author": "Alexey Melnikov", "text": "

Barry showed +1 to your (John Klensin's) proposal

", "time": "2024-11-07T17:53:23Z"}, {"author": "Steve Atkins", "text": "

I\u2019ve seen resolvers do some odd things, but not that. If one were to start I think it\u2019d be a bug in the resolver rather than something we need to consider.

", "time": "2024-11-07T17:56:52Z"}, {"author": "Murray Kucherawy", "text": "

Fair enough.

", "time": "2024-11-07T17:57:03Z"}, {"author": "Murray Kucherawy", "text": "

A mandatory extension isn't an extension anymore.

", "time": "2024-11-07T18:00:42Z"}, {"author": "Kenneth Murchison", "text": "

+1 to Murray about extensions

", "time": "2024-11-07T18:01:16Z"}, {"author": "Pete Resnick", "text": "

Side note not worth it for the mic: I pointed out to some people that there's a big security hole in SMTP if you don't do DNSSEC: I could do a DNS attack, insert an MX to my evil server, and get all of the mail that I want. That doesn't mean we need to say \"MUST use DNSSEC\". But we can point out such holes. (FYI: I am not suggesting we do so for DNSSEC. ;-) )

", "time": "2024-11-07T18:02:14Z"}, {"author": "Pete Resnick", "text": "

I think \"MUST NOT use TURN unless authenticated\" is probably correct. I can't think of any other exception case.

", "time": "2024-11-07T18:05:45Z"}, {"author": "Murray Kucherawy", "text": "

You almost need to do that for any protocol that requires name translation. Where do we draw the line?

", "time": "2024-11-07T18:05:54Z"}, {"author": "Pete Resnick", "text": "

@Murray Kucherawy Exactly my thought

", "time": "2024-11-07T18:06:23Z"}, {"author": "Pete Resnick", "text": "

But the same is true for TLS.

", "time": "2024-11-07T18:06:32Z"}, {"author": "Murray Kucherawy", "text": "

I'm having trouble coming up with a way to describe the semantic difference between \"SHOULD NOT unless\" and \"MUST NOT unless\" when we're talking about security rather than interoperability.

", "time": "2024-11-07T18:06:59Z"}, {"author": "Pete Resnick", "text": "

(That is, if you don't want people sniffing, every protocol needs to use TLS)

", "time": "2024-11-07T18:07:00Z"}, {"author": "Ricardo Signes", "text": "

something something rfc6919

", "time": "2024-11-07T18:09:54Z"}, {"author": "Pete Resnick", "text": "

I reduce my comment to \"whatever you want\".

", "time": "2024-11-07T18:10:47Z"}, {"author": "Murray Kucherawy", "text": "

Once again, it's worse than you think.

", "time": "2024-11-07T18:10:51Z"}, {"author": "Murray Kucherawy", "text": "

Damnit.

", "time": "2024-11-07T18:11:26Z"}, {"author": "Ricardo Signes", "text": "

\"They're marginal, they're obscure, and trying to enumerate them would be a waste of time.\" \u2014 welcome to email

", "time": "2024-11-07T18:11:50Z"}, {"author": "John Levine", "text": "

I think Paul said he uses ETRN, not TURN

", "time": "2024-11-07T18:12:09Z"}, {"author": "Alexey Melnikov", "text": "

I thought so too

", "time": "2024-11-07T18:12:25Z"}, {"author": "Kenneth Murchison", "text": "

Make TURN an extension? Probably not practical but if its not used widely, make it opt-in

", "time": "2024-11-07T18:12:25Z"}, {"author": "Murray Kucherawy", "text": "

ETRN is already, I think?

", "time": "2024-11-07T18:12:39Z"}, {"author": "John Levine", "text": "

@Kenneth Murchison too late, I think

", "time": "2024-11-07T18:12:40Z"}, {"author": "Alexey Melnikov", "text": "

ETRN is a separate RFC

", "time": "2024-11-07T18:12:54Z"}, {"author": "John Levine", "text": "

Yes, ETRN is an extension

", "time": "2024-11-07T18:12:56Z"}, {"author": "Pete Resnick", "text": "

I could not care less about the resolution to #111

", "time": "2024-11-07T18:15:40Z"}, {"author": "Kenneth Murchison", "text": "

Then why not deprecate and force folks to use ETRN (said while not knowing the diff between the two)

", "time": "2024-11-07T18:15:50Z"}, {"author": "Murray Kucherawy", "text": "

Isn't it deprecated? Or at least obsolete?

", "time": "2024-11-07T18:16:07Z"}, {"author": "Murray Kucherawy", "text": "

This is fine.

", "time": "2024-11-07T18:17:36Z"}, {"author": "Tero Kivinen", "text": "

I was asked to send a text listing security protocols to list, but as discussion moved forward while I was drafting this, is there any point of sending this to mailing list still:

\n
\n

There are multiple extensions that provide security services to email,
\nsome of which are outside the SMTP protocol itself. Non-exhaustive
\nlist of most important of them follows:

\n

- STARTTLS [xxx], MTA-STS [RFC8461] and DANE for SMTP [RFC7672]
\n offer confidentiality services between servers.

\n

- DKIM [RFC6376], DMARC [RFC7489], ARC [RFC8617] and SPF [RFC7208]
\n offer message level authentication services.

\n

- SMTP Authentication [RFC4954] offers authenticating clients
\n connecting to server.

\n

- S/MIME [RFC8551] and OpenPGP [RFC4880] exist to allow for message
\n confidentiality outside of the operation of SMTP.

", "time": "2024-11-07T18:18:19Z"}, {"author": "Murray Kucherawy", "text": "

104 is fine as proposed.

", "time": "2024-11-07T18:19:46Z"}, {"author": "Murray Kucherawy", "text": "

John K also thumbs-upped.

", "time": "2024-11-07T18:20:15Z"}, {"author": "Murray Kucherawy", "text": "

I'm ambivalent on this one too.

", "time": "2024-11-07T18:22:40Z"}, {"author": "Pete Resnick", "text": "

It turns out I could care less about #111, because I couldn't care less about #105.

", "time": "2024-11-07T18:22:48Z"}, {"author": "Murray Kucherawy", "text": "

Pete's official wikipedia page lists all of his issues in order of descending ambivalence.

", "time": "2024-11-07T18:23:36Z"}, {"author": "Murray Kucherawy", "text": "

There's even a dependency tree.

", "time": "2024-11-07T18:24:09Z"}, {"author": "Murray Kucherawy", "text": "

A few people won't be here tomorrow, so if we have time we should deal with more interesting stuff in the remaining time.

", "time": "2024-11-07T18:27:31Z"}, {"author": "Murray Kucherawy", "text": "

\"It's less minor than you think.\"

", "time": "2024-11-07T18:30:17Z"}]