Frank Ellermann wrote:
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.
Yes, I know that.
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.
And this I'm pretty sure leads us down a rathole we don't want
to go. It's just fine for MUA's to do the verification, but their
expectations shouldn't be what drives the standard, IMO. For
one, lots of MDA's torture messages into unverifiable messes, so
keeping expectations low is probably wise. For the same reason,
MUA's in general shouldn't be making any rash decisions about
signatures in the hear and now since regardless of x=, the sender
may also retire (= withdraw from DNS) a key in which case the
MUA would have no means of verifying it.
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.
Or just not say anything as Dave mentions. This is an easy one
to hedge against the future in any case. If it turns out we're wrong,
we haven't made an irreversable decision.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://dkim.org/ietf-list-rules.html