Steffen Nurpmeso wrote in
<20240306205414.sCe1DCRy@steffen%sdaoden.eu>:
|Please allow me an addendum.
It is too funny to get this non-delivery back:
: host mx1.taugh.com[64.57.183.56] said: 554 5.6.0 Bare CR or
LF not accepted. (in reply to end of DATA command)
Have a nice evening!
Please allow me an addendum.
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
On 2/5/2024 4:57 PM, Murray S. Kucherawy wrote:
Interesting. Is that online anywhere?
You mean, as in a recording? This was the early 1970s... So, no.
This seems to be related to the topic:
https://scholar.archive.org/work/k2udwjcwqndofj6mw3fnn5jiky
d/
--
Dave Crocker
Brandenburg
On Mon, Feb 5, 2024 at 8:50 AM Dave Crocker wrote:
> OpenDKIM will not sign a message that fails basic RFC5322 header checks
> (e.g., "From" or "Date" is missing), but will place an
> Authentication-Results field indicating the message is malformed. At some
> point, though, someone talked me
On 2/5/2024 11:50 AM, Dave Crocker wrote:
(*) Lon ago, Knuth visited UCLA when I was there, and 'structured
programming' was a hot topic. He did a presentation to test a
perspective that he later wrote up. He observed that fully
structured programs, without gotos, could sometimes make code
On 2/3/2024 1:13 PM, Murray S. Kucherawy wrote:
I generally agree with the idea that there's a layering problem here,
i.e., that a DKIM filter should be able to safely presume that its
input will comply with RFC5322 and not alter the message at all other
than adding the signature. But on
On 2/3/2024 1:54 PM, John R Levine wrote:
It occurs to me that Dave and I have different views of how software
is put together.
John, Thanks for the effort at saying I'm out of date. Very subtle.
But you've been diligently missing the distinction I've made between
software architecture
John R Levine wrote in
<7ef08541-e3cf-d356-cba9-85a92a5df...@taugh.com>:
|> But on review, it seems like I've tiptoed over that line from
|> time to time in support of robustness in some form or another. ...
|
|It occurs to me that Dave and I have different views of how software is
|put
Unix MTAs strip out the CR in CRLF, often on the way in, so by the time
opendkim sees the message, the line endings are just LF.
That might be true when it's handing a message to an LDA, but it's not true
for SMTP ingress filters. For milter, CRs are preserved in the body, so
opendkim sees
On Sat, Feb 3, 2024 at 1:54 PM John R Levine wrote:
>
> > It also optionally does LF to CRLF translation. I'm fairly certain this
> is
> > to accommodate local/human SMTP injections since humans can't be expected
> > to type CRLFs when entering manual tests from a shell. ...
>
> Unix MTAs strip
Dave Crocker wrote in
<117c5879-7255-43cb-bfee-2ca9413be...@dcrocker.net>:
|On 2/3/2024 11:29 AM, Dave Crocker wrote:
|> DKIM is not a general message parsing engine
|
|btw, one might imagine a parsing engine that mixes a number of
|functions, such as general message parsing AND DKIM
But on review, it seems like I've tiptoed over that line from
time to time in support of robustness in some form or another. ...
It occurs to me that Dave and I have different views of how software is
put together. His sounds like the waterfall model that was popular when
he and I were
On Sat, Feb 3, 2024 at 5:40 AM Dave Crocker wrote:
> Having a DKIM module check for one aspect of RFC5322 conformance -- raises
> a need to make it a full RFC5322 compliance engine.
>
> If it doesn't, then the attention to compliance is a random walk through
> whatever concerns are fashionable
On 2/3/2024 12:11 PM, John Levine wrote:
It appears that Dave Crocker said:
Any DKIM signer or verifier already has a state machine looking for CR
and LF to do header or body canonicalization. When the state machine
runs into a bare CR or LF, it has to do something. The only options
are to
It appears that Dave Crocker said:
>> Any DKIM signer or verifier already has a state machine looking for CR
>> and LF to do header or body canonicalization. When the state machine
>> runs into a bare CR or LF, it has to do something. The only options
>> are to produce a wrong result, since
On 2/3/2024 11:29 AM, Dave Crocker wrote:
DKIM is not a general message parsing engine
btw, one might imagine a parsing engine that mixes a number of
functions, such as general message parsing AND DKIM validation.
For such an engine, where a bare CR or bare LF might be illegal --
though it
On 2/3/2024 10:32 AM, John R Levine wrote:
On Sat, 3 Feb 2024, Dave Crocker wrote:
Having a DKIM module check for one aspect of RFC5322 conformance
raises a need to make it a full RFC5322 compliance engine.
That's easy: no, it doesn't.
Any DKIM signer or verifier already has a state machine
On Sat, 3 Feb 2024, Dave Crocker wrote:
Having a DKIM module check for one aspect of RFC5322 conformance raises a
need to make it a full RFC5322 compliance engine.
That's easy: no, it doesn't.
Any DKIM signer or verifier already has a state machine looking for CR and
LF to do header or body
On 2/1/2024 8:34 PM, John Levine wrote:
I can see that you have strong opinions about what a DKIM verifier
should do with those non-5322 blobs, but I don't see what the basis
for that is, and for that matter, I don't really understand what you
expect code to do with them. Why is "stop and
On 2/1/2024 8:34 PM, John Levine wrote:
I can see that you have strong opinions about what a DKIM verifier
should do with those non-5322 blobs, but I don't see what the basis
for that is, and for that matter, I don't really understand what you
expect code to do with them. Why is "stop and
I agree that by the time you're talking to a DKIM (or any) filter, I expect
that this has been handled somehow. 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.
Yup, which is why I'd prefer to take out the
On 2/2/2024 12:03 AM, Murray S. Kucherawy wrote:
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.
>
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
Hello.
Is there any advise on a "lone CR" or "lone LF" on a line? Do
these count as "whitespace characters"? Well they surely do not
as whitespace is SP / HTAB. But what if i see
SP CR CRLF
or
LF CRLF
or
LF au CRLF
when i create a digest?
For now i assume anything such except the very
35 matches
Mail list logo
