Apologies for top posting if it offends anyone.
-1 I OPPOSE this proposal for the following reasons.
The D in DKIM refers to Domain, not user. If it cannot be used to
strongly protect the purported originating domain based on that domains
stated assertions and policy, then DKIM-SSP is of limited value.
Without requiring a check (not saying what action the receiver must
take) of the From address, what we are saying is that bad guy signature
on evil nasty email is just as worthwhile of a signature as that of the
owner of the domain in the From address.
Anyone care to argue that a signature from
randomrotating.randomrotating_evil.ru is a sufficient and trustworthy
signature for an email purporting to be from this list even though
mipassic.org isn't DKIM signing? BTW, isn't ironic that an organization
that is pushing DKIM isn't signing even with t=y?
Requiring a check of From does not dictate the decision the receiver
(MTA,MUA, person at keyboard, whatever) chooses to do with the results.
The folks in favor of removing the text are concerned about what
receivers will do based on such a check. Shouldn't that choice be left
to the individual?
This is almost like arguing that a sign saying "DANGER, Shallow Water -
Do not Dive" should be removed because some people might want to ignore
the sign and dive in headfirst anyways.
Feel free to ignore the from DKIM signature in your personal
implementation but please don't weaken the opportunity for the owner of
a domain to make an assertion through DKIM-SSP and expect that people
following the standard have at least checked their disclaimer. If a
domain owner chooses not to make an assertion or chooses to make a
weaker assertion, that is their perogative.
Mike
Summary of proposal:
All text that causes SSP to be applied to an already-signed message
needs to be removed.
Folks,
I've reviewed the thread that took place on this topic. Here
are summary
statistics:
Total postings in thread: 46
Number of different people posting: 14
Apparent REJECT of proposal: 4
Apparent ACCEPT of proposal: 5
I would like to ask folks with an opinion about this proposal
to post an explicit note stating support or opposition. Some
of the existing posts were about substantive issues in the
proposal, but did not clearly indicate support or opposition.
Given that this issue goes to the core of a significant
fraction of the current specification's functionality and
given that there is at least an implied requirement for the
functionality in the SSP requirements RFC, I'll ask folks to
do both a +1/-1 *and* to explain their reasons.
I also do not find a record in the archive of working group
agreement to add the features in question. So an assumption
that the features should be retained unless there is a rough
consensus *against* is problematic. Citing the SSP
requirements RFC is comforting, but questionable, absent any
history of group discussion and clear rough consensus about the matter.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html