SM wrote:
At 17:06 26-01-2009, Dave CROCKER wrote:
Common interpretation of the document is that it *already* provides
two identities. The Errata merely makes clear their nature and priority.
The draft Errata does not update Section 1.1 of RFC 4871 which discusses
about Signing
Ok. The key question there seems to me to be 'does the UAID namespace
represent actual identities'? For most of the use cases I can think of
for assessing the UAID, it doesn't really matter whether it matches the
from address or not.
-Original Message-
From:
On Tue, Jan 27, 2009 at 8:47 PM, Adkins, Michael
michael.adk...@corp.aol.com wrote:
Ok. The key question there seems to me to be 'does the UAID namespace
represent actual identities'? For most of the use cases I can think of
for assessing the UAID, it doesn't really matter whether it matches
Suresh Ramasubramanian wrote:
On Tue, Jan 27, 2009 at 8:47 PM, Adkins, Michael
michael.adk...@corp.aol.com wrote:
Ok. The key question there seems to me to be 'does the UAID namespace
represent actual identities'? For most of the use cases I can think of
for assessing the UAID, it doesn't
On Tue, Jan 27, 2009 at 9:03 PM, Dave CROCKER d...@dcrocker.net wrote:
It looks as if the two of you are agreeing that the i= value is indeed
opaque to a receiver.
Cant speak for madkins but that's my impression. I would also add
often irrelevant besides opaque
--
Suresh Ramasubramanian
Yes, we are in agreement about opacity. I would even agree about the
'often irrelevant' part. It's the few large cases where it's a good
solution that I would like to make sure we can still use it.
And I didn't really mean for my comment on the errata to turn into a
discussion of this topic, so
On Tue, Jan 27, 2009 at 09:04:10PM +0530, Suresh Ramasubramanian wrote:
On Tue, Jan 27, 2009 at 9:03 PM, Dave CROCKER d...@dcrocker.net wrote:
It looks as if the two of you are agreeing that the i= value is indeed
opaque to a receiver.
Cant speak for madkins but that's my impression. I would
The few large cases are
1. Exceptions to the general rule
2. Useful only when backed with some out of band discussion about
these .. I trust you to know that when you sign email as good (or bad)
it probably is that . but how much would I trust other providers? Or
suppose a sender signs his mail
On Tue, Jan 27, 2009 at 9:30 PM, Jeff Macdonald jmacdon...@e-dialog.com wrote:
you lost me Suresh. It seemed like you were saying that i= would be
useful for different streams or groups of identities but then you say
often irrelevant.
I believe what i= means is irrelevant from the perspective
Suresh Ramasubramanian wrote:
The few large cases are
1. Exceptions to the general rule
2. Useful only when backed with some out of band discussion about
these ..
How does (or should) this affect the proposed Errata specification?
d/
--
Dave Crocker
Brandenburg
Your notes in 10 and 11 are correct in that UAID should be replaced with
SDID, with one caveat. If you can't assume that the UAID is even an
identity, there is no reason to warn the reader that the UAID is
different from the From address or point it out.
The only cases where the handling mail
On Tue, Jan 27, 2009 at 09:31:51PM +0530, Suresh Ramasubramanian wrote:
The few large cases are
1. Exceptions to the general rule
2. Useful only when backed with some out of band discussion about
these .. I trust you to know that when you sign email as good (or bad)
it probably is that . but how
On Tue, Jan 27, 2009 at 10:20 PM, Jeff Macdonald
jmacdon...@e-dialog.com wrote:
I'd still think even given that model, you'd let the actions of the i=
determine the trustworthness of the steam independent of what the owner
of d= claims.
Always crosscheck, is a good general rule. But let's put
[Changing subject as per Dave's request]
I've thought about just sort of passively watching UAID values and
building heuristics to guess whether they are worth assessing or not.
It might be really useful, or it might just be a complete waste of
resources. There's no good way to know for sure
Adkins, Michael wrote:
Your notes in 10 and 11 are correct in that UAID should be replaced with
SDID, with one caveat. If you can't assume that the UAID is even an
identity, there is no reason to warn the reader that the UAID is
different from the From address or point it out.
The only
It does.
-Original Message-
From: Dave CROCKER [mailto:d...@dcrocker.net]
Sent: Tuesday, January 27, 2009 12:01 PM
To: Adkins, Michael
Cc: DKIM IETF WG
Subject: Re: [ietf-dkim] draft Errata on RFC 4871
Adkins, Michael wrote:
Your notes in 10 and 11 are correct in that UAID should be
ok by me
srs
On Tue, Jan 27, 2009 at 10:31 PM, Dave CROCKER d...@dcrocker.net wrote:
1. For 10 and 11, change UAID to be SDID.
2. Add text about the use of i= stating that it's use for assessment goes
beyond using d= and is MUST be based on additional knowledge of its creation
that is
I think Suresh (and possibly Mike) are advocating a different sort of
model for i= that I (and I think many others) have for it.
They appear to be ignoring one part of the i= definition
Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message
On Tue, Jan 27, 2009 at 10:43 PM, Tony Hansen t...@att.com wrote:
and that's the word identity. They seem to be replacing it with what
appears to be an assessment of the identity as provided by someone
else. Hence their references to i=g...@aol.com, i=...@aol.com, etc. This
is contrary to the
1. For 10 and 11, change UAID to be SDID.
2. Add text about the use of i= stating that its use for assessment goes
beyond using d= and is MUST be based on additional knowledge of its creation
that is outside the specification.
Does this reflect what you two are implying?
This agrees
Suresh Ramasubramanian wrote:
On Tue, Jan 27, 2009 at 11:05 PM, John Levine jo...@iecc.com wrote:
This agrees with my understanding, too. The i= may have to be an
identity, but nothing says the identity has to be meaningful to anyone
other than the signer.
In which case either the errata
Jim,
Jim Fenton wrote:
1. 1399 received no substantive discussion and was then declared
redundant with 1519. So citing it winds up confusing the current
discussion.
Issue 1399 was open for over 4 months, surely enough time for anyone who
wished to comment to do so. If there is a
Dave CROCKER wrote:
Jim Fenton wrote:
Nevertheless, what's in the specification represents working group rough
consensus, in connection with issues 1399 and 1519. There have been
opportunities in WG Last Call and IETF Last Call to reconsider that
decision.
So, Jim, I commend your effort
Suresh Ramasubramanian wrote:
On Tue, Jan 27, 2009 at 10:53 PM, J.D. Falk
jdfalk-li...@cybernothing.org wrote:
It's irrelevant for purposes of spam filtering, but not for the equally
valid purpose of is this message really from my grandma?
(Or, more accurately, is this message really from
Dave CROCKER wrote:
Suresh Ramasubramanian wrote:
2. DKIM signs all the headers and validation of that hash tends to be
useful to verify grandma is who she is. Or at least its her, or its
comrade botmaster who's just taken over grandma's PC.
This is a common misunderstanding of DKIM:
JD,
I fear you missed my point:
Identity of the user or agent (e.g., a mailing list manager) on
behalf of which this message is signed
does not mean that that user or agent was the author. So the value might be
wonderfully stable, but its semantics say nothing about authorship.
On Jan 27, 2009, at 10:30 AM, Suresh Ramasubramanian wrote:
On Tue, Jan 27, 2009 at 10:53 PM, J.D. Falk
jdfalk-li...@cybernothing.org wrote:
It's irrelevant for purposes of spam filtering, but not for the
equally
valid purpose of is this message really from my grandma?
(Or, more
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
With DKIM i=, it becomes possible to convey a stable identifier
(though of
course there's no guarantee that the identifier is stable, leading
to John's
t= suggestion.) Without DKIM (or something like it), as we know, any
potential
Doesnt have to sign *all* - but some key fields like an authenticator
and/or received headers that stamp Received: from (f...@localhost) say
are certainly going to make sense to sign.
My concern was that we are reinventing the wheel a lot when we use i=
as a substitute for these other headers,
On Wed, Jan 28, 2009 at 1:25 AM, Steve Atkins st...@wordtothewise.com wrote:
Exactly. And that's something that's already demonstrated to scale
and be useful. Merging that functionality into (a large subset of) email
is almost inevitable, I think.
Social networking is all very good. But you
30 matches
Mail list logo
