On 8 Feb 2018, at 10:23, Dave Crocker wrote:
On 2/8/2018 10:05 AM, Pete Resnick wrote:
So, no error in 5322. As for the erratum below, not having ABNF for
the header field does seem like a miss, though I'm not sure it should
be marked as more than "Hold for document update".
Co
ensitive, specify the characters
individually.
RFC 7405 is also useful along these lines.
So, no error in 5322. As for the erratum below, not having ABNF for the
header field does seem like a miss, though I'm not sure it should be
marked as more than "Hold for document update".
pr
I want to try to be precise, which I don't think Charles is being with
his below two sets of facts. Let me try to clarify:
On 7/8/11 5:52 AM, Charles Lindsey wrote:
1. The fact that DKIM choose headers to sign from the bottom up (for good
reason) facilitates certain attacks (not against DKIM,
I am perfectly happy with Murray's original (and now, revised) text.
(Nits still being discussed are entirely up to the WG.) I am not happy
with Charles's text. Particularly:
On 7/7/11 5:08 AM, Charles Lindsey wrote:
Recall that, when multiple instances of a given header field are
On 6/29/11 11:11 AM, Barry Leiba wrote:
Pete:
I'll mostly let the editors reply to this, but there are a couple of
things I want to say first.
The first thing is that it's out of scope to address changes to things
that were in RFC 4871, which was approved by the working group, the
On 6/29/11 11:20 AM, Charles Lindsey wrote:
I agree that 8.14 is poorly written (and it was even worse a while back).
However, there most certainly IS an attack here, which is NOT the same as
the related attack discussed in 8.15, and cannot be prevented by putting
extra entries in the 'h='
Folks,
I've been reviewing 4871bis for the IESG review on Thursday. I've got a
huge number of comments. Some of them (e.g., the first two below) are
quite trivial or simple issues that I expect you'd either have no issue
with or that I'm happy to ignore; some of them are clearly not trivial
On 5/19/11 12:50 PM, Murray S. Kucherawy wrote:
Can anyone remember why there's a SHOULD for the downgrade to 7-bit in
RFC4871 Section 5.3, rather than a MUST? The likelihood of breakage
is so high when sending 8-bit data that DKIM almost becomes pointless
without the upgrade.
Not
On 5/19/11 6:09 PM, Michael Thomas wrote:
We send things that get forwarded through all kinds of manglers,
8bit manglers just being one variety. In the abstract, you can never know
as a signer that a path is clean... it can always be forwarded. So by your
argument it should be a MUST since you
On 5/19/11 6:52 PM, Hector Santos wrote:
SHOULD is an optional requirement - Its a recommendation for the
better, but things will not break things for your peers if you don't
follow it. You may be shamed but the person shaming you is the one
wrong if they depended on a SHOULD operation as a
On 5/10/11 8:45 PM, Barry Leiba wrote:
...this document might be suitable for Pete's Applicability Statement
experiment, at
the Proposed Standard level.
Leaving aside the question of whether or not this is a good idea...
I am of course pleased to see that Barry has interest in my
to
require (or REQUIRE) the Sender: field, that would be a bad thing.
But I haven't seen anything to that effect in what I've been reading.
I'll go back to lurking now, and the rest of you can go back to your
regularly scheduled love-fest.
pr
--
Pete Resnick http://www.qualcomm.com/~presnick
12 matches
Mail list logo
