[Ietf-dkim] Re: Review Response #7: Header Fields

2025-04-13 Thread Richard Clayton
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Dave Crocker writes >> It also reduces the size of every (cautious) email by 383 bytes (766 if >> the oversigning is not default) ... and there's a carbon footprint issue >> here that we should not ignore without careful consideration >

[Ietf-dkim] Re: Review Response #7: Header Fields

2025-04-13 Thread Jim Fenton
On 11 Apr 2025, at 13:00, Richard Clayton wrote: > The list of header fields is currently > > Author > Bcc Bcc header field? Doesn’t that contradict the “blank” carbon copy? > It also reduces the size of every (cautious) email by 383 bytes (766 if > the oversigning is not default

[Ietf-dkim] Re: Review Response #7: Header Fields

2025-04-13 Thread Dave Crocker
On 4/13/2025 6:34 PM, Richard Clayton wrote: An average email received at $DAYJOB$ on Friday (UTC) to be placed into the inbox was 81555 characters long; if it was automatically determined to be "span" it was 28921 bytes long. So, at the low end, less than 1/2 of 1%. And what will the increme

[Ietf-dkim] Re: Review Response #7: Header Fields

2025-04-13 Thread John Levine
It appears that Richard Clayton said: >>We made a similar optimization when designing DKIM not to include the public >>key >>in the signature and publish a digest of it in the DNS. This turned out to be >>the wrong thing when public key sizes had to increase and the DNS couldn’t >>easily acco

[Ietf-dkim] Re: Review Response #7: Header Fields

2025-04-13 Thread Richard Clayton
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In message , Jim Fenton writes >On 11 Apr 2025, at 13:00, Richard Clayton wrote: > >> The list of header fields is currently >> >> Author >> Bcc > >Bcc header field? Doesn’t that contradict the “blank” carbon copy? I suggest you read