Hi Murray.
RFC6376 and even RFC4871, but now it's apparently happening
I'd be interested to hear about the actual scenarios. Are the targeted
users somehow given an indication that the email verifies and it's
from a credible domain and yet it contains a malevolent payload?
This sounds like some sort of quarantine system which only looks at
verification status.
It's too bad formal communication to the MUA was eliminated in
DKIM. The original hope was that after a decade or so, MUAs would have
evolved to participate and make some rendering indication in such
situations. After all, an unknown-to-the-MUA to:/cc: recipient or
domain in a verified email is highly actionable.
Anyway, based on your draft I presume the desire is still to retain
the binary verification status as a strong dispositional attribute
that is handled by anything *but* the MUA?
In the section that discusses the impact on forwarded and list email
you might want to highlight that the proposal could further reduce
email to a point-to-point protocol. In which case an alternative
long-term strategy might be simply to insist on strong SPF checks
rather than signatures. Or do SPF checks not help the scenario you're
addressing here?
Mark.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html