On Fri, 24 May 2024, Jon Callas wrote:
blank lines.) Maybe you can tell it's from a list and the crud is
benign, or maybe you can't and you should treat it as suspicious.
And yet, I didn't make up the word robustness, it's there in the spec as Dave
quoted.
When I read the whole paragraph,
According to Scott Kitterman :
Honestly, I think l= is an idea whose time has passed (if it ever existed at
all). We ought to just kill it using the simplest
procedural mechanism available.
We can do an update to deprecate l= but I think that if we just adjusted
our validation software to
On Thu, 23 May 2024, Philip Guenther wrote:
I said "this current round of visibility", a statement which implies
_previous_ rounds of visibility of a NOT NEW thing.
Sorry, I don't understand what you think is invisible here.
I think it could be useful to leverage the current round of
On Thu, 23 May 2024, Philip Guenther wrote:
** or don't over-sign and clients use the first found...
I would prefer not to go there. A message with two Content-Type headers
or two Subject headers or Date or Message-ID and so forth is not a valid
message, and a DKIM signer or validator should
On Thu, 23 May 2024, Philip Guenther wrote:
There's a related, though much less general, attack that works even if you
don't use the l= tag: on a message which has nested multiparts, there are
multiple potential delimiters that will look legit to a MIME parser, so if
you don't sign
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
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, 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
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
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 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
Manfred said:
(Seems like "seal"ing would be a better term than "oversign"ing.)
We've called it oversigning for a decade now.
R's,
John
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
Future proofing? The history of encryption is riddled with examples of
overconfidence.
Well, sure, and I would not be opposed to revisiting this issue in a
decade.
As Scott noted, approximately nobody handles ed25519 yet, and nobody will
until there is some reason to believe that RSA
13 matches
Mail list logo
