On Thu, Feb 1, 2024 at 10:03 AM John Levine wrote:
> It appears that Murray S. Kucherawy said:
> >-=-=-=-=-=-
> >
> >On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso
> wrote:
> >
> >> But i cannot read this from RFC 6376.
> >
> >Sections 2.8 and 3.4.4 don't answer this?
>
> Not really. They
It appears that Dave Crocker said:
>The prohibition is not in DKIM. So the violation is not within DKIM.
>And why should DKIM care?
RFC 6376 says what to do with 5322 messages. It says nothing about
what to do with blobs of bytes that are sort of like but not quite
5322 messages. It even has
On 2/1/2024 7:31 PM, John R Levine wrote:
Layering is a fine principle, but it's not how DKIM has ever worked
in practice. Two weeks ago we had a long discussion about
oversigning, so DKIM validators can catch messages with multiple
From: or Subject: headers which have never been valid in any
Layering is a fine principle, but it's not how DKIM has ever worked in
practice. Two weeks ago we had a long discussion about oversigning, so
DKIM validators can catch messages with multiple From: or Subject: headers
which have never been valid in any version of 822/2822/5322 but show up
On 2/1/2024 7:05 PM, John R Levine wrote:
Layering is a fine principle, but it's not how DKIM has ever worked in
practice. Two weeks ago we had a long discussion about oversigning,
so DKIM validators can catch messages with multiple From: or Subject:
headers which have never been valid in any
On Thu, 1 Feb 2024, Dave Crocker wrote:
Me, I would*not* put in code looking for bare CRs or LFs. ...
A 5322 processor gets to decide what is a valid message. That's not DKIM's
job. And DKIM has no inherent reason to care about CR or LF on their own, as
distinct from any other character on
John Levine wrote in
<20240201180340.852b68205...@ary.qy>:
|It appears that Murray S. Kucherawy said:
|>-=-=-=-=-=-
|>
|>On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso \
|>wrote:
|>
|>> But i cannot read this from RFC 6376.
|>
|>Sections 2.8 and 3.4.4 don't answer this?
|
|Not
On 2/1/2024 12:28 PM, Jon Callas wrote:
So that gets to the tacit question -- what should a DKIM implementor do? Me, I
would*not*
put in code looking for bare CRs or LFs. My major rationale is an
appeal to layering, or bluntly, it's not my job to enforce RFC 5322
syntax. Someone else in the
On Feb 1, 2024, at 10:03, John Levine wrote:
It appears that Murray S. Kucherawy said:
-=-=-=-=-=-
On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso wrote:
But i cannot read this from RFC 6376.
Sections 2.8 and 3.4.4 don't answer this?
Not really. They say what to do with CRLF but not
It appears that Murray S. Kucherawy said:
>-=-=-=-=-=-
>
>On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso wrote:
>
>> But i cannot read this from RFC 6376.
>
>Sections 2.8 and 3.4.4 don't answer this?
Not really. They say what to do with CRLF but not with a lone CR or lone LF.
RFC5322 says:
Murray S. Kucherawy wrote in
:
|On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso \
|wrote:
|
|> But i cannot read this from RFC 6376.
|>
|
|Sections 2.8 and 3.4.4 don't answer this?
These were why i was coming here.
It is one thing to write a 5322/I-M-F parser who documents RFC
5234,
On Wed, Jan 31, 2024 at 5:44 PM Steffen Nurpmeso wrote:
> But i cannot read this from RFC 6376.
>
Sections 2.8 and 3.4.4 don't answer this?
-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
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 effects on signature robustness. A better
13 matches
Mail list logo
