Wietse Venema wrote:
By themselves, nothing is wrong with third-party (i.e. 2822.From
domain != d= domain) signatures. The problem is the mistaken belief
that signatures make statements about 2822.From addresses.
...
I favor first-party signatures mainly because they avoid reputation
cross-talk: when an ISP uses the same shared signing domain for
multiple author domains, bad actors can negatively affect the email
reputation of innocent author domains.
We are not going to fix mistaken beliefs with technical constraints.
If d= != rfc2822.From domain, then assessment software needs to treat the d=
value on the assumption that -- big surprise -- the message was not signed by
the author's ADMD. That does not make the d= value useless, merely different.
It is fine for an assessment engine to treat a case of both names being equal
(or directly related) in a special way, whatever that way might be. However
this, really, is a decision to be made by the assessment engine.
If an ISP has mail from different sources that it might sign, it needs to
determine whether it wants a single reputation based on the aggregate mail from
all those sources, or whether it wants finer-grained reputation information
maintained. The easiest way to do that is to use sub-domains that it signs for,
or to do no signing (or sign only for the domains it has vetted, or...).
Most of the various discussions about SSP choices seem to believe that this
realm is easily defined and controlled. It ain't. In particular, statements
about how practices information is going to get used are seriously lacking in
basis. We need to refrain from adding features that have speculative benefit,
because it is expensive and risky to add features.
Once again: We need to define a basic publishing mechanism and the smallest
number of practices to publish, for which there is very strong and very broad
agreement. Anything that is controversial needs to be deferred.
I believe we have strong and broad agreement that it would be useful to publish
"I sign everything". This is of basic benefit, when receiving a message that is
not signed.
I believe we do not have strong or broad agreement on any other features.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html