>I'm not sure what my opinion is on that last point, but on the first
>point I think it's best to define an identifier that's specifically
>for ADSP's use, if we want that function. Some signers may give that
>tag the same value they give i=, and there's no harm done. Some
>signers may use a diff
Dave CROCKER wrote:
> pasi.ero...@nokia.com wrote:
>
>> - I think introducing clear terminology for the identity/identities
>> (or identifier/identifiers) "output by DKIM" would make DKIM
>> significantly easier to understand, and would be useful in this
>> document, too. Places that probably woul
Dave, all,
I think the problem isn't so much that you aren't being precise with
UAID, but rather two fold:
1. UA has an existing connotation that people will grab onto. This in
itself is mnemonically confusing.
2. If you're going to add acronyms, let them be ones that either can be
easily p
John Levine:
> >I'm not sure what my opinion is on that last point, but on the first
> >point I think it's best to define an identifier that's specifically
> >for ADSP's use, if we want that function. Some signers may give that
> >tag the same value they give i=, and there's no harm done. Some
>
John Levine wrote:
>> I'm not sure what my opinion is on that last point, but on the first
>> point I think it's best to define an identifier that's specifically
>> for ADSP's use, if we want that function. Some signers may give that
>> tag the same value they give i=, and there's no harm done. S
Barry Leiba wrote:
> > The IESG has Errata rules that cover the qualities required or
> > prohibited for an Errata entry that applies to a standards track
> > document. By all appearances, those rules are being invoked but
> > not followed. They say nothing about the length of an entry and
> >
On Wed, Mar 11, 2009 at 10:40:18AM -, John Levine wrote:
>>I'm not sure what my opinion is on that last point, but on the first
>>point I think it's best to define an identifier that's specifically
>>for ADSP's use, if we want that function. Some signers may give that
>>tag the same value they
Eliot Lear wrote:
> As to the chair's request, FWIW I *have* given Dave suggested
> changes, and I believe he has accepted some of them. I must admit
> some confusion about the process at this point. It seems that there
> is an outstanding request of Pasi about whether this draft can
> proceed.
pasi.ero...@nokia.com wrote:
> Barry Leiba wrote:
> 7. Changes that modify the working of a protocol to something that
> might be different from the intended consensus when the document
> was approved should be either Hold for Document Update or
> Rejected.
...
> I do not think
Eliot Lear wrote:
> 1. UA has an existing connotation that people will grab onto. This in
> itself is mnemonically confusing.
It's not confusing if the meaning is related. The term "user or agent" is the
actual semantics of this value. I read that as equivalent to "user agent".
The basic
Folks,
Question to the working group...
DKIM Chair wrote:
> To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that
> we
> will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other
> choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of John Levine
> Sent: Wednesday, March 11, 2009 6:40 AM
> To: ietf-dkim@mipassoc.org
> Cc: barryle...@computer.org
> Subject: Re: [ietf-dkim] Moving on to ADSP - was RE: Handl
On 3/11/09 4:50 PM, Dave CROCKER wrote:
>
>
> Eliot Lear wrote:
>> 1. UA has an existing connotation that people will grab onto. This
>> in itself is mnemonically confusing.
>
> It's not confusing if the meaning is related. The term "user or
> agent" is the actual semantics of this value. I r
Eliot Lear wrote:
>> It's not confusing if the meaning is related. The term "user or
>> agent" is the actual semantics of this value. I read that as
>> equivalent to "user agent".
>
> It's not. A user agent is an application that acts on behalf of the
> user but is not the user.
UAID is
Humorous (maybe) and meaningless (definitely) side-comment, here,
because we need to maintain levity as well as progress:
> My personal preference for best acronym used by the
> IETF is still IPoLPDN. I leave it as an exercise to the reader or the
> reader's memory to understand how that was pron
Just on this point:
> Do you think that that label would have obvious and useful meaning to
> an average administrator who is trying to configure DKIM modules? I
> don't. I'm not even sure it's "really what is being described here"
> because the label is sufficiently far from language used in
Actually responding to the thread this time, as a participant...
>>> It's not confusing if the meaning is related. The term "user or
>>> agent" is the actual semantics of this value. I read that as
>>> equivalent to "user agent".
>>
>> It's not. A user agent is an application that acts on behal
MH Michael Hammer (5304) wrote:
> I view introducing a new tag at this point as problematic.
Agreed.
> Using i= or even going to using d= does not require any changes to
> current DKIM signing implementations. Introducing a new tag means that
> implementers are at the mercy of the timeframes tha
Barry Leiba wrote:
> The only concern I have here is that because "user agent" has a
> specific connotation, there could be confusion about what happens to
> it when a user uses more than one UA. Suppose I use Gmail's web
> client, Mulberry, Apple Mail, and Thunderbird, all at different times,
>
Isn't it much simpler, and entirely sufficient, to have ADSP use SDID (d=)?
I am not understanding the downside to the choice.
The alternatives all seem significantly more complicated and probably
problematic.
d/
J.D. Falk wrote:
> MH Michael Hammer (5304) wrote:
>
>> I view introducing a new
Dave CROCKER wrote:
>
> One of the tricks in choosing labels is to make sure they each have
> useful meaning, but also that they are different enough to avoid
> confusion. Labels are intended to have mnemonic benefit.
[...]
>
>> User Agent Identifier (UAID)
> ...
>> the user or agent on behalf o
The use of i= allows multiple subdomains to have the same d= DKIM
signature. As I said, I can live with d= personally but viewing it from
a standards approach I recognize the value of using i= for organizations
that use a number of subdomains.
Sometimes simplifying in one place (eliminate use of
Barry Leiba wrote:
> Actually responding to the thread this time, as a participant...
>
>
It's not confusing if the meaning is related. The term "user or
agent" is the actual semantics of this value. I read that as
equivalent to "user agent".
>>> It's not. A user
Dave CROCKER wrote:
>
> Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?
>
I believe the Chairs requested that the other, non-controversial, errata
be incorporated into this draft. Is that (editorial) work ongoing?
-Jim
___
Jim Fenton wrote:
> Dave CROCKER wrote:
>> Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?
>>
>
> I believe the Chairs requested that the other, non-controversial, errata
> be incorporated into this draft.
I think we suggested it as an option rather than requested
Jim Fenton wrote:
> Dave CROCKER wrote:
>> Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed?
>
> I believe the Chairs requested that the other, non-controversial, errata
> be incorporated into this draft. Is that (editorial) work ongoing?
No, they didn't:
> DKIM Chair
Dave CROCKER wrote:
> First, thank you for the clarification. I believe I now do understand your
> logic and, sadly, I believe your interpretation of the implication of the
> "might" is a reasonable.
>
> Unfortunately the simple, practical result of your interpretation and logic
> is:
> Sta
Stephen Farrell wrote:
>> Is that (editorial) work ongoing?
>
> I think it'd be great if Dave were willing to do that, but I could
> understand if he'd rather not.
I'm fine with continuing to edit the draft-ietf-dkim-rfc4871-errata for the
working group.
d/
--
Dave Crocker
Brandenburg
On Mar 11, 2009, at 10:15 AM, Dave CROCKER wrote:
> Isn't it much simpler, and entirely sufficient, to have ADSP use
> SDID (d=)?
>
> I am not understanding the downside to the choice.
>
> The alternatives all seem significantly more complicated and
> probably problematic.
100% agreed. : ^)
> -Original Message-
> On Behalf Of John Levine
>
> Seems like a reasonable way to avoid the i= fight. If there's interest,
> I can whip up a new ADSP draft with an r= tag.
>
Sounds like a good approach to me.
Ellen
___
NOTE WELL: This li
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Douglas Otis
> Sent: Wednesday, March 11, 2009 2:13 PM
> To: dcroc...@bbiw.net
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] Moving on to ADSP - was RE: Handlingth
Siegel, Ellen wrote:
>
>> -Original Message-
>> On Behalf Of John Levine
>>
>> Seems like a reasonable way to avoid the i= fight. If there's interest,
>> I can whip up a new ADSP draft with an r= tag.
>>
>
> Sounds like a good approach to me.
Just in case: Please don't prepare a new A
On Wed, 11 Mar 2009 08:54:35 -0700 Dave CROCKER wrote:
>Folks,
>
>Question to the working group...
>
>
>DKIM Chair wrote:
>> To those who voted against draft-ietf-dkim-rfc4871-errata: given, now,
that we
>> will be using draft-ietf-dkim-rfc4871-errata to move forward, and the
other
>> choices
It seems to me that the domains likely to benefit from the ability to
state "All email we send is DKIM signed" share a few things in common.
1. They're concerned about other people sending email claiming to
be "from" the domain.
2. They send email using the domain to, typically, a large
Stephen Farrell wrote:
>
> Siegel, Ellen wrote:
>>> -Original Message-
>>> On Behalf Of John Levine
>>>
>>> Seems like a reasonable way to avoid the i= fight. If there's interest,
>>> I can whip up a new ADSP draft with an r= tag.
>>>
>> Sounds like a good approach to me.
>
> Just in cas
The more we move "policy" information or in this case Jim's reputation-based
policy r= idea to the DKIM policy record, the better, where it ought to be
to better cover the legacy transactions (those without signatures).
--
hls
On Wed, Mar 11, 2009 at 12:01 PM, MH Michael Hammer (5304)
wrote:
>
On Wed, Mar 11, 2009 at 3:33 PM, Steve Atkins wrote:
>
> Did we already look at this idea and discard it before we settled on
> using a DNS query for every email received?
Discussed, not discarded. AFAIR, the general feeling is that Lookups are
cheap today.
As defined by the SSP design requir
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Steve Atkins
> Sent: Wednesday, March 11, 2009 3:34 PM
> To: ietf-dkim WG
> Subject: [ietf-dkim] Another take on "all email from us is dkim
signed"
>
> It seems to me that
Steve Atkins wrote:
> If there were another field in the DKIM-Signature header, or an
> entirely separate email header covered by the DKIM signature, that
> stated "all email sent using this domain in the From field will be
> DKIM signed" then any receiving MTA or MTA cluster could keep track
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Michael Thomas
> Sent: Wednesday, March 11, 2009 4:26 PM
> To: Steve Atkins
> Cc: ietf-dkim WG
> Subject: Re: [ietf-dkim] Another take on "all email from us is dkim
> signed
On Mar 11, 2009, at 1:26 PM, Michael Thomas wrote:
> Steve Atkins wrote:
>> If there were another field in the DKIM-Signature header, or an
>> entirely separate email header covered by the DKIM signature, that
>> stated "all email sent using this domain in the From field will be
>> DKIM
On Mar 11, 2009, at 1:20 PM, MH Michael Hammer (5304) wrote:
>>
>> It seems to me that the domains likely to benefit from the ability to
>> state "All email we send is DKIM signed" share a few things in
>> common.
>>
>> 1. They're concerned about other people sending email claiming to
>> be "
MH Michael Hammer (5304) wrote:
>>If nothing else, this would make revocation sort of... bizarre
>>and unpredictable. The implication is that I'd have to send $you
>>mail (for $you == 'universe') to get you to nuke my record in your
>>database. Of course every good protocol becomes
On Wed, Mar 11, 2009 at 3:33 PM, Steve Atkins wrote:
If there were another field in the DKIM-Signature header, or an
> entirely separate email header covered by the DKIM signature, that
> stated "all email sent using this domain in the From field will be
> DKIM signed" then any receiving MTA or MT
On Mar 11, 2009, at 1:38 PM, HLS wrote:
>
>
> On Wed, Mar 11, 2009 at 3:33 PM, Steve Atkins
> wrote:
>
> If there were another field in the DKIM-Signature header, or an
> entirely separate email header covered by the DKIM signature, that
> stated "all email sent using this domain in the From f
On Wed, Mar 11, 2009 at 4:33 PM, Mark Delany
> wrote:
> On Wed, Mar 11, 2009 at 3:33 PM, Steve Atkins wrote:
>
>>
>> Did we already look at this idea and discard it before we settled on
>> using a DNS query for every email received?
>
>
> Discussed, not discarded. AFAIR, the general feeling is
Scott Kitterman wrote:
> I won't propose any. I don't have time to do a proper job of rewriting it.
> I think it alters
> the IETF conensus view via errata and adds needless complexity.
>
> Silence or lack of change proposals does not equate to thinking the current
> draft is good.
+1
I t
On Wed, Mar 11, 2009 at 3:33 PM, Steve Atkins
wrote:
Did we already look at this idea and discard it before we settled on
using a DNS query for every email received?
Discussed, not discarded. AFAIR, the general feeling is that
Lookups are cheap today.
Essentially such an approach is a
On Wed, Mar 11, 2009 at 4:53 PM, Mark Delany
> wrote:
> Outside of DNS query related technical issues, the first operational
>> repercussion is the lost of handling legacy mail. We need to use an
>> "standard anchor" something we know will always be there, which as it is
>> now, is the From:
> Outside of DNS query related technical issues, the first
> operational repercussion is the lost of handling legacy mail. We
> need to use an "standard anchor" something we know will always be
> there, which as it is now, is the From: domain lookup.
>
For those subset of folk who want t
http://dkimcore.org/dkimcore.pdf
I just stumbled on this document, this seems strange to me. What do you think?
I find that adding a hash on the body and putting it in the DKIM record will
certainly break the DKIM spec, as it stops mailing lists to forward a DKIM
email and add a footer to the
On Wed, Mar 11, 2009 at 4:41 PM, Steve Atkins wrote:
>
> On Mar 11, 2009, at 1:38 PM, HLS wrote:
>
> >
> >
> > On Wed, Mar 11, 2009 at 3:33 PM, Steve Atkins
> > wrote:
> >
> > This was touched upon back in 2007/2008 holidays with a WG
> > suggestion to add a DKIM-Signature tag thats says *first p
Somewhat whimsically but wholly serious: Would simply changing the
acronym to AUID (for Agent or User IDentifier) avoid mistaken
connotations associated with User Agents (UAs)?
Tony
Jim Fenton wrote:
> Barry Leiba wrote:
>> Actually responding to the thread this time, as a participant...
On Mar 11, 2009, at 2:05 PM, Tony Hansen wrote:
> Somewhat whimsically but wholly serious: Would simply changing the
> acronym to AUID (for Agent or User IDentifier) avoid mistaken
> connotations associated with User Agents (UAs)?
+1 for the easy fix.
Cheers,
Steve
_
> Somewhat whimsically but wholly serious: Would simply changing the
> acronym to AUID (for Agent or User IDentifier) avoid mistaken
> connotations associated with User Agents (UAs)?
WFM.
Barry
___
NOTE WELL: This list operates according to
http://mipa
Well, anonymous domains and documents should not be trusted, especially
since PDF has recently suffered with Zero-Day PDF Exploit.
Google: PDF Zero Day Exploit
Its fresh out of the press.
This domain has no content, totally blind. I would not trust this dkimcore
. org until they reveal
Before I attempt to answer Dave's question, I have two questions for the
Chairs:
1. Is discussion of ADSP on the list in order again?
2. It sounds like what's being proposed here is a "do over" of the WG
and IETF Last Calls on the ADSP specification, by making a substantial
change. Is that in or
MH Michael Hammer (5304) wrote:
>>
>> It also seems that the number of domains who want this will likely be
>> a small fraction of the total number of domains, and likely a small
>> fraction of the number of emails sent.
>>
>
> That may be true today but may not be true tomorrow.
Besides the fa
On Wed, 11 Mar 2009 15:55:05 -0700 Jim Fenton wrote:
>Before I attempt to answer Dave's question, I have two questions for the
>Chairs:
>
>1. Is discussion of ADSP on the list in order again?
>
>2. It sounds like what's being proposed here is a "do over" of the WG
>and IETF Last Calls on the ADSP
On Mar 11, 2009, at 11:59 AM, MH Michael Hammer (5304) wrote:
>> On Mar 11, 2009 11:12 AM, Douglas Otis wrote:
>>
>> The only logic for requiring either a DKIM signature that lacks an
>> i= value, or one that matches against the From header, would be
>> there is something special about a DKIM
On Thu, Mar 12, 2009 at 3:54 AM, Barry Leiba wrote:
>> Somewhat whimsically but wholly serious: Would simply changing the
>> acronym to AUID (for Agent or User IDentifier) avoid mistaken
>> connotations associated with User Agents (UAs)?
>
> WFM.
+1
___
At 15:24 11-03-2009, HLS wrote:
>This domain has no content, totally blind. I would not trust this
>dkimcore . org until they reveal themselves.
The person who wrote that document revealed himself/herself. :-)
Regards,
-sm
___
NOTE WELL: This list o
On Thu, Mar 12, 2009 at 9:17 AM, SM wrote:
> At 15:24 11-03-2009, HLS wrote:
>>This domain has no content, totally blind. I would not trust this
>>dkimcore . org until they reveal themselves.
>
> The person who wrote that document revealed himself/herself. :-)
And if people missed that, then I a
I've uploaded the following draft agenda to the IETF 74 meeting materials page.
https://datatracker.ietf.org/meeting/74/materials.html
This is a first stab at a draft, and I've made wild guesses at the times. If
you
have better suggestions for dividing up the time, let Stephen and me know, at
Suresh Ramasubramanian wrote:
> On Thu, Mar 12, 2009 at 9:17 AM, SM wrote:
>> At 15:24 11-03-2009, HLS wrote:
>>> This domain has no content, totally blind. I would not trust this
>>> dkimcore . org until they reveal themselves.
>>>
>> The person who wrote that document revealed himself/herself.
65 matches
Mail list logo
