[Ietf-dkim] Test Msg to ietf-dk...@ietf.org

Ignore -- HLS ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

e: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1537415189; bh=TJWGUVdPL8OTY+HJnUzpBRd52OaKfWjFqS68Cby0s/M=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From; b=..... X-Original-From: Hector

Re: [Ietf-dkim] DKIM-Signature: r=y and MLM

On 10/24/2018 4:53 PM, Дилян Палаузов wrote: PS: Please describe the handling, of the above message by the MLM, if the original message contained in addition DKIM-Signature: v=1; d=isdg.net; r=y; … ... or something different than r=y, that permits finding faulty DKIM implementations. Our

Re: [Ietf-dkim] [dmarc-ietf] DKIM-Signature: r=y and MLM

On 10/24/2018 5:18 PM, Kurt Andersen wrote: On Mon, Oct 15, 2018 at 7:30 AM Hector Santos What it should do is: 1) It should use a 1st party signature using d=dmarc.ietf.org to match the new author domain dmarc.ietf.org 2) It should has hash bind the X

Re: [Ietf-dkim] Thinking About DKIM and Surveillance

Thanks jon for loading my plate! :) I plan to finish reading the paper later today. Need to recall past discussions and how the paper relates. But with initial reading, it made me recall the proposal I wrote in 2006: https://tools.ietf.org/html/draft-santos-dkim-rcvd-00 related to

Re: [Ietf-dkim] Adding an aim= tag to DKIM Signature Tag Specifications

We need to update DMARC or any other DKIM Policy proposal to seriously consider 3rd party signature Authorization methods. We have wasted so much time avoiding it. Sure, it may not apply to all, but neither does DMARC and the push to embed a "half-baked" DMARC into our mail network has

Re: [Ietf-dkim] Remove the signature! (was: Re: DKIM reply mitigations: re-opening the DKIM working group)

> On Nov 20, 2022, at 6:01 PM, Murray S. Kucherawy wrote: > > > > On Sun, Nov 20, 2022, 11:08 Dave Crocker > wrote: >> Seriously. DKIM is intended as a transit-time mechanism. When delivery >> occurs, transit is done. So DKIM has done its job and can (safely?)

Re: [Ietf-dkim] DKIM reply mitigations: re-opening the DKIM working group

> On Nov 11, 2022, at 11:46 AM, Barry Leiba wrote: > > Indeed... > The issue here is this: > > 1. I get a (free) account on free-email.com. Ok > 2. I send myself email from my account to my account. Of course, > free-email signs it, because it's sent from me to me: why would it > not?

Re: [Ietf-dkim] Welcome to the rechartered working group

model do not have this problem. But, via POLICY if the domain using reputation wishes a verifier to put more restrictions on a received signed domain, i.e. enforce `x=` expiration tag, I am all for it. Thanks Hector Santos CEO/CTO Santronics Software, Inc. > On Mar 7, 2023, at 7:09

Re: [Ietf-dkim] DKIM update - header tag

-1. The v= tag description is accurate. There is no current DKIM design expectation for any other string value. The current spec is `v=DKIM1`. Any software writing `v=DKIM1.0` is technically “broken” and should not be encourage to exist or perpetuate. IOW, software should not process the

Re: [Ietf-dkim] Comments on draft-chuang-dkim-replay-problem

+1. ARC is not a solution, but it is a good part of the problem. It’s not hard to see how our fall back to defocusing, the de-emphasis of the DKIM Policy Model in lieu of Reputation Modeling creating this issue. Every issue we have today is nearly 100% because of the lob-sided efforts to

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

> On Mar 26, 2023, at 6:13 AM, Murray S. Kucherawy wrote: > > On Sat, Mar 25, 2023 at 10:29 AM Michael Thomas > wrote: >> On 3/24/23 6:19 PM, Barry Leiba wrote: >> > I don't agree with the premise. I think what was tried and didn't >> > work should be documented in the

Re: [Ietf-dkim] What has been tried and doesn't work should be documented in the problem statement

> On Mar 26, 2023, at 1:11 PM, Michael Thomas wrote: > My contention is that documenting what has failed in the problem statement > saves time eventually in the solution space as you can reference it when > somebody brings it up as to why it doesn't work. It would be just a cut and > paste

Re: [Ietf-dkim] On the current state of DKIM and the replay problem

> On Mar 28, 2023, at 1:36 PM, Michael Thomas wrote: > > Since the chair is threatening to ban me, I decided to write up my view of > things in a longer form. > > https://rip-van-webble.blogspot.com/2023/03/on-dmarc-arc-and-dkim-replays.html > > This has some technical aspects and meta

Re: [Ietf-dkim] DMARC's auth=dkim+spf tag

> On Jul 3, 2023, at 10:06 AM, Barry Leiba wrote: > >> Anyway, discussing whether spf+dkim verification can mitigate DKIM replay >> belongs to the ietf-dkim list. (In case, it could also be expressed outside >> DMARC, for example by an additional DKIM tag.) > > I do agree with this, yes. >

Re: [Ietf-dkim] Security indicators, not Headers that should not be automatically oversigned

xpect-less-email-marketing-dd124c19 Google and Yahoo Are Cracking Down on Inbox Spam. Don’t Expect Less Email Marketing. wsj.com All the best, Hector Santos > On Feb 6, 2024, at 1:43 PM, John Levine wrote: > > It appears that Jim Fenton said: >> On 5 Feb 2024, at 14:02

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

is the best. Go with your GUTS. Always works in the long term. All the best, Hector Santos > On Feb 5, 2024, at 8:50 PM, Dave Crocker wrote: > Om > On 2/5/2024 2:08 PM, Jim Fenton wrote: >> On 5 Feb 2024, at 14:02, Dave Crocker wrote: >>> On 2/5/2024 1:56 PM, Jim Fenton wrote

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

ed for certain DKIM signing routes. What is most important is what it is suppose to help address - DKIM Replay hacks. All the best, Hector Santos ___ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim

Re: [Ietf-dkim] Question about lone CR / LF

omehow. CRLF ends a line, anything before that is part of the line, and WSP is just a space or a tab.  Past that, garbage in, garbage out. +1.   5322/5321 EOL is CRLF -- Hector Santos, https://santronics.com https://winserver.com ___ Ietf-dki

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

On 2/1/2024 6:38 AM, Alessandro Vesely wrote: On Wed 31/Jan/2024 18:34:46 +0100 Hector Santos wrote: If I add this feature to wcDKIM, it can be introduced as: [X] Enable DKIM Replay Protection That'd be deceptive, as DKIM replay in Dave's sense won't be blocked, while there can be other

Re: [Ietf-dkim] Question about lone CR / LF

recall an old corporate project SE coding guideline: usage of a GOTO LABEL was allowed if the LABEL is within the reader's page view, i.e. 25 lines (using 25x80 terminal standards). -- Hector Santos, https://santronics.com https://winserver.com

Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

> On Feb 3, 2024, at 8:23 AM, Alessandro Vesely wrote: > > On Fri 02/Feb/2024 14:34:22 +0100 Hector Santos wrote: >> Of course, the MUA is another issue. What read order should be expected for >> Oversign headers? Each MUA can be different although I would think

Re: [Ietf-dkim] Testing a DKIM implementation

would be appreciated. Thanks in advance for any assistance. There are number of verifiers.   One such address is dkim-autoresp...@isdg.net will verify your DKIM signatures and apply DKIM Policies such as ADSP (deprecated), DMARC and report the result. -- Hector Santos, https://santronics.com

[Ietf-dkim] Re: [Dcrup] [standards] [Editorial Errata Reported] RFC8463 (7930)

a high overhead of two signatures, The ignorant RFC8463 system (the majority) is not ready for this. One SHA256 signature is sufficient, I would not Ed25519 provides smaller keys that are more supportive by DNS Zone Managers. All the best, Hector Santos ___