- Original Message -
From: "Michael Thomas" <[EMAIL PROTECTED]>
> I'm sorry, just saying that the protocol is for "transport time" is not
> going to help developers, and is likely to lead to the
> inconsistencies and incompatibility that you are trying to get
> rid of. x= leaves it a
On Apr 7, 2006, at 1:53 PM, Stephen Farrell wrote:
So a signature expiry failure doesn't mean message rejection, same
as if the signature check failed because the message was mangled.
The bane of DSNs are minimized when MTAs follow consistent rule-sets,
as SMTP is a store and forward proto
Paul Hoffman wrote:
At 1:18 PM -0700 4/7/06, Michael Thomas wrote:
Paul Hoffman wrote:
At 12:01 PM -0700 4/7/06, Michael Thomas wrote:
The alternative is to just put normative guidance in the document
to the effect
that x= MUST be greater than t=+2weeks, and less than t=+2 months
or somet
On Apr 7, 2006, at 1:53 PM, Stephen Farrell wrote:
Douglas Otis wrote:
If an MTA is forwarding messages, and these forwarding agents are
known, then bad actors sending messages to forwarded accounts may
be delighted to find their messages are subsequently rejected due
to an expired signat
At 1:18 PM -0700 4/7/06, Michael Thomas wrote:
Paul Hoffman wrote:
At 12:01 PM -0700 4/7/06, Michael Thomas wrote:
The alternative is to just put normative guidance in the document
to the effect
that x= MUST be greater than t=+2weeks, and less than t=+2 months
or something,
and that it SHOU
Doug,
Douglas Otis wrote:
If an MTA is forwarding messages, and these forwarding agents
are known, then bad actors sending messages to forwarded accounts may be
delighted to find their messages are subsequently rejected due to an
expired signature by some down stream MTA. : (
Is that right?
On Apr 7, 2006, at 12:52 PM, Paul Hoffman wrote:
At 12:01 PM -0700 4/7/06, Michael Thomas wrote:
Paul Hoffman wrote:
If what the WG wants is signatures whose life is the time of
transit, we should say that in the protocol definition, not
optionally in each message.
The alternative is to
Paul Hoffman wrote:
At 12:01 PM -0700 4/7/06, Michael Thomas wrote:
The alternative is to just put normative guidance in the document to
the effect
that x= MUST be greater than t=+2weeks, and less than t=+2 months or
something,
and that it SHOULD be set to t=+4 weeks.
That is an alternati
At 12:01 PM -0700 4/7/06, Michael Thomas wrote:
Paul Hoffman wrote:
If what the WG wants is signatures whose life is the time of
transit, we should say that in the protocol definition, not
optionally in each message.
The alternative is to just put normative guidance in the document to
the ef
On Fri, 7 Apr 2006, Michael Thomas wrote:
The alternative is to just put normative guidance in the document to the
effect that x= MUST be greater than t=+2weeks, and less than t=+2 months
or something, and that it SHOULD be set to t=+4 weeks.
I guess I worry a little about codifying an _exac
Paul Hoffman wrote:
The signer has measured the transit time to location A, and it is
always less than ten seconds. The signing system sets x= to a day to
be safe. Location A's SMTP server, becomes unavailable due to a
backhoe incident. The outgoing mail sits on the signer's system for a
day
DKIM is not designed to support persistent signatures. This does not mean
that we will not end up creating any under any cirscumstances.
I don't think that the x= has any effect from a legal standpoint. Courts
currently regard an ASCII signature at the bottom of a message as rebuttable
proof of cr
On Apr 7, 2006, at 8:20 AM, Michael Thomas wrote:
Stephen Farrell wrote:
Yes, but this was a non-goal. We've said all along that it could
be done in an MUA, but not that it was generally a good idea to
put in an MUA since DKIM is intended to have a transport lifetime
relevance.
True. M
At 8:33 AM -0700 4/7/06, Dave Crocker wrote:
DKIM is about signatures, not transit.
Having a parameter in an RFC2822 header field attempt to specify
something relevant to RFC2821 transit does not make sense and, at
best, won't have any effect on transit.
Fully agree.
At 5:27 PM -0700 4/6/06, Michael Thomas wrote:
DKIM is intended to have a transport duration lifetime, eg about
2 weeks.
Yep.
It is not intended to be used for archival purposes or
anything else like that.
Yep.
So what is the value to giving the signer a tool that can change
either of tho
[EMAIL PROTECTED] wrote:
I would put the date of my next key change in there if I was going to
put anything.
Fair enough. Presumably plus a bit extra so your last signature also
verifies.
Others?
S.
___
NOTE WELL: This list operates according to
I would put the date of my next key change in there if I was going to
put anything.
Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
[EMAIL PROTECTED]
___
NOTE WELL: This list operates according to
http://mipass
Stephen Farrell wrote:
Michael Thomas wrote:
You could, but the semantic is more of a "I don't want this
to be in transit after X".
I kind of like that description actually.
DKIM is about signatures, not transit.
Having a parameter in an RFC2822 header field attempt to specify somet
Michael Thomas wrote:
You could, but the semantic is more of a "I don't want this
to be in transit after X".
I kind of like that description actually.
And it makes me wonder if the MUST NOT accept is a good idea since
I'm worried that MTA admins won't know what to put there and will
all
Stephen Farrell wrote:
> Were we to ask verifiers to
interpret "x=" as guidance, and not as a way in which it MUST
fail a signature, then its optional inclusion may well help some
layer above DKIM.
I've struggled with that too... for DKIM purposes, it really does
fail to "verify", but so do
Michael Thomas wrote:
Stephen Farrell wrote:
Paul Hoffman wrote:
Note that the informative note only says what x= is not. Leaving x=
in can also lead to silly states.
What states might those be?
I was also wondering about that. I guess that "x=" is a way to make
it crystal clear that t
Stephen Farrell wrote:
Paul Hoffman wrote:
Note that the informative note only says what x= is not. Leaving x=
in can also lead to silly states.
What states might those be?
I was also wondering about that. I guess that "x=" is a way to make
it crystal clear that this signature is (probabl
22 matches
Mail list logo
