--On Sunday, December 25, 2022 18:37 +1000 George Michaelson <ggm@xxxxxxxxxxxx> wrote: > If an expires: field was included in a dkim signature would it > alter how you felt about it? > > I understand your opposition due to risks of misapplication, > I'm asking if authenticity plays any role in this. > > Eg if dkim signed and date is after submission date, then I > feel differently to signed with an expires header in the past > even when sent. The first is a reasonable statement made by a > sender. The second can't really to be. George, Without speaking for Keith or anyone else to whom "how you felt" might have been addressed... First, consider two example cases where a message originator might want to specify an expiration for the message: (i) The message is a request or direction to the recipient to perform some specific action that, if not performed by some particular date (and time?), would be irrelevant or even problematic. Fairly clear what "lost validity" would mean in that case and worth noting that either the message originator, the recipient, or both might no be human. Keith's concerns about deletion (for record-keeping purposes if nothing else) still stand but having the message moved to another place and/or supplied with a clear warning to the recipient to not take the action would be useful and, in some cases, very important. (ii) The message contains information that times out. That would be the case for at least some of the Netnews feeds but, sticking to email, one could imagine a message titled "This Week's Weather Forecast" that one would like to time out and be automatically hidden or archived once it is no long a forecast. Again, I didn't say "delete" although I'd hope UIs would make it easy to clean those expired forecasts up without affecting messages that had expired for other reasons. In addition to reinforcing my comments about different meanings of "lost validity", DKIM authentication would probably be more than sufficient for the second case. For that case, "Expires" would be convenient but not very important if, e.g., that subject line instead read "Weather Forecast for the Week Ending 2022-12-31". For the first case and ones like it, I'd want to see authentication at the originator level, not by some MSA or MTA that was not, very directly, under the originator's control. So, no, DKIM authentication that the message came from some domain and was authorized _by the domain_ would not make me at all more comfortable. Something more like the following would work: Expires: Date-Time Interpretation Authorizer Signature with Date-Time: more or less the 5322 (or SEDATE) definition, with consideration of the "future date" issues. Interpretation: don't have a good idea about how to do this, but the difference between the two cases above, and other issues with "validity", suggest that it might be important (Cf. Tom Petch's comments around the 11th as well as more recent ones.) Authorizer: might be a different person or entity from the addresses in "From:" or "Sender:" and might use something other than an email address as a credential anchor. Signature: More like PGP or another Security Area-approved certificate and signature mechanism than like DKIM and applicable to this one, particular field. However, just in case it isn't obvious, I am confident that you understand the character and dimension of the rathole(s) that trying to get the above specified and agreed would take us into as well as I do. For starters, it is a very different proposal than draft-billon-expires-08, starting with a change from the syntax inherited from MIXER [RFC2156]. best, john -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
