I know that I've written about this before, so please bear with me a bit. A
continuing concern of mine is the way that DKIM contributes to overall
surveillance smog that the Internet has.
When we designed DKIM, this was something we considered; it was a concern. It
wasn't so big a concern that
> On Aug 6, 2020, at 3:42 PM, Shana Bagherian
> wrote:
>
> I was looking over rfc 4871 and emailed Eric who suggested I ask the question
> of you all on this DL. So, I was wondering if any of the RCSs related to
> DKIM list a best practice, or if some other authority has given a best
> pra
> On Nov 21, 2022, at 14:01, Dave Crocker wrote:
>
> On 11/21/2022 1:56 PM, Murray S. Kucherawy wrote:
>> I don't want to get into implementation discussions before we even have a
>> charter, but I'm curious about how this could be made effective.
>
> I'd count it as a simple tool that might
> On Dec 3, 2022, at 11:01, Stephen Farrell wrote:
>
> One nit though, that you should feel free to ignore if it
> was discussed already - the phrase "in a secure way" doesn't
> quite capture what the DKIM WG was trying to produce, e.g.
> we consider unsigned DNS fine for DKIM public keys, eve
> On Dec 3, 2022, at 11:42, Dave Crocker wrote:
>
> On 12/3/2022 11:35 AM, Jon Callas wrote:
>> Agreed, and we need some other weasel word than "lightweight" because there
>> are lots of people working on "lightweight" symmetric ciphers. Something
> On Dec 6, 2022, at 14:23, Michael Thomas wrote:
>
>
> On 12/6/22 2:05 PM, mikespec...@gmail.com wrote:
>> I very much disagree with everything the above poster said.
>>
>> Deniability is a default property of all e2ee messaging apps; it’s both
>> surprising and disheartening that email — a
> On Aug 13, 2023, at 20:31, Jesse Thompson wrote:
>
> If I understand based on my limited view of history, DKIM was designed for
> authentication between two hops. Signature survival across intermediaries was
> only achievable by encouraging intermediaries to not make any changes to the
> m
> On Aug 16, 2023, at 10:25, Alessandro Vesely wrote:
>
> To repeat my questions, then, would limiting (qualified) DKIM signatures to
> verified accounts diminish replay attacks by any amount? Is this kind of
> solution acceptable?
There's two reasons that this isn't acceptable. One is tha
> On Aug 16, 2023, at 11:21, Jim Fenton wrote:
>
> On 16 Aug 2023, at 10:57, Jon Callas wrote:
>
>>> On Aug 16, 2023, at 10:25, Alessandro Vesely wrote:
>>>
>>> To repeat my questions, then, would limiting (qualified) DKIM signatures to
>>>
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 wi
I feel like I ought to comment. I've always had mixed emotions about l=, and I
also agree with some of the things John Levine said.
When we first talked about l=, I thought it was kinda silly. What brought me
around to it was a comment someone made that the receiver of a message with l=
ought t
> Jon,
>
> Sorry to be finicky, but I don't recall any statement in the DKIM
> specification that matches or approximate that semantic for any aspect of
> DKIM, never mind l=.
>
> As for l= semantics, this is all of the relevant text, none of which is
> nearly as interesting as the interpretat
> On May 24, 2024, at 19:55, John Levine wrote:
>
> It appears that Jon Callas said:
>> And look at it -- l= is intended to increase robustness and strictness of
>> interpreting the message.
>
> I don't see how that followes. In all the years I've b
I was thinking about this, and have come around to the other side -- if the
real-world problem is that people are doing a feature wrong, pulling it is a
completely reasonable response. That it could be a good idea, if only it were
implemented right doesn't matter. The reality is that it's wrong
> On May 25, 2024, at 09:49, John R Levine wrote:
>
> 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.
>>
>> An
15 matches
Mail list logo
