Hector Santos wrote:
> - Original Message -
> From: "Jim Fenton" <[EMAIL PROTECTED]>
> To: "Hector Santos" <[EMAIL PROTECTED]>
> Cc:
> Sent: Friday, April 21, 2006 8:56 PM
> Subject: Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error
&g
>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
- 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
Fenton
Cc: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error
- Original Message -
From: "Dave Crocker" <[EMAIL PROTECTED]>
To: "Jim Fenton" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, April 21, 2006 8:51 PM
Subject: Re: [ietf-dki
- Original Message -
From: "Dave Crocker" <[EMAIL PROTECTED]>
To: "Jim Fenton" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, April 21, 2006 8:51 PM
Subject: Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error
> Exactly right. This is a specification concerning t
- Original Message -
From: "Jim Fenton" <[EMAIL PROTECTED]>
To: "Hector Santos" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, April 21, 2006 8:56 PM
Subject: Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error
>>> This points out another problem: if a verif
Hector Santos wrote:
> - Original Message -
> From: "Jim Fenton" <[EMAIL PROTECTED]>
>
>
>> This points out another problem: if a verifier defers verification or
>> acceptance of a given message, it SHOULD maintain enough state so that
>> the message may be accepted after some number o
The longer I think about this, the more I am of the opinion that we
shouldn't talk about 400-ing in the -base specification.
...
> I'd suggest that we just remove the mention of special responses to key
retrieval failures in -base, and put them in the overview document as a
deployment opti
Scott Kitterman wrote:
> On 04/20/2006 18:53, Michael Thomas wrote:
>
>> Scott Kitterman wrote:
>>
>>> On 04/19/2006 23:51, Jim Fenton wrote:
>>>
This points out another problem: if a verifier defers verification or
acceptance of a given message, it SHOULD maintain enough
On Apr 20, 2006, at 5:26 PM, Hector Santos wrote:
Keep in mind that a DSN (AKA Bounce) is only activated in an Accept/
Reject
mode of operation.
With a SMTP level rejection, no DSN is required simply because its
not even
technically possible.
This was about issuing 4xx errors.
-Doug
__
On 04/20/2006 18:53, Michael Thomas wrote:
> Scott Kitterman wrote:
> >On 04/19/2006 23:51, Jim Fenton wrote:
> >>This points out another problem: if a verifier defers verification or
> >>acceptance of a given message, it SHOULD maintain enough state so that
> >>the message may be accepted after s
- Original Message -
From: "Douglas Otis" <[EMAIL PROTECTED]>
To: "Michael Thomas" <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, April 20, 2006 7:46 PM
Subject: Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error
> An apparent server fault of the signer should
On Apr 20, 2006, at 3:53 PM, Michael Thomas wrote:
On 04/19/2006 23:51, Jim Fenton wrote:
This points out another problem: if a verifier defers
verification or
acceptance of a given message, it SHOULD maintain enough state so
that
the message may be accepted after some number of retries
Scott Kitterman wrote:
On 04/19/2006 23:51, Jim Fenton wrote:
This points out another problem: if a verifier defers verification or
acceptance of a given message, it SHOULD maintain enough state so that
the message may be accepted after some number of retries, so that
messages with key re
On 04/20/2006 09:53, Douglas Otis wrote:
> On Thu, 2006-04-20 at 07:53 -0400, Scott Kitterman wrote:
> > WRT your point, I agree. Perhaps we need to add another bit along the
> > lines of, "If an email is deferred based on lack of response to the
> > query for the public key, the verifier SHOULD N
On Thu, 2006-04-20 at 07:53 -0400, Scott Kitterman wrote:
> WRT your point, I agree. Perhaps we need to add another bit along the
> lines of, "If an email is deferred based on lack of response to the
> query for the public key, the verifier SHOULD NOT indefinitely defer
> the message. While messa
On 04/19/2006 23:51, Jim Fenton wrote:
> Scott Kitterman wrote:
> > There is another potential issue with this approach if we get to a
> > dedicated RR type. While not an issue when using TXT, there are
> > resolvers that will fail to respond when queried with an unknown RR type
> > (no I don't k
- Original Message -
From: "Jim Fenton" <[EMAIL PROTECTED]>
> This points out another problem: if a verifier defers verification or
> acceptance of a given message, it SHOULD maintain enough state so that
> the message may be accepted after some number of retries, so that
> messages wit
Scott Kitterman wrote:
> 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 wit
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).
>
>
20 matches
Mail list logo
