Eliot Lear:
The question one has to ask is broader than inputs and outputs. Are
each of the protocol elements described in the specification clear
enough to be understood as to their meaning? If they are not then that
is what needs to be clarified. Regardless, this debate about
On 2/18/09 1:51 PM, Wietse Venema wrote:
If intelligent people cannot agree on what is the result of a
protocol, then there is a problem that needs to be fixed. The
proposed errata address the problem. The alternative does not.
But that where precisely is the disagreement? That is the
Eliot Lear wrote:
On 2/18/09 1:51 PM, Wietse Venema wrote:
If intelligent people cannot agree on what is the result of a
protocol, then there is a problem that needs to be fixed. The
proposed errata address the problem. The alternative does not.
But that where precisely is the
I just had a look and we have a 9am slot on the 25th (Wednesday) now.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
On Feb 18, 2009, at 4:51 AM, Wietse Venema wrote:
Eliot Lear:
The question one has to ask is broader than inputs and outputs.
Are each of the protocol elements described in the specification
clear enough to be understood as to their meaning? If they are not
then that is what needs
Stephen and Barry,
I have a procedural question on how the responses to the consensus call
will be evaluated for options a,b,c,d.
Will it be a+b vs c+d to get a general sense of direction and then
evaluate each option with in an approach or will each option be
evaluated independently (that is,
Disagree. One such use case is noted in the draft, where an domain has
a premium service and a free service, and tags signatures accordingly so
that users of the premium service avail themselves of the better
reputation that service might have.
Right, but that has nothing to do with i=. They'll
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
But i= isn't opaque, not as a whole anyway. It has the syntax of an
email address, and the domain part of that address MUST be the same
as or a subdomain of the d= value.
I think I want to say just a few things about opaque as a term of
The majority of the time, i= will be precisely an email address,
I've been collecting the DKIM signatures on my incoming mail, and
I'm surprised how few of them have i= at all. Ignoring my own
signatures, I see some from Cisco where the i= typically matches
the From address, a couple of spams
Jim,
I think this is at least the second time I've seen you offer this line of
commentary and I still don't understand it. On its surface, your comments seem
to me to be a complete non sequitor with the question at hand.
The best I can guess is that you think that distinguishing payload from
My vote:
(a) The erratum I-D [1] is ready to go. Process it.
If there is indeed a requirement to conform to the concept that a protocol
must specify its payload, I believe this is the right way to go. At
present, a new API implementor has no clear indication of what a minimal
DKIM
At 16:38 18-02-2009, John Levine wrote:
I've been collecting the DKIM signatures on my incoming mail, and
I'm surprised how few of them have i= at all. Ignoring my own
As I mentioned previously, there are some DKIM signers using
i=. Usually, it is when the domain part of the address is a
12 matches
Mail list logo
