Doug,
That's better, since it uses requirements language, but unfortunately
still not understandable (for me at any rate).
Douglas Otis wrote:
Rephrased:
The policy should be able to indicate:
- What signing domains are authoritative for the First Party Address.
(The policy specifies whi
On Aug 10, 2006, at 10:33 AM, Stephen Farrell wrote:
Douglas Otis wrote:
Actually "Signing Complete" should be as explicit assertion,
whereas "Not Signing Complete" should be a default ...
That's a nice example of a design discussion. We're on requirements
now.
Rephrased:
The policy sho
Doug,
Douglas Otis wrote:
Actually "Signing Complete" should be as explicit assertion, whereas
"Not Signing Complete" should be a default ...
That's a nice example of a design discussion. We're on requirements
now.
Stephen.
___
NOTE WELL: This list
On Aug 9, 2006, at 7:51 PM, Scott Kitterman wrote:
On Wednesday 09 August 2006 22:30, Tony Hansen wrote:
Stephen Farrell wrote:
Michael Thomas wrote:
Tony Hansen wrote:
add RFC2822.Sender
I'm not the chair, but I've seen considerably less consensus
about anything other than rfc2822.from
On Wed, Aug 09, 2006 at 10:30:21PM -0400, Tony Hansen allegedly wrote:
> Stephen Farrell wrote:
> >
> > Michael Thomas wrote:
> >> Tony Hansen wrote:
> >>> add RFC2822.Sender
> >>>
> >> I'm not the chair, but I've seen considerably less consensus about
> >> anything other than rfc2822.from. I'm
ware, Inc.
http://www.santronics.com
- Original Message -
From: "Tony Hansen" <[EMAIL PROTECTED]>
To: "DKIM List"
Sent: Wednesday, August 09, 2006 10:30 PM
Subject: Re: [ietf-dkim] RFC2822.Sender
> Stephen Farrell wrote:
> >
> > Michael Thomas
On Wednesday 09 August 2006 22:30, Tony Hansen wrote:
> Stephen Farrell wrote:
> > Michael Thomas wrote:
> >> Tony Hansen wrote:
> >>> add RFC2822.Sender
> >>
> >> I'm not the chair, but I've seen considerably less consensus about
> >> anything other than rfc2822.from. I'm frankly not sure I unders
That this thread is being discussed brings up a requirement that policy
record syntax should be capable of supporting multiple identities.
A subquestion of that is if policy record identity should or should
not be part of the query selection process (i.e. _from._policy if DNS).
That BTW brings
Stephen Farrell wrote:
>
> Michael Thomas wrote:
>> Tony Hansen wrote:
>>> add RFC2822.Sender
>>>
>> I'm not the chair, but I've seen considerably less consensus about
>> anything other than rfc2822.from. I'm frankly not sure I understand
>> it very well.
>
> I know I don't understand it!
>
>
Michael Thomas wrote:
Tony Hansen wrote:
add RFC2822.Sender
I'm not the chair, but I've seen considerably less consensus about
anything other
than rfc2822.from. I'm frankly not sure I understand it very well.
I know I don't understand it!
Maybe a more detailed use-case would help? (Tony?
Tony Hansen wrote:
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,
11 matches
Mail list logo
