On 01.05.2011 14:13, John R. Levine wrote:
I don't think we actually understand all the ways that l= allows you to
shoot yourself in the foot, so I would prefer not to give the impression
that if people avoid a few cases we describe, they're safe.
-1, I agree we don't know all the ways DKIM
On Fri, 29 Apr 2011 18:39:03 +0100, Murray S. Kucherawy
m...@cloudmark.com wrote:
Right before Section 6:
+ Verifiers SHOULD ignore those signatures that produce a PERMFAIL
+ result (see Section 7.1), acting as though they were not present in
+ the message. ...
s/Verifiers SHOULD
On Sun, 01 May 2011 05:10:06 +0100, Hector Santos hsan...@isdg.net wrote:
So perhaps to help shut down this ambiguity we should add a DKIM
terminology to clearly separate it from AUID.
3.x Originating Domain Identity (ODID)
The ODID is the domain part of the From: address. This
I don't think we yet have consensus to take out l= but it is quite clear
that the problems it causes are far greater than whatever problems it
might solve.
As Hector notes, it is required by non-DKIM aware MLMs.
To aim one more kick at the greasy spot on the floor where the horse used
to
On 01.05.2011 10:38, Hector Santos wrote:
Again, its about protocol consistency. So maybe I should ask the
chairs for:
Consensus needs to be reevaluated
IMHO, it needs not: It is premature to define an ODID now. ADSP is
considered somewhat broken, and for this message, for
On Wed, Apr 20, 2011 at 8:29 PM, Murray S. Kucherawy m...@cloudmark.com wrote:
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of J.D. Falk
Sent: Wednesday, April 20, 2011 1:25 PM
To: ietf-dkim@mipassoc.org
Subject: Re:
On Thu, Apr 28, 2011 at 7:00 PM, Rolf E. Sonneveld
r.e.sonnev...@sonnection.nl wrote:
snip
From the design view of DKIM I know we should not want it, but what if
we would add the From address as a third _required_ output parameter?
With From: I mean: that particular From address that was
On Mon, May 2, 2011 at 11:27 AM, Charles Lindsey c...@clerew.man.ac.uk wrote:
On Sun, 01 May 2011 05:10:06 +0100, Hector Santos hsan...@isdg.net wrote:
So perhaps to help shut down this ambiguity we should add a DKIM
terminology to clearly separate it from AUID.
3.x Originating Domain
Alessandro Vesely wrote:
On 01.05.2011 10:38, Hector Santos wrote:
Again, its about protocol consistency. So maybe I should ask the
chairs for:
Consensus needs to be reevaluated
IMHO, it needs not: It is premature to define an ODID now. ADSP is
considered somewhat broken,
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Jeff Macdonald
Sent: Monday, May 02, 2011 8:07 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] ADSP stats
I can see ATPS gaining momentum in two ways:
a) ADSP
Hector Santos wrote:
IMV, ADSP is only broken in that it didn't allow you to declare you
were allowing mipassoc.org to sign for you or in general
My Mail Is Always Signed - by me or someone else.
By the way Alessandro, you could explore ADSP/ATPS support from your
record. Use
On May 1, 2011, at 10:15 AM, Dave CROCKER wrote:
On 4/30/2011 11:43 PM, Murray S. Kucherawy wrote:
I'd like to leave in MIME and HTML exploits as examples if people agree that
wouldn't be harmful, such as this updated text in 4.4.5:
tINFORMATIVE IMPLEMENTATION NOTE:
On 5/1/11 6:55 AM, Dave CROCKER wrote:
[...]
In other words, DKIM has nothing to do with the rfc5321.From field, and
therefore it is entirely inappropriate -- that is, out of scope -- for the
specification to suggest dealing with it.
You mean 5322.From?
And how should we read par. 3.2.2 of
-Original Message-
From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
On Behalf Of Rolf E. Sonneveld
Sent: Monday, May 02, 2011 1:14 PM
To: dcroc...@bbiw.net
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] Output summary - proposing ODID Originating
Murray S. Kucherawy wrote:
Although 5322.From is not mentioned here, how can DKIM provide any level
of defense against fraudulent use of origin addresses, if d= is the one
and only mandatory output of the verification process?
Why does the output of DKIM need to include something when the
Murray S. Kucherawy wrote:
It could stand some revision, I suspect.
Nevertheless, the overall threat model doesn't require that
DKIM itself, i.e. the protocol being defined, also be the
thing that evaluates origin addresses for validity or value.
It's certainly legitimate to leave that
I think the definition of all tags in 3.5 should have as much critical
information (or a section reference) that will not deviate from what
is defined.
I think the definition of i= should include information about the
public key t=s tag. This t=s information that will deviate the i=
17 matches
Mail list logo
