On Fri, Nov 4, 2022 at 4:18 AM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Maybe the problem is that John has trademarked "weak" to mean "L=0", so I
> will use "poorly constructed". DKIM "works" because malicious actors have
> found easier ways to attack than using an
It appears that Douglas Foster said:
>-=-=-=-=-=-
>
>Maybe the problem is that John has trademarked "weak" to mean "L=0", so I
>will use "poorly constructed". ...
Sorry, no. Once again, you appear to have completely misunderstood my
old double signing proposal.
Nobody uses weak signatures,
It appears that Neil Anuskiewicz said:
>
>> On Oct 30, 2022, at 11:09 AM, Scott Kitterman wrote:
>>
>> I believe it would go in a separate applicability statement if it were
>> going to be in an IETF document.
>>
>> Scott K
>
>I think the ideas discussed around this topic shouldn’t be
> On Oct 30, 2022, at 11:09 AM, Scott Kitterman wrote:
>
> I believe it would go in a separate applicability statement if it were going
> to be in an IETF document.
>
> Scott K
I think the ideas discussed around this topic shouldn’t be forgotten. But I’m
seeing that going down this rabbit
I believe it would go in a separate applicability statement if it were going to
be in an IETF document.
Scott K
On October 30, 2022 5:54:20 PM UTC, Douglas Foster
wrote:
>Where does the operational guidance go? A simple review of actual
>messages demonstrates that there is a need for
Where does the operational guidance go? A simple review of actual
messages demonstrates that there is a need for guidance. It would seem to
me that a sentence or two, elucidating principles and providing guidance
(not mandate), would solve the problem now.
If we leave it to each
On October 29, 2022 5:30:07 AM UTC, Neil Anuskiewicz
wrote:
>
>
>> On Oct 27, 2022, at 10:46 PM, Murray S. Kucherawy
>> wrote:
>>
>>
>>> On Thu, Oct 27, 2022 at 4:16 PM Douglas Foster
>>> wrote:
>>
>>> Murray raised the issue of a signature which produces PASS, but lacks trust
>>>
On Sat 29/Oct/2022 14:24:15 +0200 Douglas Foster wrote:
[...]
1) These fields are used with some frequency in observed signatures, but I
withhold judgement as I am not fluent in MIME.
mime-version content-type content-transfer-encoding;
These are MTA's responsibility. Protecting them
> On Oct 29, 2022, at 10:35 AM, Dotzero wrote:
>
> On Sat, Oct 29, 2022 at 1:30 AM Neil Anuskiewicz wrote:
>
>
>>
>> DMARC’s job is to flat out prevent unauthorized spoofing. It’s not a
>> stretch to imagine some higher signature standard without feeling like
>> you’re on DKIM’s turf.
>
On Sat, Oct 29, 2022 at 1:30 AM Neil Anuskiewicz
wrote:
>
> DMARC’s job is to flat out prevent unauthorized spoofing. It’s not a
> stretch to imagine some higher signature standard without feeling like
> you’re on DKIM’s turf.
>
The above statement is so incorrect. DMARC's "job" is to
This is to document some research related to this issue:
IANA Registry
---
After reviewing the IANA registry, these headers appear to be appropriate
only for a message originator, and are therefore candidates for inclusion
in an originator's DKIM signature:
Accept-Language Bcc
> On Oct 27, 2022, at 10:46 PM, Murray S. Kucherawy wrote:
>
>
>> On Thu, Oct 27, 2022 at 4:16 PM Douglas Foster
>> wrote:
>
>> Murray raised the issue of a signature which produces PASS, but lacks trust
>> because it is constructed with weak coverage, such as omitting the Subject
>> or
> On Oct 27, 2022, at 4:16 PM, Douglas Foster
> wrote:
>
>
> Murray raised the issue of a signature which produces PASS, but lacks trust
> because it is constructed with weak coverage, such as omitting the Subject or
> including an L=valuie clause.
>
> DKIM was designed to be flexible so
On Thu, Oct 27, 2022 at 4:16 PM Douglas Foster <
dougfoster.emailstanda...@gmail.com> wrote:
> Murray raised the issue of a signature which produces PASS, but lacks
> trust because it is constructed with weak coverage, such as omitting the
> Subject or including an L=valuie clause.
>
> DKIM was
> On Oct 27, 2022, at 4:16 PM, Douglas Foster
> wrote:
>
>
> Murray raised the issue of a signature which produces PASS, but lacks trust
> because it is constructed with weak coverage, such as omitting the Subject or
> including an L=valuie clause.
>
> DKIM was designed to be flexible so
Murray raised the issue of a signature which produces PASS, but lacks trust
because it is constructed with weak coverage, such as omitting the Subject
or including an L=valuie clause.
DKIM was designed to be flexible so that it could be used for many
purposes. DMARC is a specific purpose and
16 matches
Mail list logo
