I would like to propose a small change in semantics to the current
text in section 6.1, last sentence of 2nd paragraph:
Therefore, a verifier SHOULD NOT treat a message that has one or more
bad signatures and no good signatures differently from a message with
no signature at all.
Since the
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Murray S. Kucherawy
> Sent: Sunday, July 10, 2011 8:39 PM
> To: Charles Lindsey; DKIM
> Cc: Pete Resnick
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group r
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Charles Lindsey
> Sent: Sunday, July 10, 2011 6:00 AM
> To: DKIM
> Cc: Pete Resnick
> Subject: Re: [ietf-dkim] Final update to 4871bis for working group review
>
> Implemento
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Scott Kitterman
> Sent: Sunday, July 10, 2011 6:46 PM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Doublefrom language should be in ADSP, not core
>
> I think we s
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Michael Deutschmann
> Sent: Sunday, July 10, 2011 12:53 AM
> To: DKIM List
> Subject: Re: [ietf-dkim] Doublefrom language should be in ADSP, not core
>
> The attack only matt
On Saturday, July 09, 2011 07:19:17 PM Michael Deutschmann wrote:
> One additional thought on the whole double-From: argument -- if RFC
> language on the issue is justified at all, it really belongs in the
> ADSP RFC, not a core DKIM one.
>
> A double-From: doesn't even rise to the level of theore
Why not just keep it simple, less confusing, less challenging on
competing mind games, that DKIM can't not fully protect again unsigned
Author Addresses and its highly recommendation that DKIM signers,
verifiers and Mail Readers to kick out, reject, destroy, do not pass
on these sort of Invalid
On Fri, 08 Jul 2011 18:51:39 +0100, Pete Resnick
wrote:
> 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 botto
On Sun, 10 Jul 2011, Hector Santos wrote:
> Well, you have a point:
>
> DKIM has failed to address legacy spoofing problems.
That's not quite the point I intended to make.
I consider it faintly possible that a situation could arise where a lazy
validation module embedded in an MTA always chec
Well, you have a point:
DKIM has failed to address legacy spoofing problems.
The hope was this would be one of the highest and immediate benefits
when an domain raised the bar by what was expected in his mail and
supportive receivers saw deviations from the domain's published policy
expect
-1
---
Sent from my mobile phone
On Jul 10, 2011, at 3:58 AM, "Michael Deutschmann"
wrote:
> On Sun, 10 Jul 2011, Hector Santos wrote:
>> Now of course, if ADSP was a standard and whitehouse.com had an
>> exclusive signing policy, receivers would of rejected the junk
>> distributed by Dave's l
On Sun, 10 Jul 2011, Hector Santos wrote:
> Now of course, if ADSP was a standard and whitehouse.com had an
> exclusive signing policy, receivers would of rejected the junk
> distributed by Dave's list server as an ADSP violation. But ADSP is a
> pipe dream.
The attack only matters if the user be
Michael Deutschmann wrote:
> One additional thought on the whole double-From: argument -- if RFC
> language on the issue is justified at all, it really belongs in the
> ADSP RFC, not a core DKIM one.
>
> A double-From: doesn't even rise to the level of theoretical threat
> except when dealing with
13 matches
Mail list logo