On Sep 16, 2010, at 5:58 AM, wrote:
> we can discuss it for the very reason you pointed out, people want to
> use/sell 3rd party signing, so lets discuss a policy and write it up. I know
> my company wants one and I suspect a few others might as well. I know that
> some folks fought very har
Murray S. Kucherawy wrote:
> Neither class of extension is a statement by us that extensive
> field operations has yielded this as a flaw in the protocol or
> a required extension. Absent a statement by this other open
> source project to that effect, I would just assume it's another
> knob p
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org]
> On Behalf Of Scott Kitterman
> Sent: Thursday, September 16, 2010 8:08 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] RFC4871 5322.From Binding - Pr
t; On Thu, 16 Sep 2010, MH Michael Hammer (5304) wrote:
>
>>
>>
>>> -Original Message-
>>> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
>>> boun...@mipassoc.org] On Behalf Of Scott Kitterman
>>> Sent: Thursday, September 16, 2010
On Thursday, September 16, 2010 03:23:15 am Hector Santos wrote:
> Scott Kitterman wrote:
> >> My Technical recommendation.
> >>
> >> 1) For 4871bis, we should consider relaxing the 5322.From
> >>
> >>binding requirement from a MUST to a SHOULD. This will help
> >>justify its new words o
John R. Levine wrote:
> Since there's no such thing as a "3rd party signing policy" in DKIM or
> ADSP, I don't understand why we're even discussing this.
John,
Because the lack of one has created other conflicts and
mis-interpretations.
Cited another way:
1) dkim=all
is being read as a
oc.org [mailto:ietf-dkim-
boun...@mipassoc.org] On Behalf Of Scott Kitterman
Sent: Thursday, September 16, 2010 12:57 AM
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] RFC4871 5322.From Binding - Proposal to relax
it.
Since anyone can generate a DKIM signature with a signing domain they
contr
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of Scott Kitterman
> Sent: Thursday, September 16, 2010 12:57 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] RFC4871 5322.From Binding - Pr
Scott Kitterman wrote:
>> My Technical recommendation.
>>
>> 1) For 4871bis, we should consider relaxing the 5322.From
>>binding requirement from a MUST to a SHOULD. This will help
>>justify its new words of "separating the signer domain from
>>the author domain." There is no separat
] RFC4871 5322.From Binding - Proposal to relax it.
[...]
- 1.
Scott K
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
"Hector Santos" wrote:
>Based on existing open source DKIM API code from a large MTA, they
>must of come across signatures that did not include the 5322.From
>signature binding requirement of RFC 4871 because it contains an
>option to not enforce 5322.From hash binding in the DKIM.H header.
Ian Eiloart wrote:
>> However, this can be potentially be a high overhead/management for
>> large companies with many employees using different list servers.
>
> Too true, and I don't think that this kind of delegation would be any
> kind of a solution for the ADSP=discardable/MLM problem. It mi
>
> Perhaps and this has been proposed in the 2006 DSAP I-D, Doug's has
> similar TPA (Third Party Authorization) and I recently tried to rewake
> the DSAP idea for ADSP as an extension called ASL (Allowable Signer List).
>
> ADSP allows extension, so a DNS record like
>
> DKIM=all; x-asl=mi
Ian Eiloart wrote:
>
>
>> 2) We should consider a 5617bis (ADSPbis) to codify its semantics
>> regarding Author Domain only signature policies to include a:
>>
>> Always sign by *anyone* Policy.
>>
>> Currently 5617 (ADSP) defines the two policies:
>>
>>
>> all All mail
> 2) We should consider a 5617bis (ADSPbis) to codify its semantics
> regarding Author Domain only signature policies to include a:
>
> Always sign by *anyone* Policy.
>
> Currently 5617 (ADSP) defines the two policies:
>
>
> all All mail from the domain is signed with
Based on existing open source DKIM API code from a large MTA, they
must of come across signatures that did not include the 5322.From
signature binding requirement of RFC 4871 because it contains an
option to not enforce 5322.From hash binding in the DKIM.H header.
In other words, if the DKIM-Si
16 matches
Mail list logo
