(Thanks to you, John, Hector, and the others for helping. I think I
understand a little better where you are going, now. I'll let you know
when I know everything and have solved all the world's problems.)
Eliot Lear wrote:
Sandy Wills wrote:
I love analogies, so let's extend this one a bit.
* 2. If the query for the public key fails to respond, the verifier
*SHOULD defer acceptance of this email. Verifiers SHOULD track
* continuous errors and SHOULD eventually accept the message
*object after a number of tries.
If the query for the public key fails to respo
- Original Message -
From: <[EMAIL PROTECTED]>
>> 2. If the query for the public key fails to respond, the verifier
>> SHOULD defer acceptance of this email. Verifiers SHOULD track
>> continuous errors and SHOULD eventually accept the message
>> object after a number of trie
The Milk Carton Analogy was good, but there is a slight difference when it
comes to (DKIM) mail.
The problem with the milk analogy is that the expiration date is a shelf
life concept. To the store, it is the date it must remove the cartons from
the store shelves. To the consumer, who brought it da
>If the query for the public key fails to respond, the verifier SHOULD defer
>acceptance of this email. Verifiers MAY track continuous errors and determine
>the message has a broken signature.
I don't know what "acceptance" means here. Since we're talking about
verification, I suspect "verificati
Given that DKIM has reached a stage where new specifications are no
longer backwards compatible, I think it has become imperative that a
clear identification of signature formats be adopted. Not having a
stable specification is one thing, but promoting confusion by not
properly identifying in
Hi,
While it may be sensible to start using v= now, or when an RFC
issues, or in some other way, I don't think that having a
different v= for each Internet-draft is a good idea really.
Perhaps you are expecting too much of each version of the I-D
in terms of stability/compatibility. These are w
While it may be sensible to start using v= now, or when an RFC
issues, or in some other way, I don't think that having a
different v= for each Internet-draft is a good idea really.
Perhaps you are expecting too much of each version of the I-D
in terms of stability/compatibility. These are workin
Mircea Purdea wrote:
While it may be sensible to start using v= now, or when an RFC
issues, or in some other way, I don't think that having a
different v= for each Internet-draft is a good idea really.
Perhaps you are expecting too much of each version of the I-D
in terms of stability/compati
Stephen Farrell wrote:
I guess my concern would be that it might encourage people not to
update their code to be RFC compliant.
That might be so, but on the other hand, I think that before commiting
to a RFC, live testing of draft implementations SHOULD be done, and
currently, given the v=
Mircea Purdea wrote:
Stephen Farrell wrote:
I guess my concern would be that it might encourage people not to
update their code to be RFC compliant.
That might be so, but on the other hand, I think that before commiting
to a RFC, live testing of draft implementations SHOULD be done, and
11 matches
Mail list logo
