On Apr 18, 2006, at 6:56 PM, Stephen Farrell wrote:
Douglas Otis wrote:
If 7 days provides for the SMTP transport, and people in Sweden
and France want to verify messages following their 5 week
vacation, then this would require a minimum of 42 days of key
availability. The suggestion for
What exactly are we looking for here? What's the goal?
- Average User Mail Reception Time?
- Average POP3/IMAP Polling Time?
---
Hector
- Original Message -
From: "Lyndon Nerenberg" <[EMAIL PROTECTED]>
To: "Stephen Farrell" <[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, April 18, 2006 11:
On Apr 18, 2006, at 7:50 PM, Stephen Farrell wrote:
That'd be great. Esp. if you could co-ordinate with a few others
first that see similar distributions.
Sure. I'm swamped with other stuff until next week, though.
If there are others on the list who can contribute datasets to the
cause,
Lyndon Nerenberg wrote:
Real, significant, usable, numbers would be welcome. I've not seen
any.
I'll see what I can pull from the mail logs at work. We push a couple
of million messages a day, and exercise the AOL and Yahoo mail throttles
on an ongoing basis.
That'd be great. Esp. if y
Real, significant, usable, numbers would be welcome. I've not seen
any.
I'll see what I can pull from the mail logs at work. We push a
couple of million messages a day, and exercise the AOL and Yahoo mail
throttles on an ongoing basis.
--lyndon
_
Lyndon Nerenberg wrote:
On Apr 18, 2006, at 6:56 PM, Stephen Farrell wrote:
If you knew the distribution of transit times based on some
reasonable sample, then I'd listen. Presumably there's a bell
curve in there and we could argue about how many std. devs. to
ask signers to take into account
On Apr 18, 2006, at 6:56 PM, Stephen Farrell wrote:
If you knew the distribution of transit times based on some
reasonable sample, then I'd listen. Presumably there's a bell
curve in there and we could argue about how many std. devs. to
ask signers to take into account. Anything less soundly bas
Doug,
Douglas Otis wrote:
If 7 days provides for the SMTP transport, and people in Sweden and
France want to verify messages following their 5 week vacation, then
this would require a minimum of 42 days of key availability. The
suggestion for 45 days provided an additional 3 days to assure
On Apr 18, 2006, at 5:36 PM, Stephen Farrell wrote:
Doug,
Your response is non-responsive :-(
Douglas Otis wrote:
On Apr 18, 2006, at 4:10 PM, Stephen Farrell wrote:
Douglas Otis wrote:
The duration of the signature should cover the "expected"
distribution of transit times for a message
Doug,
Your response is non-responsive :-(
Douglas Otis wrote:
On Apr 18, 2006, at 4:10 PM, Stephen Farrell wrote:
Douglas Otis wrote:
The duration of the signature should cover the "expected"
distribution of transit times for a message from the originator to
recipient.
Sure. Can you g
On Apr 18, 2006, at 4:10 PM, Stephen Farrell wrote:
Douglas Otis wrote:
The duration of the signature should cover the "expected"
distribution of transit times for a message from the originator to
recipient.
Sure. Can you get us the peer reviewed stats so we can remove those
quotes fr
Paul Hoffman wrote:
The meaning of x= is completely clear in the -00 and -01 drafts.
However, many people on the list, including some of the document
authors, have wide disagreement about what x= is supposed to do. Some
people say that it is supposed to be when a particular signature is no
lo
Doug,
Douglas Otis wrote:
The duration of the signature should cover the "expected" distribution
of transit times for a message from the originator to recipient.
Sure. Can you get us the peer reviewed stats so we can
remove those quotes from "expected"?
I certainly don't have 'em, and in the
On Apr 18, 2006, at 2:25 PM, Stephen Farrell wrote:
Douglas Otis wrote:
On Apr 18, 2006, at 1:35 PM, Stephen Farrell wrote:
There's been a good bit of MUA related discussion about
long time periods.
Our charter says explicitly that the following is out of
scope:
* Signatures that are inten
At 5:28 PM -0400 4/18/06, <[EMAIL PROTECTED]> wrote:
Proposed
x=Expiration date (plain-text; RECOMMENDED, default is no
expiration). The format is the same as in the "t=" tag,
represented as an absolute date, not as a time delta from the
signing timestamp. Signatures MU
--On April 18, 2006 5:45:46 PM -0400 Tony Hansen <[EMAIL PROTECTED]> wrote:
... I think this
clarification by itself is reason enough to get a -02 out as
quickly as possible.
Agreed. I'm going to try to fold in the various comments I've
received and then get -02 out.
I'm at a conference
Stephen Farrell wrote:
There's been a good bit of MUA related discussion about
long time periods.
Our charter says explicitly that the following is out of
scope:
* Signatures that are intended to make long-term assertions beyond the
expected transit time of a message from originator to reci
Hi Murray,
Murray S. Kucherawy wrote:
If indeed discussion of Authentication-Results: or similar mechanisms is
outside of the scope of this working group (or even if it isn't), I'd
like to remind everyone that there's a mailing list dedicated to that
very discussion. It is:
[EMAIL PROT
Which is just the opposite of what I expected. I'm willing to change my
implementation to use this interpretation instead, but I think this
clarification by itself is reason enough to get a -02 out as quickly as
possible.
Tony Hansen
[EMAIL PROTECTED]
Murray S. Kucherawy wrote:
>
If indeed discussion of Authentication-Results: or similar mechanisms is outside
of the scope of this working group (or even if it isn't), I'd like to remind
everyone that there's a mailing list dedicated to that very discussion. It is:
[EMAIL PROTECTED]
Bastardizing the administrativ
Paul Hoffman wrote:
At 9:58 PM +0100 4/18/06, Stephen Farrell wrote:
So there is no clear consensus to delete x=, therefore
we go with the status quo.
Right.
Could I ask that someone try propose text for the draft
to clarify the meaning of x=, bearing in mind all of
the list discussion?
Current
x= Signature Expiration (plain-text; RECOMMENDED, default is no
expiration). The format is the same as in the "t=" tag,
represented as an absolute date, not as a time delta from the
signing timestamp. Signatures MUST NOT be considered valid if
the current tim
At 9:58 PM +0100 4/18/06, Stephen Farrell wrote:
So there is no clear consensus to delete x=, therefore
we go with the status quo.
Right.
Could I ask that someone try propose text for the draft
to clarify the meaning of x=, bearing in mind all of
the list discussion?
The meaning of x= is co
Doug,
Douglas Otis wrote:
On Apr 18, 2006, at 1:35 PM, Stephen Farrell wrote:
There's been a good bit of MUA related discussion about
long time periods.
Our charter says explicitly that the following is out of
scope:
* Signatures that are intended to make long-term assertions beyond the
On Apr 18, 2006, at 1:35 PM, Stephen Farrell wrote:
There's been a good bit of MUA related discussion about
long time periods.
Our charter says explicitly that the following is out of
scope:
* Signatures that are intended to make long-term assertions beyond the
expected transit time of a m
Tony Hansen wrote:
This paragraph should be ignored completely. It should have been removed.
Should the CRLF be there or not between the canonicalized headers and
the DKIM-Signature? I expect it to be there, but this paragraph is the
only place that says it should be there.
No, it should not
On Apr 18, 2006, at 1:03 PM, Scott Kitterman wrote:
On 04/18/2006 15:43, Douglas Otis wrote:
Or the primary goal of offering protection for all obtainable use
cases?
I guess we disagree about MUA level verification being obtainable.
I actually have some e-mail accounts I only check abo
Results are in:
Keep (8)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Remove (9)
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAI
Murray S. Kucherawy wrote:
> There are a few spots in the newer draft which are ambiguous. I chatted
> with Eric yesterday and he concurs; it's stuff he meant to change but
> they fell through the cracks prior to submission. They'll be fixed in
> the next one.
>
> My implementation follows the i
There's been a good bit of MUA related discussion about
long time periods.
Our charter says explicitly that the following is out of
scope:
* Signatures that are intended to make long-term assertions beyond the
expected transit time of a message from originator to recipient,
which is normall
There are a few spots in the newer draft which are ambiguous. I chatted with
Eric yesterday and he concurs; it's stuff he meant to change but they fell
through the cracks prior to submission. They'll be fixed in the next one.
My implementation follows the intended algorithm as we discussed it
On 04/18/2006 15:43, Douglas Otis wrote:
> On Apr 18, 2006, at 11:33 AM, Scott Kitterman wrote:
> > I would not say that we shouldn't include DKIM protection beyond
> > SMTP, but that whatever happens after delivery shouldn't distract
> > us from the primary use case.
>
> Or the primary goal of of
- Original Message -
From: "Steve Atkins" <[EMAIL PROTECTED]>
> Simple, functional and deployed beats complex, over-designed and
> theoretical.
Agree, but I also recognize the school of thought that simplicity promotes
complexity which promotes over-designed functionality when resolving
f
On Apr 18, 2006, at 11:33 AM, Scott Kitterman wrote:
On 04/18/2006 14:18, Douglas Otis wrote:
Depending upon an unsigned "results" header being added to the
message is an unsafe practice.
It is not practical to determine who added the "results" header,
whether the MDA strips/adds all pr
On Apr 18, 2006, at 10:43 AM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
,---
| 2.1 Signers
|...
| The key issue is that a message must be signed before it
| leaves the administrative domain of the signer.
'---
What is intended by this statement? How does this relate to messages
signed
From: "Stephen Farrell" <[EMAIL PROTECTED]>
> Last call for opinions. I'm gonna count 'em up when I
> get home and send results in a few hours.
I prefer KEEP X=
Please note: It is already optional. If people don't want to use it, they
don't have to add it to the signature.
If kept, we need on
On 04/14/2006 12:26, Douglas Otis wrote:
> On Apr 14, 2006, at 5:56 AM, Hector Santos wrote:
> >>> Unless it has help from the backend server, offline mail systems
> >>> will not work very reliably when keys are being changed.
> >>
> >> Should DKIM require services beyond DNS for verification?
> >
On 04/18/2006 14:18, Douglas Otis wrote:
> On Apr 18, 2006, at 10:42 AM, Scott Kitterman wrote:
> > From a protocol design perspective, I think the right answer is to
> > design for the case where the receiving MTA/MDA will check the
> > signature and record a result that, if appropriate, an MUA ca
On Apr 18, 2006, at 10:42 AM, Scott Kitterman wrote:
From a protocol design perspective, I think the right answer is to
design for the case where the receiving MTA/MDA will check the
signature and record a result that, if appropriate, an MUA can use.
Depending upon an unsigned "results" h
step 1) remove it
step 2) decide what we really want
step 3) propose something with those exact semantics
Stephen Farrell wrote:
> Last call for opinions. I'm gonna count 'em up when I
> get home and send results in a few hours.
___
NOTE WELL: This list
On Apr 18, 2006, at 10:32 AM, Hector Santos wrote:
- Original Message -
From: "Steve Atkins" <[EMAIL PROTECTED]>
But it still an optimization concept:
- No need to DNS lookup, regardless of TTL state.
Yes. DNS is cheap, and NXDOMAIN is cached, though. How often, in
practice,
- Original Message -
From: "Steve Atkins" <[EMAIL PROTECTED]>
>>
>> But it still an optimization concept:
>>
>> - No need to DNS lookup, regardless of TTL state.
>
> Yes. DNS is cheap, and NXDOMAIN is cached, though. How often, in
> practice, do you think that even an MUA, let alone
On 04/14/2006 10:36, Hector Santos wrote:
> In section 6.2 "Get The Public Key, we have step #2
>
> | 2. If the query for the public key fails to respond, the verifier
> | SHOULD defer acceptance of this email (normally this will be
> | achieved with a 451/4.7.5 SMTP reply code).
>
>
If a MUA is the signer I would hope it is within its own administrative
domain. I haven't seen one yet that was outside of its own domain.
Thanks,
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
[EMAIL PROTECTED]
-Original Message-
From: [EMAIL PR
,---
| 2.1 Signers
|...
| The key issue is that a message must be signed before it
| leaves the administrative domain of the signer.
'---
What is intended by this statement? How does this relate to messages
signed by an MUA, which is not mentioned as a possible signer? Is
this statement i
Jon Callas wrote:
> The issue, then, is what happens when I have my expiration being
> (e.g.) a month and I decide out of the blue to change keys. The answer
> is that some messages now won't verify, which means they are
> "suspicious" which interacts with SSP and other things to make it so
> that
At 12:29 PM -0400 4/18/06, Hector Santos wrote:
- Original Message -
From: "Paul Hoffman" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, April 18, 2006 11:38 AM
Subject: Re: [ietf-dkim] Expiration Tag (x=) is required to minimize DNS
lookups.
At 2:34 PM + 4/18/06, Mark Delany wrote:
>Th
Last call for opinions. I'm gonna count 'em up when I
get home and send results in a few hours.
Cheers,
S.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On Apr 18, 2006, at 9:29 AM, Hector Santos wrote:
- Original Message -
From: "Paul Hoffman" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, April 18, 2006 11:38 AM
Subject: Re: [ietf-dkim] Expiration Tag (x=) is required to
minimize DNS
lookups.
At 2:34 PM + 4/18/06, Mark Delany wrot
- Original Message -
From: "Paul Hoffman" <[EMAIL PROTECTED]>
To:
Sent: Tuesday, April 18, 2006 11:38 AM
Subject: Re: [ietf-dkim] Expiration Tag (x=) is required to minimize DNS
lookups.
> At 2:34 PM + 4/18/06, Mark Delany wrote:
> >This is surely an edge case that Knuth warns us ab
- Original Message -
From: "Mark Delany" <[EMAIL PROTECTED]>
>>x= is needed to offer a major DKIM verifier optimization to
>>address expiring or revoked keys.
>
> This is surely an edge case that Knuth warns us about.
-10
You got to be kidding me? :-)
Besides, you mean Hoare an
On Apr 17, 2006, at 11:24 PM, Hallam-Baker, Phillip wrote:
Expiry is a reason for bouncing mail??
Which document are you reading there? Expired sig equals unsigned
at worst.
Expired sig plus other factors might lead to bounce, for example. A
transport layer verifier that sees a three
At 2:34 PM + 4/18/06, Mark Delany wrote:
This is surely an edge case that Knuth warns us about.
+1
The current spec has enough language to handle key rollover
gracefully. Further, if a sender wants to minimize DNS lookups, the
DNS TTL is the perfect tool, and is already implemented every
On Tue, Apr 18, 2006 at 06:39:49AM -0400, Hector Santos allegedly wrote:
> Summary:
>
>x= is needed to offer a major DKIM verifier optimization to
>address expiring or revoked keys.
This is surely an edge case that Knuth warns us about.
Mark.
___
Summary:
x= is needed to offer a major DKIM verifier optimization to
address expiring or revoked keys.
Background:
Overall we have this basic key rollover, revocation and removal time model
such as:
DAY T1 : First day mail is signed with KEY1
DAY T2 Last day mail is signed
55 matches
Mail list logo
