Michael Thomas wrote:
[base-00 3.5 x=]
Douglas Otis wrote:
The MUST in the draft may be a bit harsh.
Yes, s/MUST/SHOULD/ makes sense, e.g. if a MUA behind IMAP
I dunno, what does X.509 say about expired certificates?
I'm a little bit worried about the law of unintended
consequences here. Right now we have exactly two states:
fully verifies, or doesn't and is equivalent to no signature
at all. What is the ramification of allowing for a third
state?
SHOULD NOT is most definitely not "do what you like". One case
of "x NOT RECOMMENDED" vs. "SHOULD do y" where y is a part of x
just made it to the IAB for review.
Violating a SHOULD NOT still needs a good excuse, and wrt DKIM
the typical excuse "old implementations couldn't know this" is
not applicable (or maybe it is if an older DK draft didn't have
this MUST, I'm too lazy to verify this).
But checking DKIM in MUAs is possible, and what they find in
their POP3 or IMAP inbox could be rather old. Not always, but
sometimes. For a STRONG signing policy "invalid signature" is
almost the same as "reject - delete - report - it's a phish".
If the only problem is the expiration, and if that has a simple
reason like "user is now back from vacation reading his mails",
then the full anti-phishing-flak is not necessarily what (s)he
wants. That could be a third case for STRONG signing policies.
Are there exploits which become available? What about over
all reliability/stability when some receivers interpret the
SHOULD differently?
It's also possible to say "MUST NOT, but" if it's clear what
the "but" is about.
Bye, Frank
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html