Richard Clayton wrote in
 <n8x6p$dhkkynf...@highwayman.com>:
 |-----BEGIN PGP SIGNED MESSAGE-----
 |Hash: SHA1
 |
 |In message <20250305184412.8asro9Ar@steffen%sdaoden.eu>, Steffen
 |Nurpmeso <stef...@sdaoden.eu> writes
 |
 |>And not to talk about the possible privacy issues if such a DKIM2
 |>header escapes into the wild, shall
 |>
 |>| rt=        | RFC5321.rcpt-to
 |>but also
 |>| mf=        | RFC5321.mail-from
 |
 |this information is recorded in other header fields already -- in what
 |scenario does a single header field escape ??

You mean this:

  Received: from [127.0.0.1] (port=11981 helo=happyday.al.cl.cam.ac.uk)
          by mail.highwayman.com with esmtp (Exim 4.98)
          (envelope-from <rich...@highwayman.com>)
          id 1tpufV-00000000CV2-0aGp
          for ietf-dkim@ietf.org;
          Wed, 05 Mar 2025 19:44:37 +0000

This is very likely exim specific, you will not see this for
postfix and others, maximally you get "for <addr>" in a trace
header; that is, possibly configuration is possible, but hardly,
hardly to be seen.

Having said that, i put effort not to reveal such data in ACDC.
It is of course -- in my opinion at least -- a design pitfall to
do otherwise, and move on-the-fly SMTP 5321 into the permanent
storage IMF 5322 level.  Especially so for Bcc receivers.
I mean, just today i got an email via yahoo, it does not even show
the for, nothing RFC 5321 at all, no?  From a pretty public list
(in my case 99+ percent of all messages passed a M-L ..):

  Received: from sonic311-27.consmr.mail.ne1.yahoo.com 
(sonic311-27.consmr.mail.ne1.yahoo.com [66.163.188.208])
          by sdaoden.eu (Postfix) with ESMTPS id 5E2BA1605A
          for <stef...@sdaoden.eu>; Wed, 05 Mar 2025 20:22:27 +0100 (CET)
  Received: from sonic.gate.mail.ne1.yahoo.com by 
sonic311.consmr.mail.ne1.yahoo.com with HTTP; Wed, 5 Mar 2025 19:22:25 +0000
  Received: by hermes--production-ne1-8446b9c656-q64nj (Yahoo Inc. Hermes SMTP 
Server) with ESMTPA ID ......;
            Wed, 05 Mar 2025 19:22:23 +0000 (UTC)

Authentication result headers become obsolete with DKIMACDC, too,
except for SPF results.  (Over time only, as software gets updated
only, and people declare their willingness to use that extension
by creating a DNS record, of course.  Other than that most DKIM
software supports removal of headers, the MUA i maintain also can
remove configured headers upon "save" time, like Envelope-To etc.)

If only original DKIM design would have been a bit more careful.
Time to fix it.

Happy day back and forth .. very nice!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org

Reply via email to