Re: [Ietf-dkim] Usage of RFC 6651 for replay-mitigation interoperability reporting (was Re: What makes this posting different from the original posting?)

2023-09-22 Thread Alessandro Vesely
On Thu 21/Sep/2023 22:27:30 +0200 Brotman, Alex wrote: Including that data in a DMARC report may not be very useful if it's going to the domain holder instead of the DKIM signer. For example, SES signs all of their messages, but unless that 5322 owner shares the data, they wouldn't see any

Re: [Ietf-dkim] Usage of RFC 6651 for replay-mitigation interoperability reporting (was Re: What makes this posting different from the original posting?)

2023-09-21 Thread Brotman, Alex
Ale, Including that data in a DMARC report may not be very useful if it's going to the domain holder instead of the DKIM signer. For example, SES signs all of their messages, but unless that 5322 owner shares the data, they wouldn't see any information relating to those signatures. -- Alex

Re: [Ietf-dkim] Usage of RFC 6651 for replay-mitigation interoperability reporting (was Re: What makes this posting different from the original posting?)

2023-09-15 Thread Alessandro Vesely
On Sun 10/Sep/2023 18:44:00 +0200 Jesse Thompson wrote: On Fri, Sep 8, 2023, at 9:23 AM, Murray S. Kucherawy wrote: On Fri, Sep 8, 2023 at 7:17 AM Jesse Thompson wrote:__ Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in control of the signer, as opposed to the

[Ietf-dkim] Usage of RFC 6651 for replay-mitigation interoperability reporting (was Re: What makes this posting different from the original posting?)

2023-09-10 Thread Jesse Thompson
On Fri, Sep 8, 2023, at 9:23 AM, Murray S. Kucherawy wrote: > On Fri, Sep 8, 2023 at 7:17 AM Jesse Thompson wrote:__ Is rfc6651 a lost cause? It looks like it defines a reporting mechanism in control of the signer, as opposed to the attacker. >>> >>> Has anyone (else) implemented it?