ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] RFC4871bis - whether to drop -- k: Key type

2009-06-02 23:21:48
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

<Prev in Thread] Current Thread [Next in Thread>