[Ietf-dkim] Re: DKIM with body length
On 20/05/2024 09:06, Alessandro Vesely wrote: Content-Type: is a technical field Not a term I've met before. Is there a formal definition? And as far as "which forwarders need to change" goes - isn't the entire point of DKIM to detect chages? -- Cheers, Jeremy ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
[Ietf-dkim] Re: DKIM with body length
On 19/05/2024 17:26, Wei Chuang wrote: then rewrite the Content-type header mime delimitter Seems like including this header in the signed set would be Best Practice? -- Cheers, Jeremy ___ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
Re: [Ietf-dkim] Fwd: Re: [..] Recommendation for dkim signing
On 06/03/2024 23:30, Steffen Nurpmeso wrote: Does this mean you do use Ed25519 and RSA since over four years in regular email? It*brakes things*!? Yes. And no, not that I've noticed. -- Cheers, Jeremy ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Fwd: Re: [..] Recommendation for dkim signing
On 06/03/2024 22:41, Steffen Nurpmeso wrote: exam i do not know exim, possibly? -- Cheers, Jeremy ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Signature
On 27/10/2023 15:56, Murray S. Kucherawy wrote: Which DKIM implementations are known to be willing to support this if it were added? If I saw interest, I'd be willing to add it to Exim. -- Cheers, Jeremy ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On 09/08/2023 21:12, Murray S. Kucherawy wrote: It seems to me that adding a per-recipient DKIM "sub-signature" can be accomplished very cheaply, and "scales to super-parallelism". If by that you mean a distinct signing key per user, I don't think this scales. If you signed per-recipient a new 5321 option on the RCPT command, using the sending domain key, but mixing the 5321 recipient into the sig? Yes, it's more signing to do, so more work for the sending MTA. But no scaling issue for keys. I guess you'd still want the trad DKIM sig in the headers for back-compat. Possibly add a marker to that to say the new method was also used, so that new-aware receiving MTAs don't accept it for replay. (Yes, it doesn't survive a further indirect mailflow step) -- Cheers, Jeremy ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On 09/08/2023 15:55, Murray S. Kucherawy wrote: because it allows for better tracking and association of bounces This. -- Cheers, Jeremy ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Call for adoption results: draft-ietf-dkim-replay-problem Adopted
On 07/08/2023 05:22, Jesse Thompson wrote: For messages which are originally submitted as BCC and, depending on the circumstances, it's necessary for us to identify the recipient in the headers, what is/should be the standard header to use for this purpose? BCC? Forwarded-to? There is no such header. That's the whole point of a bcc; it's Blind. If there was one it would have to be a separate message to the one it is a copy of. -- Cheers, Jeremy ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] DKIM Replay Problem Statement and Scenarios -01 draft posted
On 16/02/2023 23:17, Dave Crocker wrote: On 2/16/2023 2:04 PM, Evan Burke wrote: 1hr is at the very low end of the scale, only appropriate in narrow, specific circumstances. I think you're right that 2+ days is the right range for most mail. The historical common choice, for when to stop retrying mail delivery, has been 3 days. This was a matter of discussion some years ago and as I recall, was a comfortable choice. And we got a note observing that replay attack can reasonably begin within minutes of original posting. This produces a choice for setting a timeout that is wholly ineffective or one that destroys retries of leigimate mail delivery attempts. Does that not assume that the point where a message is held during delay is after the point of signing? -- Cheers, Jeremy ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)
On 26/11/2022 23:20, Barry Leiba wrote: I will say that the use case that is broken by removing the signature is the "re-send" case There was another use-case already noted: where the MUA verifies the DKIM for the purpose of display to the user. Example: the "DKIM Verifier" add-on for Thunderbird. -- Cheers, Jeremy ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
