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
