Re: [mailop] ARC and not ARC, was Microsoft Announces Tenant Trusted ARC Seal
On 30/06/2022 01:04, John Levine via mailop wrote: It appears that Vsevolod Stakhov via mailop said: I agree that would've been better than ARC. However, it'd still need to know which recipients are mailing list supporting DKIMv2 and operate accordingly. ... Not necessarily. On a small system you could put fowarding signatures on all the mail you send and hope, probably correctly, that the people to whom your users send mail are unlikely to do malicious things with it. If we ignore unknown tags safely then this extension can be introduced without any additional issues with the compatibility I suppose. If your DKIM verifier doesn't ignore unknown tags, it's not going to work. People add random tags all the time. I agree that it is a bug, and I have already pushed a fix for this issue to the Rspamd sources tree. But I disagree that 'people add random tags all the time': this dkim implementation has been used in Rspamd for like 10 years, and I have not received a single complaint on a wrong behaviour due to an unknown tag (it led to a specific unique error that must have been noticed somehow). That's why I'm curious if there are any other implementations that refuse unknown tags. Furthermore, if you have by a chance any example of the correct DKIM signature but with a non-standard tag, then I'd really appreciate if you can somehow share it with me, as it will help me to write an integration test for this particular part of the DKIM verifier. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ARC and not ARC, was Microsoft Announces Tenant Trusted ARC Seal
It appears that Vsevolod Stakhov via mailop said: >> I agree that would've been better than ARC. However, it'd still need to >> know which recipients are mailing list supporting DKIMv2 and operate >> accordingly. ... Not necessarily. On a small system you could put fowarding signatures on all the mail you send and hope, probably correctly, that the people to whom your users send mail are unlikely to do malicious things with it. >If we ignore unknown tags safely then this extension can be introduced >without any additional issues with the compatibility I suppose. If your DKIM verifier doesn't ignore unknown tags, it's not going to work. People add random tags all the time. I presume you noticed that my draft changed the v= tag so that signatures that depend on forwarding a v=1,tag that is unknown to verifiers that don't implement the draft so they'll consider the signature invalid. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ARC and not ARC, was Microsoft Announces Tenant Trusted ARC Seal
On Tue 28/Jun/2022 15:33:01 +0200 Dave Crocker via mailop wrote: On 6/28/2022 3:32 AM, Alessandro Vesely via mailop wrote: I agree that would've been better than ARC. However, it'd still need to know which recipients are mailing list supporting DKIMv2 and operate accordingly. For example, on a reply-all the MSA should split the message and sign it regularly for regular recipients and conditionally for MLs. 1. What do you mean by DKIMv2? I seemed to recall that John's conditional-signatures required a version bump. Now I looked at the draft again and it doesn't mention v2. 2. What features of v2 are relevant here and where are they in the spec? The point, IIRC, was to set a mandatory tag, !fs=, which cannot be ignored. 3. How is an MSA to know, reliably and accurately, the difference between 'regular recipients' and MLs? Eh, that's a good question. Vsevolod suggests a Merkle tree. Any database would do, but databases don't seem to be part of the typical MTA tools. The other side of the question is how do they obtain the relevant data. Once I fantasized about a sort of extended opt-in protocol that involved the user's MX. MSAs having a per-user list of subscribed MLs would have several advantages, and the disadvantage of decreased user privacy. Perhaps the opposite is more workable, MLs having a per-subscriber list of MTA capabilities. That way they'd know which MTA trusts their ARC sealing and can skim From: munging. 4. What do you mean by 'conditional' signing? You certainly recall John's conditional signatures. DMARC WG talked a lot about them in 2014, before ARC. https://datatracker.ietf.org/doc/html/draft-levine-dkim-conditional Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ARC and not ARC, was Microsoft Announces Tenant Trusted ARC Seal
On 6/28/2022 3:32 AM, Alessandro Vesely via mailop wrote: I agree that would've been better than ARC. However, it'd still need to know which recipients are mailing list supporting DKIMv2 and operate accordingly. For example, on a reply-all the MSA should split the message and sign it regularly for regular recipients and conditionally for MLs. 1. What do you mean by DKIMv2? 2. What features of v2 are relevant here and where are they in the spec? 3. How is an MSA to know, reliably and accurately, the difference between 'regular recipients' and MLs? 4. What do you mean by 'conditional' signing? d/ ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ARC and not ARC, was Microsoft Announces Tenant Trusted ARC Seal
On 28/06/2022 11:32, Alessandro Vesely via mailop wrote: On Mon 27/Jun/2022 13:39:52 +0200 Vsevolod Stakhov via mailop wrote: On 25/06/2022 18:14, John Levine via mailop wrote: It appears that Vsevolod Stakhov via mailop said: I really, really miss one simple feature in ARC signatures. Whilst it is +/- trivial to have a list of trusted signers on a receiver side, it would be super helpful to allow **a sender** to specify it's next trusted hop. You mean liks this? https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ I proposed that in 2014, the ARC crowd didn't go for it. Yes, that's exactly what I have in my mind if thinking about how to `fix` dmarc for forwarding! And it doesn't introduce that bloated complexity that ARC does, allowing to restore authority by just following DKIM signatures. It is not a silver bullet as you still have a choice to trust or not for those forwarders but it is really a choice of a sender, like the whole DMARC policy. I agree that would've been better than ARC. However, it'd still need to know which recipients are mailing list supporting DKIMv2 and operate accordingly. For example, on a reply-all the MSA should split the message and sign it regularly for regular recipients and conditionally for MLs. Interesting, I have just found that the current DKIM RFC actually states that a verifier must *ignore* the unknown tags in the signature: https://datatracker.ietf.org/doc/html/rfc6376#section-3.2 However, my own implementation of DKIM verifier in Rspamd fails to comply with this requirement (I will fix it soon). I'm curious now how many of the existing DKIM implementations panic on an unknown tags in DKIM signatures. If we ignore unknown tags safely then this extension can be introduced without any additional issues with the compatibility I suppose. Albeit requirements differ, both ARC and dkim-conditional would need to exchange info between a mailing list and each subscriber's MTA in order to operate as intended. Perhaps an extended opt-in protocol...? Well, it is possible for an ML software to keep all signatures in a Merkle tree and store any additional information about the particular signature to share it with the interested receivers. However, it might be an overkill in general, I don't know. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ARC and not ARC, was Microsoft Announces Tenant Trusted ARC Seal
On Mon 27/Jun/2022 13:39:52 +0200 Vsevolod Stakhov via mailop wrote: On 25/06/2022 18:14, John Levine via mailop wrote: It appears that Vsevolod Stakhov via mailop said: I really, really miss one simple feature in ARC signatures. Whilst it is +/- trivial to have a list of trusted signers on a receiver side, it would be super helpful to allow **a sender** to specify it's next trusted hop. You mean liks this? https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ I proposed that in 2014, the ARC crowd didn't go for it. Yes, that's exactly what I have in my mind if thinking about how to `fix` dmarc for forwarding! And it doesn't introduce that bloated complexity that ARC does, allowing to restore authority by just following DKIM signatures. It is not a silver bullet as you still have a choice to trust or not for those forwarders but it is really a choice of a sender, like the whole DMARC policy. I agree that would've been better than ARC. However, it'd still need to know which recipients are mailing list supporting DKIMv2 and operate accordingly. For example, on a reply-all the MSA should split the message and sign it regularly for regular recipients and conditionally for MLs. Albeit requirements differ, both ARC and dkim-conditional would need to exchange info between a mailing list and each subscriber's MTA in order to operate as intended. Perhaps an extended opt-in protocol...? Best Ale -- ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ARC and not ARC, was Microsoft Announces Tenant Trusted ARC Seal
On 25/06/2022 18:14, John Levine via mailop wrote: It appears that Vsevolod Stakhov via mailop said: I really, really miss one simple feature in ARC signatures. Whilst it is +/- trivial to have a list of trusted signers on a receiver side, it would be super helpful to allow **a sender** to specify it's next trusted hop. You mean liks this? https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ I proposed that in 2014, the ARC crowd didn't go for it. Yes, that's exactly what I have in my mind if thinking about how to `fix` dmarc for forwarding! And it doesn't introduce that bloated complexity that ARC does, allowing to restore authority by just following DKIM signatures. It is not a silver bullet as you still have a choice to trust or not for those forwarders but it is really a choice of a sender, like the whole DMARC policy. As far as I observe, spammers now use DMARC more actively and properly than legit senders. So now we also need to check more signatures with ARC (which I personally hate, as RSA and even EdDSA are quite CPU intensive operations) and still have no way to allow a sender to specify a trusted forwarder. ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
Re: [mailop] ARC and not ARC, was Microsoft Announces Tenant Trusted ARC Seal
It appears that Vsevolod Stakhov via mailop said: >I really, really miss one simple feature in ARC signatures. Whilst it is >+/- trivial to have a list of trusted signers on a receiver side, it >would be super helpful to allow **a sender** to specify it's next >trusted hop. You mean liks this? https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ I proposed that in 2014, the ARC crowd didn't go for it. R's, John ___ mailop mailing list mailop@mailop.org https://list.mailop.org/listinfo/mailop
