I also expected to offer added value to our customers who are more exclusive in their communications. A vendor when signing up a new user or customer, if have a DKIM mandate in their Vendor/User communications and may want to quickly verify what level of DKIM support the user's email domain has. When DKIM is peppered with terms like security and "domain responsibility," sending out DKIM mail to a user base they know might fail puts the organization at risk.
K= provides value for software vendors to offer advanced managed mail features to their DKIM operators. --- HLS Murray S. Kucherawy wrote: >> Without this feature, people may soon find their inbox flooded by >> bogus messages indicating the use of new algorithm, that could have >> been mitigated extensively by having the key feature. >> > > As opposed to what? What would you expect a verifier or assessor to do if > the hash used to sign was not in the key's approved hash list? Wouldn't it > get delivered anyway, but perhaps with a slightly different annotation? > > I don't see any value here other than disabling verification using a > known-compromised hash algorithm. But even that wouldn't inhibit delivery, > only change annotation. > > _______________________________________________ > 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
