[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: The cost of choices
- To: "ietf-mailsig" <ietf-mailsig@xxxxxxx>
- Subject: Re: The cost of choices
- From: "Arvel Hathcock" <arvel@xxxxxxxx>
- Date: Wed, 27 Jul 2005 15:51:52 -0500
- Dkim-signature: a=rsa-sha1; c=nowsp; d=altn.com; s=c3po; l=1828; t=1122497720; x=1123102520; firstname.lastname@example.org; q=dns; h=DomainKey-Signature: Received:Message-ID:From:To:References:Subject:Date:Organization: MIME-Version:Content-Type:Content-Transfer-Encoding:Reply-To; b=TblkWpjkh6LtmA6LDBfFIZzjDkARH+mf4YwL32ZgaSrImBPvyWLJ3G1xqZkOBW7z H4jELJt2qPZaAmQw561/yPi7LpTrlCQ3+p5esEEG358q7wRu9lPa7uYgO5shoLxK 5Ee6805yGFLuCWR7GglkZ/o9SnNMUPtIJGF7m2s7Z2c=
- Domainkey-signature: a=rsa-sha1; s=c3po; d=altn.com; c=nofws; q=dns; h=from:message-id; b=fm9jry8oP64nzuRT5Mc8yH/zHf01XOmIAqRAIsVvNqm6epWvv74fpW+6Q2b3FF+g4cAISgHyYEEVFP+vQuTeHnmbCmJpM+2YB3bLnTh8F+YRq/dIgI2SZzQee3+h8kJbhgoJInKm7k4N5v72QD/DH1hzHe/qdO6KcsXJPJZvDsg=;
- List-archive: <http://www.imc.org/ietf-mailsig/mail-archive/>
- List-id: <ietf-mailsig.imc.org>
- List-unsubscribe: <mailto:email@example.com?body=unsubscribe>
- Organization: Alt-N Technologies
- References: <> <>
- Reply-to: arvel@xxxxxxxx
- Sender: owner-ietf-mailsig@xxxxxxxxxxxx
Makes perfect sense to me. In my opinion, Hector is right - this is the way
to go and this is what the existing DKIM draft already allows.
----- Original Message -----
From: "Hector Santos" <hsantos@xxxxxxxxxxxxxx>
To: "Dave Crocker" <dcrocker@xxxxxxxx>;
<domainkeys-feedbackbase02@xxxxxxxxx>; "IETF MASS WG" <ietf-mailsig@xxxxxxx>
Sent: Wednesday, July 27, 2005 12:10 AM
Subject: Re: The cost of choices
----- Original Message -----
From: "Dave Crocker" <dhc@xxxxxxxxxxxx>
To: <domainkeys-feedbackbase02@xxxxxxxxx>; "IETF MASS WG"
Sent: Wednesday, July 27, 2005 12:06 AM
Subject: The cost of choices
Whether operators choose to use all the features is a separate matter,
Mark notes, there is a problem if the initiating side uses it but the
receiving side does not.
I brought this up in my response to your poll. Did you read it?
The suggestion is that q=DNS query be the standard fallback and that a
extended SIGNER using some other "q=" query method must also publish the
DKIM policy in DNS as well to support the fallback on non-compliant
query DKIM receivers.
This allows us to concentrate on using DNS.
But we should model the specification based on a standard Input/Output
DKIM_POLICY = DKIM_DNS(selector, domain)
Extended DKIM query protocols:
DKIM_POLICY = DKIM_XKMS(selector, domain)
DKIM_POLICY = DKIM_SOAP(selector, domain)
DKIM_POLICY = DKIM_other(selector, domain)
These extender protocols would be out of scope for the core DKIM
specification, but I think the core should include a simple modeling thus
allowing future query methods to be invented.
So I think, the only thing that needs to be clearly defined is what are
minimum CORE expected input and output variables. I think this is
established. So it just a matter of modeling it in the specs.
A separate DKIM-QUERY ID draft can be written that follows the DKIM-core
Make sense? If not, please let me know what I am not seeing here that
this more difficult than it is?