Pete Resnick wrote in <[email protected]>: |On 30 Sep 2026, at 14:05, Bron Gondwana wrote: |> On Wed, Sep 30, 2026, at 11:58, Steffen Nurpmeso wrote: |>> Today an OpenSSL announcement, which has a 77198 bytes HTML part. |>> If that is reposted through a mailing-list which cuts HTML parts, |>> only leaving text, |> |> Those mailing lists should stop doing that. As part of upgrading to |> DKIM2 they can also upgrade to not arbitrarily dropping parts of the |> original message, whether that's HTML parts or attachments. It's not |> 1995 any more, and they don't need to "save bandwidth" by excessively |> tampering the incoming message. | |I think Mauro's request was more general than the mailing list case: |What we don't want is software (mailing list or otherwise) taking "the |message that came in" and blindly comparing it to "the message that is |going out after modification" and forming an instance header from that. |Putting a cap on header size is one way to make it clear to such |middleware that it is about to do a bad thing. Whether that's the way we |want to put it in the BCP is up to the WG.
That not me and DKIM/ACDC. In that i cannot believe in this in practice, for certain attachments, whatever. So your way would, i would think, effectively end-up with always "T" (not even "t") flags raised, talking ACDC (ie, hard removal of differential data to break the cryptographical path to elder message states). Just imagine certain MIME parts which trigger content filters, then you end up in a situation where a helpless user sends a network traffic dump that includes "attack data", you will no longer be able to communicate (the info, verifiably) at all, unless the parties switch to encrypted content via PGP or S/MIME. That does not sound useful. For DKIM/ACDC i now did + </t><t> + To avoid excessing MTA specific size limits, + each DKIX-DC: header field shall not be larger than 32768 bytes + (8-bit octets, 0x8000 hexadecimal), + counting field name, folding whitespace and line terminators. + If this limit would be exceeded, multiple DKIX-DC: header fields + shall be generated, with any follow-up DKIX-DC: header field consisting + of only continuation data of the overflowed first, storing as much data + as possible within each, until no more patch data remains. + The optional "s=" tag and the "f=" tag shall be placed in the first + header field. + An example covering maybe 100000 bytes of patch data could be: + </t><sourcecode><![CDATA[ +DKIX-DC: w=3; f=base64; h=base64... +DKIX-DC: ...; b=base64... +DKIX-DC: ... +DKIX-DC: ... + ]]></sourcecode> I also dropped the DNS record in favour of a simple CNAME, weeks ago (so no credit for Richard Clayton due). And a bit more regarding email hygiene (through the header field database), and i will reintroduce the -resend- "block"s there, enforcing mitigations when used. They are currently broken, effectively, due to DMARC, right. But that is not complete yet. Maybe even dropping the sequence number, the email header stack is the email header stack is the email header stack, so it really seems overengineered. --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 -- [email protected] To unsubscribe send an email to [email protected]
