On Thursday 10 August 2006 10:26, Michael Thomas wrote:
> Scott Kitterman wrote:
> >Mike,
> >
> >Are you making a change to the spec to change impossible to a more
> > realistic standard?
>
> How about:
> >Discovery mechanism MUST NOT overload semantics of existing
> > DNS resource records where
Scott Kitterman wrote:
On Wednesday 09 August 2006 16:42, Michael Thomas wrote:
Paul Hoffman wrote:
At 1:02 PM -0400 8/9/06, Scott Kitterman wrote:
***
*** 474,480
expectation is "few".]
3. Discovery mechanism MUST NOT overload semantics of exi
On Wednesday 09 August 2006 16:42, Michael Thomas wrote:
> Paul Hoffman wrote:
> > At 1:02 PM -0400 8/9/06, Scott Kitterman wrote:
> >> ***
> >> *** 474,480
> >> expectation is "few".]
> >>
> >> 3. Discovery mechanism MUST NOT overload semantics of existing DNS
>
Tony Hansen wrote:
>> !! arrival of a piece of unsigned, damaged in transit mail, or if
>> a RFC2822.From sender policy exists which specifies authoritative
>> domain(s), a mail signed by an entity other than described in the sender
>> policy.
>
> add RFC2822.Sender
Let's try an exercise:
Wh
Paul Hoffman wrote:
At 1:02 PM -0400 8/9/06, Scott Kitterman wrote:
***
*** 474,480
expectation is "few".]
3. Discovery mechanism MUST NOT overload semantics of existing DNS
!resource records where name space collisions are possible.
5.2. Transpo
Scott Kitterman wrote:
> *** 508,514
> 5.3. Practice and Expectation Requirements
>
> In this section, a Practice is defined as a true statement according
> !to the domain holder of its intended externally viewable behavior.
> An Expectation combines with a Practice to convey
Damon wrote:
>> --- 350,357
>> previous scenario. A receiver, on the other hand, may be able to
>> take advantage of the knowledge the domain's practice of signing all
>> mail in order to use it to bias filters against the unexpected
>> !arrival of a piece of unsigned, damaged
Scott Kitterman wrote:
> I went through the draft and marked it up. I'll break these up into
> individual messages for each comment. I'll start with a context diff of the
> draft and proposed changes and then give a discussion of why...
>
> *** 321,328
> unsigned outweights the risk
At 1:02 PM -0400 8/9/06, Scott Kitterman wrote:
***
*** 474,480
expectation is "few".]
3. Discovery mechanism MUST NOT overload semantics of existing DNS
!resource records where name space collisions are possible.
5.2. Transport requirements
--- 47
Done.
Scott Kitterman wrote:
*** 508,514
5.3. Practice and Expectation Requirements
In this section, a Practice is defined as a true statement according
!to the domain holder of its intended externally viewable behavior.
An Expectation combines with a Practice to convey what
--- 350,357
previous scenario. A receiver, on the other hand, may be able to
take advantage of the knowledge the domain's practice of signing all
mail in order to use it to bias filters against the unexpected
!arrival of a piece of unsigned, damaged in transit mail, or mail
!
On Wednesday 09 August 2006 13:26, Damon wrote:
> > --- 542,556
> > for signing its messages to a non-related domain in such a way
> > that it does not require active participation by the non-related
> > domain. That is, the published information MUST have a way to
--- 542,556
for signing its messages to a non-related domain in such a way
that it does not require active participation by the non-related
domain. That is, the published information MUST have a way to
! specify the domains that are allowed to sign on its b
> 2. The operation of the signing library that signs with a
> different key
> depending on the sender.
>
> As far as how hard #2 is, does anyone's implementation
> support this currently
> (I'm asking, I don't know)?
Ours does. Admins can select keys based on username, domain, LDAP group,
> But the SSP client is not the naive user - its a DKIM-verifier. Does
> that change the argument? E.g. in terms of requiring consideration of
> other "identities" or "domains" found in the message? (Just asking.)
If an SSP client could consider other identities/domains found within
the message
Hi Arvel,
Arvel Hathcock wrote:
I'll take a crack at this one.
> I suggest that we need to explain the basis for that assumption and
> that the explanation needs to provide the empirical basis for
> believing that it is the right choice.
The "From:" header value is the identity the naive u
On Fri, 28 Jul 2006, Jim Fenton wrote:
william(at)elan.net wrote:
On Fri, 28 Jul 2006, Stephen Farrell wrote:
A similar question to the previous one.
Current proposals involve searching for SSP stuff based on
the domain part of an unsigned message's RFC2822.From element.
Are there any oth
I'll take a crack at this one.
> I suggest that we need to explain the basis for that assumption and
> that the explanation needs to provide the empirical basis for
> believing that it is the right choice.
The "From:" header value is the identity the naive user assumes to be
the originator due
Dave Crocker wrote:
Jim Fenton wrote:
Stephen Farrell wrote:
I'll throw out a few generic requirements:
Jim, these all look pretty reasonable, but they are all about the mechanism
rather than being about sender signing practices, per se.
True, but we do need to get both discovery
Dave Crocker wrote:
Stephen Farrell wrote:
Folks,
We all (or almost all) seem to be assuming that the DNS is the
place to put SSP stuff.
I just wanted to raise the question to see if that's a requirement
or just a near-accidental part of the current design proposals.
Let me suggest
- Original Message -
From: "Douglas Otis" <[EMAIL PROTECTED]>
> It makes little sense to indicate "sometimes expected." How
> would that be useful?
First, lets keep in mind that "sometimes" or the neutral policy is currently
the DKIM-BASE default behavior. It is also the default policy
On Sat, 2006-07-29 at 23:26 -0400, Hector Santos wrote:
> - Definition should expose the following DKIM signer attributes:
>
> - List of allowable 3PS signers
The term third-party signer should not be used to avoid confusion with
designated signing domains and non-designated domains. The lis
Dave Crocker wrote:
> Jim Fenton wrote:
>
>> Stephen Farrell wrote:
>> I'll throw out a few generic requirements:
>>
>
> Jim, these all look pretty reasonable, but they are all about the mechanism
> rather than being about sender signing practices, per se.
>
Sure. I was responding to St
- Original Message -
From: "Dave Crocker" <[EMAIL PROTECTED]>
To: "Jim Fenton" <[EMAIL PROTECTED]>
>> Jim Fenton wrote:
>> I'll throw out a few generic requirements:
>
> Jim, these all look pretty reasonable, but they are all about
> the mechanism rather than being about sender signing p
Jim Fenton wrote:
> Stephen Farrell wrote:
> I'll throw out a few generic requirements:
Jim, these all look pretty reasonable, but they are all about the mechanism
rather than being about sender signing practices, per se.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_
Stephen Farrell wrote:
>
> Folks,
>
> We all (or almost all) seem to be assuming that the DNS is the
> place to put SSP stuff.
>
> I just wanted to raise the question to see if that's a requirement
> or just a near-accidental part of the current design proposals.
>
> So is using the DNS in fact nec
On Jul 28, 2006, at 3:35 PM, Dave Crocker wrote:
Mark Delany wrote:
How do you then decide which policies to check? Does this mean
that you need to check every address corresponding to a From,
Sender, Resent-from, Resent-sender, 2821 envelope-from, and List-
id, ...
Right. The "Which
Mark Delany wrote:
>> How do you then decide which policies to check? Does this mean that you
>> need to check every address corresponding to a From, Sender,
>> Resent-from, Resent-sender, 2821 envelope-from, and List-id, ...
> Right. The "Which I" problem.
Indeed. I suspect the challenge, her
On Fri, Jul 28, 2006 at 02:46:32PM -0700, Jim Fenton allegedly wrote:
> > You need to be open to other possibilities and make system easily
> > extendeable to other identities. My preference would be to encode
> > identity in the lookup path, so instead of doing lookup on _policy
> > it would actua
william(at)elan.net wrote:
>
> On Fri, 28 Jul 2006, Stephen Farrell wrote:
>
>> A similar question to the previous one.
>>
>> Current proposals involve searching for SSP stuff based on
>> the domain part of an unsigned message's RFC2822.From element.
>>
>> Are there any other requirements there or
> Sent: Friday, July 28, 2006 4:22 PM
> To: 'John Levine'; ietf-dkim@mipassoc.org
> Subject: RE: [ietf-dkim] Requirements on where/how SSP stuff
> is published...
>
>
> > [mailto:[EMAIL PROTECTED] On Behalf Of John Levine
>
> > I'm hoping that we
> [mailto:[EMAIL PROTECTED] On Behalf Of John Levine
> I'm hoping that we can constrain the SSP info to a modest
> number of bits, so DNS is is. If SSP bloats up to the point
> where it doesn't fit in 512, then it's http.
I think that if we follow the approach that the policy record specifies
Stephen Farrell wrote:
>
> Folks,
>
> We all (or almost all) seem to be assuming that the DNS is the
> place to put SSP stuff.
>
> I just wanted to raise the question to see if that's a requirement
> or just a near-accidental part of the current design proposals.
Let me suggest that it will b
Stephen Farrell wrote:
>
> A similar question to the previous one.
>
> Current proposals involve searching for SSP stuff based on
> the domain part of an unsigned message's RFC2822.From element.
Yes, that is clearly a core assumption. I suggest that we need to explain the
basis for that assum
>So is using the DNS in fact necessary? If it is, we may need text
>that explicitly says why at some stage.
I think we're all presuming that if a receipient uses SSP, it'll be
doing a query per message to fetch the SSP info for that message. If
we expect the query to be small enough that the quer
[EMAIL PROTECTED] wrote:
> According to my DNS admin
> "Why are you putting all that crap in DNS? The MTA can do that!! Or use
> a web page!"
The 'stuff' is to be queried, so the mechanism that must be used is a query
service.
1. An MTA does not provide a query service, so I do not understand
> We all (or almost all) seem to be assuming that the DNS is the
> place to put SSP stuff.
>
> I just wanted to raise the question to see if that's a requirement
> or just a near-accidental part of the current design proposals.
I suppose that since the rest of DKIM is in DNS it seems logical to p
- Original Message -
From: "Jon Callas" <[EMAIL PROTECTED]>
> What do you mean by an unauthorized signing, Hector?
Basically, the responsible domain property owner (Original Address) mail
policy expectations were violated in some form.
Maybe he did not expect any signing or signing by ot
On Fri, 28 Jul 2006, Stephen Farrell wrote:
Folks,
We all (or almost all) seem to be assuming that the DNS is the
place to put SSP stuff.
DNS is not the right place to put public keys either - its been
shown here many that it makes DNS systems vulnerable to attack when
you put such large rec
On Fri, 28 Jul 2006, Stephen Farrell wrote:
A similar question to the previous one.
Current proposals involve searching for SSP stuff based on
the domain part of an unsigned message's RFC2822.From element.
Are there any other requirements there or is that the only
basis on which we need to be
According to my DNS admin
"Why are you putting all that crap in DNS? The MTA can do that!! Or use
a web page!"
Just passing along a reaction I got.
Thanks,
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
[EMAIL PROTECTED]
-Original Message-
From:
In short, it implies DKIM-BASE is based on a "Good Citizen" model
where
every "i is dotted" and every "t is crossed." But it lacks no
security
provisions for protecting against the most obvious of all DKIM
failures - in
this case as to relates the above statement - unauthorized signings.
- Original Message -
From: "Douglas Otis" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, July 27, 2006 11:28 PM
Subject: Re: [ietf-dkim] requirements
> The draft uses the term domain without referencing which domain
On Jul 27, 2006, at 6:02 PM, Hector Santos wrote:
Is it possible to view this from a VERIFIER security standpoint
based on what is to expected in DKIM-BASE and all possible
signatures regardless what is deemed useful or not?
After, the verifier is going to be the ultimate "controller" of
On Jul 27, 2006, at 5:20 PM, Jim Fenton wrote:
Douglas Otis wrote:
Regardless of the OA, spam will reflect poorly upon the signing
domain. Reports of abuse and expectations of who will resolve an
abuse issue always falls to the signing domain. There will not
be any "spreading" of res
- Original Message -
From: "Jim Fenton" <[EMAIL PROTECTED]>
To: "Douglas Otis" <[EMAIL PROTECTED]>
>> Regardless of the OA, spam will reflect poorly upon the signing
>> domain. Reports of abuse and expectations of who will resolve an
>> abuse issue always falls to the signing domain. T
Douglas Otis wrote:
>
> On Jul 27, 2006, at 3:40 PM, Jim Fenton wrote:
>> I have a somewhat less tangible concern, too. If example.com
>> publishes an SSP record saying that some mail provider is an
>> authorized sender, and there is an abuse problem, will example.com
>> feel the same responsibili
Jim Fenton wrote:
Michael Thomas wrote:
This could possibly be dealt with in a couple of ways:
1) make all of the customer's zones change (bletch).
2) customer delegates the _domainkey subdomain to the provider so they
can manage it on the customer's behalf (probably only scales to one
pr
On Jul 27, 2006, at 3:40 PM, Jim Fenton wrote:
3) have the ability for the policy statement say that a provider
(s) legitimately signs for that domain.
The potential scaling problem with multiple providers in (3) is one
of my main concerns with this approach. I have heard of
enterprise
Michael Thomas wrote:
> This could possibly be dealt with in a couple of ways:
>
> 1) make all of the customer's zones change (bletch).
> 2) customer delegates the _domainkey subdomain to the provider so they
>can manage it on the customer's behalf (probably only scales to one
> provider
>t
> 2. The operation of the signing library that signs with a different
> key depending on the sender.
>
> As far as how hard #2 is, does anyone's implementation support this
> currently (I'm asking, I don't know)?
Yes, MDaemon does. We found this to be a necessity so I created the
ability to as
On Jul 26, 2006, at 5:44 PM, Michael Thomas wrote:
3) have the ability for the policy statement say that a provider(s)
legitimately
signs for that domain.
+1
Ways 1 and 2 should be fairly transparent from a policy standpoint,
but these methods likely represent an ongoing expense. Wa
Scott Kitterman wrote:
On Wednesday 26 July 2006 16:36, Michael Thomas wrote:
Scott Kitterman wrote:
On Wednesday 26 July 2006 14:14, Michael Thomas wrote:
This is a really good instance of what the base level requirements are.
On the one hand we can say that the requirement is
006 5:42 PM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] requirements
On Wednesday 26 July 2006 16:36, Michael Thomas wrote:
> Scott Kitterman wrote:
> >On Wednesday 26 July 2006 14:14, Michael Thomas wrote:
> >>This is a really good instance of what the base level requireme
On Wednesday 26 July 2006 16:36, Michael Thomas wrote:
> Scott Kitterman wrote:
> >On Wednesday 26 July 2006 14:14, Michael Thomas wrote:
> >>This is a really good instance of what the base level requirements are.
> >>On the one hand we can say that the requirement is that an ISP signing
> >>on beh
Scott Kitterman wrote:
On Wednesday 26 July 2006 14:14, Michael Thomas wrote:
This is a really good instance of what the base level requirements are.
On the one hand we can say that the requirement is that an ISP signing
on behalf of a customer actually sign on behalf of the customer. That
i
On Jul 26, 2006, at 11:14 AM, Michael Thomas wrote:
This is a really good instance of what the base level requirements
are.
On the one hand we can say that the requirement is that an ISP signing
on behalf of a customer actually sign on behalf of the customer. That
is, the d=customer.com rathe
On Wednesday 26 July 2006 14:14, Michael Thomas wrote:
> This is a really good instance of what the base level requirements are.
> On the one hand we can say that the requirement is that an ISP signing
> on behalf of a customer actually sign on behalf of the customer. That
> is, the d=customer.com
58 matches
Mail list logo
