Damon <[EMAIL PROTECTED]> writes:
> Should mailing lists sign messages?
The problem with mailing lists is that there are 2 identities which it
might be useful to verify. First that the message did actually come
via the mailing list, and the second is the identity of the person
submitting the mess
On Tuesday 22 August 2006 20:22, [EMAIL PROTECTED] wrote:
> "This could be done, but dilutes the simplicity argument that motivated
> "the Authorized Signing Domains approach in the first place. Formerly
> "the ISP just signed using their own domain name; now they must create a
> "subdomain for ea
On Tue, 22 Aug 2006 16:06:08 -0700 Jim Fenton <[EMAIL PROTECTED]> wrote:
>Scott Kitterman wrote:
>
>On Mon, 21 Aug 2006 14:55:08 -0700 Michael Thomas <[EMAIL PROTECTED]> wrote:
>Scott Kitterman wrote:
>OTOH, it seems to me that it's been said Ad Nauseum. Where feasible I
agree it's better, but the
On Tue, 22 Aug 2006 15:59:00 -0700 Jim Fenton <[EMAIL PROTECTED]> wrote:
>Scott Kitterman wrote:
>> On Monday 21 August 2006 01:34, Jim Fenton wrote:
>>> Scott Kitterman wrote:
Yes, but the fundamental operational problem will be to pick the
correct
domain to sign with. You have to mak
On Aug 22, 2006, at 5:05 PM, Damon wrote:
If an ISP were using the key/location provided to them from
various customers, there would be an identical process need. The
assigned keys however now include a need to acquire these keys
rather than simply creating them. In addition, there would
"This could be done, but dilutes the simplicity argument that motivated
"the Authorized Signing Domains approach in the first place. Formerly
"the ISP just signed using their own domain name; now they must create a
"subdomain for each of their customers, publish keys there, and sign each
"using t
Jim,
I consider the baseline situation where verifiers receiving non-signed
messages and what you would use from the minimum 2822 headers available to
extract the domain policy information.
What will that be?
In other words, if you have:
Received:
From:
To:
Subject:
Date:
and no othe
If an ISP were using the key/location provided to them from various
customers, there would be an identical process need. The assigned
keys however now include a need to acquire these keys rather than
simply creating them. In addition, there would be a separate key/
domain needed for each custome
But there is a residual problem. Suppose [EMAIL PROTECTED] is a
subscriber to this list and someone spoofs a message from
[EMAIL PROTECTED] to the list. ietf-dkim@mipassoc.org accepts the
message and sends it to isp.com, their Authorized Signing Domain, and it
is signed and sent. Is the signatu
On Aug 22, 2006, at 4:06 PM, Jim Fenton wrote:
Scott Kitterman wrote:
I disagree. What I think we've discovered that there is no
additional complexity for signers or authors. It is, in fact,
simpler for signers.
With the need to choose the appropriate subdomain depending on
which auth
On Aug 22, 2006, at 3:59 PM, Jim Fenton wrote:
Scott Kitterman wrote:
We had been discussing the need to segregated authenticated
traffic (where authorization to use the 2822.From has been
established) from other traffic being signed by use of a
subdomain. This is to avoid issues like
On 2006-08-22 12:56, Hallam-Baker, Phillip wrote:
Third we need to promote the idea that you should not look for the
existence or even the validity of a DKIM header as being as important as
the domain that is claiming responsibility. If you can't correlate the
domain to some form of additional
Scott Kitterman wrote:
On Mon, 21 Aug 2006 14:55:08 -0700 Michael Thomas <[EMAIL PROTECTED]> wrote:
Scott Kitterman wrote:
OTOH, it seems to me that it's been said Ad Nauseum. Where feasible I
agree it's better, but there are operational frictions that will imped
Scott Kitterman wrote:
> On Monday 21 August 2006 01:34, Jim Fenton wrote:
>
>> Scott Kitterman wrote:
>>
>>> Yes, but the fundamental operational problem will be to pick the correct
>>> domain to sign with. You have to make that decision either way. The
>>> basis upon which you make the
On Aug 22, 2006, at 12:56 PM, Hallam-Baker, Phillip wrote:
Third we need to promote the idea that you should not look for the
existence or even the validity of a DKIM header as being as
important as the domain that is claiming responsibility. If you
can't correlate the domain to some form
On Tuesday 22 August 2006 15:56, Hallam-Baker, Phillip wrote:
> ... we need to promote the idea that you should not look for the
> existence or even the validity of a DKIM header as being as important as
> the domain that is claiming responsibility. If you can't correlate the
> domain to some form
I have been looking
through some of the responses from the spamming community to SPF. I conclude
that the real problem here is that people using naive Bayesian filtering don't
have a clue.
The problem with the
Bayesisan approach is that it is very vulnerable to counter-programming by
spa
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
A DKIM base compatible option?
When subdomains or other domains are used to sign the message, a
significant utility is lost. This utility allows the 2822.From
address to be assured on a per message basis independent of a policy
assertion. To overcome this limitation, adopting the r= param
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
Paul Hoffman wrote:
>> I'm not quite sure, what "||" means. I assume it means
>> concatenation of the two strings. Is that right?
> Yes. That is standard terminology in security documents.
It's also the string concatenation operator in REXX. In a
security related memo I've seen { } (curly brac
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.
>> Scott Kitterman wrote:
>>
>> OTOH, it seems to me that it's been said Ad Nauseum. Where
>> feasible I agree it's better, but there are operational frictions
>> that will impede this approach in some cases.
> Michael Thomas wrote:
> What I believe that we've discovered is that this isn't nea
26 matches
Mail list logo
