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 B

[Ietf-dkim] DKIM-FBL

2023-09-27 Thread Brotman, Alex
Hey folks, I'm not entirely sure this is the right place for this. Someone else suggested the DMARC list, and I thought perhaps the "smtp" list might make more sense. If I'm shuffled off to one of those lists, I'll let this thread know. I've attached a draft that uses attributes of a passing

Re: [Ietf-dkim] DKIM-FBL

2023-09-27 Thread Brotman, Alex
ssage- > From: Ietf-dkim On Behalf Of Alessandro Vesely > Sent: Wednesday, September 27, 2023 10:07 AM > To: ietf-dkim@ietf.org > Subject: Re: [Ietf-dkim] DKIM-FBL > > On 9/27/23 13:36, Brotman, Alex wrote: > > I've attached a draft that uses attributes of a passing

Re: [Ietf-dkim] DKIM-FBL

2023-09-28 Thread Brotman, Alex
amp; Messaging Policy Comcast > -Original Message- > From: Dave Crocker > Sent: Thursday, September 28, 2023 1:05 PM > To: Brotman, Alex > Cc: ietf-dkim@ietf.org > Subject: Re: [Ietf-dkim] DKIM-FBL > > On 9/27/2023 7:41 PM, Murray S. Kucherawy wrote: > > We don

[Ietf-dkim] Re: PROPOSAL: reopen this working group and work on DKIM2

2024-11-07 Thread Brotman, Alex
The motivations have been stated, and I think most folks agree with them. It feels like the proposed features should be easily adoptable by a majority of participants in the ecosystem. Looks to be a good way forward, and an improvement for parties involved. -- Alex Brotman Sr. Engineer, Anti-A

[Ietf-dkim] Re: [EXTERNAL] Re: Re: The "back scatter" problem

2025-01-27 Thread Brotman, Alex
, January 27, 2025 1:59 PM > To: Brotman, Alex ; ietf-dkim@ietf.org > Subject: [EXTERNAL] Re: [Ietf-dkim] Re: The "back scatter" problem > > > On 1/27/25 8:22 AM, Brotman, Alex wrote: > > "The way they use DKIM" is still a bit vague. What context are you &

[Ietf-dkim] Re: The "back scatter" problem

2025-01-27 Thread Brotman, Alex
"The way they use DKIM" is still a bit vague. What context are you referring to here? What would be an appropriate venue for those discussions that you find acceptable? This list doesn't quite seem appropriate either. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast >

[Ietf-dkim] Re: Charter v5 available

2025-01-28 Thread Brotman, Alex
Without delving into technical discussion, this gives us a good framework to start with. -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast From: Murray S. Kucherawy Sent: Tuesday, January 28, 2025 10:30 AM To: ietf-dkim@ietf.org Subject: [Ietf-dkim] Charter v5 available I've

[Ietf-dkim] Re: ELI5: DKIM2 and DMARC

2025-03-21 Thread Brotman, Alex
If a message appears at my doorstep with: 5321.From: t...@herr.net 5322.From: toddh...@isp.net DKIM2 d=: intermediary.net And the DKIM2 fails, then what should I do? Reject it back to the (malicious?) sending host, who has no relationship to any of

[Ietf-dkim] Re: On the rationale for a new protocol (from the meeting)

2025-03-31 Thread Brotman, Alex
Also, we'll get them to switch to ed25519 at the same time. I have a hard time believing that all the libraries focusing on DKIMv1 will go back and create some code to handle this case. It's better to create a proper delineation. If the header string doesn't match, we don't have to worry about