Michael Thomas wrote in <64aaf30f-c5ca-42a3-8ee6-730d7d98e...@mtcc.com>: |On 3/5/25 3:12 PM, Steffen Nurpmeso wrote: |> Michael Thomas wrote in |> <1dbce124-0e1c-4f05-b827-60025684e...@mtcc.com>: |>|On 3/5/25 12:29 PM, Tobias Herkula wrote: |> ... |>|I've been reading the draft mentioned in the charter re: replay and |>|rcpt-to and don't understand why that changes anything wrt replay. If |>|there is a message that a spammer has discovered passes a recipient's |>|spam filter, what difference does it make if it's a single smtp |>|transaction or multiple transactions? |>| |>|If the idea is that it is somehow bound to the original rcpt-to, that |>|breaks a significant amount of use cases in the email architecture |>|(forwarding) so I sure hope it's not that. The draft does sort of imply |>|that a Bcc'd address will end up in the signature block, which |>|completely defeats the purpose of Bcc which sounds like a really \ |>|bad idea. |> |> Dear Michael Thomas, do you refer to the ACDC draft here?
|I don't know what the ACDC draft is. This at least explains it. It is a DKIMv1 extension. Practically, from the Silverlake side, but you said you live somewhere else. Ah, hm; you should read it. That would be nice. It surely is sad to talk for several years without getting a useful response, but then getting presented this cumulation of harmful ideas as a solution for the future, including SMTP interference, feedback bypasses, envelope content unhiding, heaps of additional headers, pseudo "user readable" content, covered header restrictions / fixations, and such. Anyhow i have nothing to retract, professionally. That must be said. Including the l= and z= tags already of DomainKeys, which was in 2006/7 and a newborn child. Almost twenty years ago. (ACDC obsoletes them.) Have a good night, greetings to America, --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
