At 15:58 13-02-2009, Murray S. Kucherawy wrote:
>We SHOULD NOT (in 2119 terms) make any changes to the base spec, which is
>followed by a growing deployed base, via erratum or a full revision in a
>way which establishes any new constraints.
A base specification generally takes a minimalist approac
On Feb 13, 2009, at 3:33 PM, Ellen Siegel wrote:
> Can you explain why you think this makes it impossible to use i= in
> an arbitrary way? I don't see that that usage is excluded. If it's
> not intended to be stable, there is no constraint at all except that
> it can't use an identical iden
On Fri, 13 Feb 2009, Ellen Siegel wrote:
In other words, I think the intent is that messages using the same
UAID MUST be intended to be evaluated as sharing the same sphere of
responsibility (this is a mandate on the sender's usage, not on the
receiver's interpretation); senders
On Fri, Feb 13, 2009 at 1:52 PM, Murray S. Kucherawy wrote:
> On Fri, 13 Feb 2009, Jeff Macdonald wrote:
> >> In other words, I think the intent is that messages using the same
> >> UAID MUST be intended to be evaluated as sharing the same sphere of
> >> responsibility (this is a mandate on the se
On Fri, 13 Feb 2009, Jeff Macdonald wrote:
>> In other words, I think the intent is that messages using the same
>> UAID MUST be intended to be evaluated as sharing the same sphere of
>> responsibility (this is a mandate on the sender's usage, not on the
>> receiver's interpretation); senders SHOUL
On Thu, Feb 12, 2009 at 05:38:34PM -0500, Siegel, Ellen wrote:
>
>
>> >
>> > "... The Signer MAY choose to use the same namespace for its UAIDs as
>> its
>> > users' email addresses, or MAY choose other means of representing its
>> > users. However, the signer SHOULD use the same UAID for each mess
> >
> > "... The Signer MAY choose to use the same namespace for its UAIDs as
> its
> > users' email addresses, or MAY choose other means of representing its
> > users. However, the signer SHOULD use the same UAID for each message
> > intended to be evaluated as being within the same sphere of
>
On Wed, Feb 11, 2009 at 01:44:32PM -0800, Murray S. Kucherawy wrote:
> On Wed, 11 Feb 2009, Jeff Macdonald wrote:
My understanding of opaque allows identical opaque values to
identify the same "something".
>>>
>>> Then you're arguing for something stronger than what the draft
>>> propo
Jeff Macdonald wrote:
> On Wed, Feb 11, 2009 at 09:01:39AM -0800, Jim Fenton wrote:
>
>>> Assume the messages pass DKIM authentication. Next the "output of DKIM"
>>> is passed to some reputation module. Receiver A decides that is i= and
>>> treats the two types of DKIM messages as the signer intend
On Wed, 11 Feb 2009, Jeff Macdonald wrote:
>>> My understanding of opaque allows identical opaque values to identify
>>> the same "something".
>>
>> Then you're arguing for something stronger than what the draft
>> proposes. The draft uses SHOULD, where to match your understanding, it
>> would
On Wed, Feb 11, 2009 at 11:46:14AM -0800, Murray S. Kucherawy wrote:
> On Wed, 11 Feb 2009, Jeff Macdonald wrote:
>>> It would be equally valid for a signer to apply a different
>>> pseudo-subdomain on each message, perhaps for tracking purposes.
>>
>> I think that is actually a mis-use of DKIM.
On Wed, 11 Feb 2009, Jeff Macdonald wrote:
>> It would be equally valid for a signer to apply a different
>> pseudo-subdomain on each message, perhaps for tracking purposes.
>
> I think that is actually a mis-use of DKIM. The message-id field covers
> that nicely.
But Message-ID:'s semantics are
On Wed, Feb 11, 2009 at 09:01:39AM -0800, Jim Fenton wrote:
>Jeff Macdonald wrote:
>>
>> As a signer, I may want to do this:
>>
>> i...@transaction.company.com d=company.com for transactional messages and
>> d=company.com for everything else (yes, there is no i=, but i= defaults
>> to @d). This is
On Feb 11, 2009, at 9:01 AM, Jim Fenton wrote:
> If the value is really intended to be opaque, the verifier shouldn't
> even group together like pseudo-subdomains for reputation purposes,
> in the absence of out-of-band information describing what the signer
> does.
Jim,
When mitigating r
Jeff Macdonald wrote:
>
> As a signer, I may want to do this:
>
> i...@transaction.company.com d=company.com for transactional messages and
> d=company.com for everything else (yes, there is no i=, but i= defaults
> to @d). This is done to emulate separate IP streams by using a DKIM
> identifier. I
On Wed, Feb 11, 2009 at 12:03:40PM +0100, Eliot Lear wrote:
> On 2/11/09 10:50 AM, Murray S. Kucherawy wrote:
>
> Or, alternately, perhaps you're suggesting that's not an issue that
> really needs to be solved? (That's not sarcastic; I don't have
> experience yet to suggest this is a fire that n
On 2/11/09 10:50 AM, Murray S. Kucherawy wrote:
Or, alternately, perhaps you're suggesting that's not an issue that really
needs to be solved? (That's not sarcastic; I don't have experience yet to
suggest this is a fire that needs to be put out, so I'm genuinely
wondering.)
Murray,
I do
Eliot,
Your proposal would satisfy me (as an implementor, anyway) in terms of the
opacity of the local-part value in "i=".
What it doesn't do is address the question about whether or not RFC4871
presents a single identity as its output, and if so, which one that is.
Or, alternately, perhaps yo
On Feb 10, 2009, at 11:42 AM, Eliot Lear wrote:
While cleaner than the errata Dave Crocker is proposing, this still
changes the definition of the i= parameter intended to represent the
identity on whose behalf the signature was added. It is not
reasonable to assume the i= represents a coll
Dear all,
As I had mentioned in a previous email[*], my understanding of the
concerns raised by Dave and others is that there is insufficient clarity
(I originally used the word sternness) in the warnings about the use of
i=, with respect to its stability and presence. My greatest concern
wit
20 matches
Mail list logo
