On Aug 24, 2006, at 11:09 AM, Jon Callas wrote:
Indeed the DKIM signature does not directly validate the 2822.From
address. However there is a means for the signing domain to
communicate an assurance of the 2822.From address through the use
of the dkim-signature i= syntax. A similar asse
Indeed the DKIM signature does not directly validate the 2822.From
address. However there is a means for the signing domain to
communicate an assurance of the 2822.From address through the use
of the dkim-signature i= syntax. A similar assertion is equally
plausible within the 2822.From p
On Aug 23, 2006, at 10:59 AM, Jon Callas wrote:
Applying a signature and ensuring the 2822.From header can not be
modified is not equal to having validated that the account sending
the message represents the recipient of that 2822.From address or
that this account's use of the 2822.From
Applying a signature and ensuring the 2822.From header can not be
modified is not equal to having validated that the account sending
the message represents the recipient of that 2822.From address or
that this account's use of the 2822.From address is valid. Being
included in the signatur
On Aug 22, 2006, at 9:57 AM, Jon Callas wrote:
On 21 Aug 2006, at 10:48 PM, Douglas Otis wrote:
When DKIM fails to offer a means to assure the validity of the
2822.From address, then an important goal has been missed. The
use of a subdomain for signing removes an ability to indicate with
On 21 Aug 2006, at 10:48 PM, Douglas Otis wrote:
When DKIM fails to offer a means to assure the validity of the
2822.From address, then an important goal has been missed. The use
of a
subdomain for signing removes an ability to indicate with the i=
syntax
that the 2822.From is assured to b
On Tue, 2006-08-22 at 10:45 -0400, Damon wrote:
>
> Wow, that was a lot of typing to try and convince me that everyone
> hates more phone calls and trouble tickets and therefore we should
> punt.
>
> Are you saying that you see NO value in it or so little value that it
> would be statistically ins
On 8/22/06, Douglas Otis <[EMAIL PROTECTED]> wrote:
On Tue, 2006-08-22 at 05:54 -0400, Hector Santos wrote:
>
> But 99% of the times or lets just say it is expected police protocol
> and practice for a traffic stop that if there is a problem with your
> Driver's license; the photo, the sex, age,
On Tue, 2006-08-22 at 05:54 -0400, Hector Santos wrote:
>
> But 99% of the times or lets just say it is expected police protocol
> and practice for a traffic stop that if there is a problem with your
> Driver's license; the photo, the sex, age, height, etc, it is simply
> not quite consistent which
Original Message -
From: "Dave Crocker" <[EMAIL PROTECTED]>
> In other words, the job of DKIM is to deliver a valid identity
> to an assessment mechanism.
To me, SSP is an protocol assessment mechanism. I view it as an assessment
of the proper and expected protocol usage and consistency.
On Mon, 2006-08-21 at 22:29 -0400, Wietse Venema wrote:
> Douglas Otis:
> > When Big-Bank.com is coerced into using subdomains to partition their
> > messages, their customers will see more complex domain names within
> > the email-addresses and might become confused by what they see.
> >
> >
Wietse Venema wrote:
>> When Big-Bank.com is coerced into using subdomains to partition their
>> messages, their customers will see more complex domain names within
>> the email-addresses and might become confused by what they see.
...
> No, the SIGNER uses different d= domains in the signatu
Douglas Otis:
> When Big-Bank.com is coerced into using subdomains to partition their
> messages, their customers will see more complex domain names within
> the email-addresses and might become confused by what they see.
>
> Perhaps this might be subdomains like:
>
> [EMAIL PROTECTED]
>
On Aug 21, 2006, at 5:19 PM, Dave Crocker wrote:
It seems too early to know how key selectors might be used,
No it doesn't.
A selector adds one level of name granularity. So does a regular
sub-domain name.
If the purpose of an extra level of granularity is semantic, then
it belongs
>> It seems too early to know how key selectors might be used,
No it doesn't.
A selector adds one level of name granularity. So does a regular sub-domain
name.
If the purpose of an extra level of granularity is semantic, then it belongs in
the actual name. That is, it belongs in the d= st
On 2006-08-21 14:15, Dave Crocker wrote:
It is even more important that we carefully distinguish between internal
operational policies, versus the information that a signer must make public.
+1
[ . . . ]
If the signer wants to have assessment be based on different reputations, such
as for m
On 8/21/06, Michael Thomas <[EMAIL PROTECTED]> wrote:
Damon wrote:
> This is _exactly_ the direction I would like to go, and so far, I
> don't see a technical issue with it as long as we _do not_ say, 3rd
> parties can sign for me even if I don't want them to.
Nobody to my knowledge has taken t
Damon wrote:
This is _exactly_ the direction I would like to go, and so far, I
don't see a technical issue with it as long as we _do not_ say, 3rd
parties can sign for me even if I don't want them to.
Nobody to my knowledge has taken that position.
Mike
It seems too early to know how key selectors might be used, whether
reputation accrues to just the parent domain, and the role of the
2822.From address. Perhaps a convention is established for
transactional messages where the right-most label in the key selector
is named "safe". Selectors might
On Aug 21, 2006, at 2:15 PM, Dave Crocker wrote:
Folks,
Wietse Venema wrote:
With a shared signing key+domain, if one of those thousands of
domains mis-behaves, all the other domains could suffer from the
bad reputation of that shared signing key+domain.
Thus it's better to avoid shared
On Monday 21 August 2006 17:15, Dave Crocker wrote:
...
> The question is what does the signer need to communicate to a validation
> site, for the validation site to be able to make a useful assessment?
>
> The answer is: a validly signed domain name.
>
> That's all.
>
> If the signer wants to hav
Folks,
Wietse Venema wrote:
> With a shared signing key+domain, if one of those thousands of
> domains mis-behaves, all the other domains could suffer from the
> bad reputation of that shared signing key+domain.
>
> Thus it's better to avoid shared signing key+domain scenarios.
Based on some con
22 matches
Mail list logo
