+1. Thank god someone had the nerve to speak up.
Beside the fact it is being used in conflictive ways, I just love it
when a "new word" gets into ones vocabulary that they are compelled to
use it even when not 100% understood to the layman. Just consider, if
a reader has to take the time to googled it to attempt to understand
its usage in DKIM, then most likely, its the wrong technical term to
use in the first place.
IMO, same is true with the word "Consume" makes one feel that
something is being "eaten up," never to be used again by seen and used
by anything else, i.e. its not passed on. The fact is, it is passed on
to whoever may want to see it and it may be passed on more than once,
therefore it isn't "consumed", it is utilities, processed, etc, but
not "consumed."
In my opinion, as far as I am concern as a potential implementation I
need to know
1) Is I=/D= the same in RFC 4871 or are we trying to say that I=
domains can in fact be DIFFERENCE than whats defined as the
requirement in RFC 4871?
2) Resolve this MUST convey concept. It is conflictive with other
relaxed semantics regarding i= described in the specs.
Keep in mind, IMO, is DKIM is going to succeed, be widely adopted, its
not going to be 100% used the same way across the board. Others may
not want to convey anything about backend passive, transparent DKIM
verification methods to users - this is especially true if the sender
is anonymous, there is no WHITE/REPUTATION info to fall back on.
IMV, this is where POLICY concept plays an important role. It is the
policy that is going to help receivers to dissemination the OBVIOUS
FRAUD from the rest, and folks, if we can not dissemination the
OBVIOUS FRAUD, then I ask, where is the payoff for the high value
exclusive domains who may want to use DKIM in 1 to 1 communications
with users.
I hate to rehash anything, but we need to keep the eye on the prize
here - FRAUD DETECTION.
--
Sincerely
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
Jim Fenton wrote:
I have been hearing quite a bit of discussion and confusion on this list
about the word "opaque". Since the stated intent of an erratum or
revision to the specification is to remove a point of confusion, it's
important not to introduce a new one.
I strongly suggest that we not use the word "opaque" in 4871bis, or in
an erratum if things go that way. Instead, state exactly what the
significance of various fields is, e.g., "the local-part of the i= value
MAY have no significance to other than the signer, and may not be
depended upon by the verifier in the absence of other information
provided by the signer".
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html