I support adoption of dkim-atps as an experimental RFC. It would have
been clearer to use the term Author-Domain rather than Author. Clearly,
it is not the Author offering Authorization.
-Doug
___
Ietf mailing list
Ietf@ietf.org
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Douglas Otis
Sent: Thursday, December 08, 2011 10:12 AM
To: ietf@ietf.org
Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers) to Experimental RFC
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John
Levine
Sent: Sunday, December 04, 2011 1:28 PM
To: ietf@ietf.org
Cc: dcroc...@bbiw.net
Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers
On 12/4/2011 1:27 PM, John Levine wrote:
ADSP already dictates use of the From: domain.
The the nature ADSP's use of the From: domain is fundamentally different from
ATPS' use.
Broadly, we can distinguish:
Name extraction:determining what name is being claimed
Name
On 11/30/2011 1:03 PM, Barry Leiba wrote:
In plain English, this reads as an update of ADSP but this draft does not
update RFC 5617.
It does not. There's no reason that anyone implementing ADSP need pay
attention to this.*IF* you implement this, it might change your
behaviour with respect
ATPS essentially modifies name extraction, by making it a two-step process.
The first step is the usual one, with d=, for use with validation, but the
second one takes the domain in the From: field and makes it the output string
to the assessment process.
If you're referring to the second
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John
R. Levine
Sent: Monday, December 05, 2011 5:25 PM
To: Dave Crocker
Cc: ietf@ietf.org
Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers
Section 5 is for those people that do DKIM without ADSP but care about
giving author domain signatures preferential treatment.
Since there's nothing in the DKIM spec that suggests that's a correct
way to use DKIM, I'd be fairly unhappy about any language that
purports to legitimize it.
Here in
-Original Message-
From: Rolf E. Sonneveld [mailto:r.e.sonnev...@sonnection.nl]
Sent: Saturday, December 03, 2011 4:49 AM
To: Murray S. Kucherawy
Cc: ietf@ietf.org
Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers) to Experimental RFC
-Original Message-
From: Dave CROCKER [mailto:d...@dcrocker.net]
Sent: Saturday, December 03, 2011 10:38 AM
To: Murray S. Kucherawy
Cc: ietf@ietf.org
Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers) to Experimental RFC
So I suggest
With ATPS, the requirement is to replace the d= string with the domain name
from
the From: field. That replacement value is then passed to the assessment
module.
In other words, DKIM provides it's own identifier to be used for assessment,
whereas ATPS dictates use of the From: field domain
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Dave CROCKER
Sent: Friday, December 02, 2011 3:59 PM
To: SM
Cc: ietf@ietf.org
Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers) to Experimental
Hi, Murray,
having read the draft I support its publication as experimental RFC. One
suggestion: under 'Security Considerations' add a reference to what is
said about DNSSEC in RFC6376 par. 8.5. In my opinion, the same
consideration applies for this ATPS document.
/rolf
On 12/3/11 9:32 AM,
On 12/3/2011 12:32 AM, Murray S. Kucherawy wrote:
Does a signature by this on behalf of signer mean something different
from a regular DKIM signature? It appears the current text means the
answer to be yes.
Correct, inasmuch as there are some people in the community who think author
domain
Dave CROCKER wrote:
On 11/30/2011 8:09 PM, Murray S. Kucherawy wrote:
As the draft says, the point is to make the idea available and see if
it sticks to anyone or anything. If the bulk senders (or receivers)
do decide they collectively want this, there's something for them to
try and report
On 11/30/2011 12:34 PM, SM wrote:
Readers should be familiar with the material and terminology
discussed in [MAIL] and [EMAIL-ARCH].
The references to RFC 5598 and RFC 5322 should be normative.
Arguably, they already are: the text says should and that's a normative term
in the document...
On 1 December 2011 05:09, Murray S. Kucherawy m...@cloudmark.com wrote:
so long as experimental-status drafts are allowed to make IANA
registrations. (I thought they weren't, which is why it is the
way it is right now.)
Depends on the registry, some registrations need standards track,
others
At 11:38 30-11-2011, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'DKIM Authorized Third-Party Signers'
draft-kucherawy-dkim-atps-11.txt as an Experimental RFC
The IESG plans to make a decision in the next few weeks, and
Readers should be familiar with the material and terminology
discussed in [MAIL] and [EMAIL-ARCH].
The references to RFC 5598 and RFC 5322 should be normative.
I agree; I missed that in my shepherd review. So sorry.
A Verifier implementing both ADSP and ATPS SHOULD treat a message for
Hi Barry,
At 13:03 30-11-2011, Barry Leiba wrote:
It does not. There's no reason that anyone implementing ADSP need pay
attention to this. *IF* you implement this, it might change your
behaviour with respect to ADSP, but information about that is
contained here. There's no reason for this to
-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers) to Experimental RFC
In Section 3:
An Author participates in this protocol if it wishes to announce that
a message from it (in the RFC5322.From sense) should be considered
authentic as long as it bears a signature from any
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of
Murray S. Kucherawy
Sent: Wednesday, November 30, 2011 2:21 PM
To: ietf@ietf.org
Subject: RE: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers
I'm one of the authors of RFC 5617, which this document would update
if it moved into the standards track. It doesn't seem very useful to
me, but it also seems mostly harmless so there's no reason not to
publish it as experimental.
This strikes me a hack that appeals primarily to bulk mail
-Original Message-
From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of John
Levine
Sent: Wednesday, November 30, 2011 6:04 PM
To: ietf@ietf.org
Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers) to Experimental RFC
On 11/30/2011 8:09 PM, Murray S. Kucherawy wrote:
As the draft says, the point is to make the idea available and see if it sticks
to anyone or anything. If the bulk senders (or receivers) do decide they
collectively want this, there's something for them to try and report back.
if one
-Original Message-
From: Dave CROCKER [mailto:d...@dcrocker.net]
Sent: Wednesday, November 30, 2011 11:16 PM
To: Murray S. Kucherawy
Cc: ietf@ietf.org
Subject: Re: Last Call: draft-kucherawy-dkim-atps-11.txt (DKIM Authorized
Third-Party Signers) to Experimental RFC
I'd be fine
26 matches
Mail list logo
