I think the current defaults I'm using in the software I maintain go back quite
a ways, to well before the proposed standards were formally published, when it
was unclear what harm would come from a message that was signed but didn't
verify for whatever reason. Defaulting to "accept" could theoretically be
dangerous, but defaulting to "reject" was obviously extreme. Putting the
decision in the hands of the administrators, with a medium default ("tempfail",
which is a delayed "reject", thus giving one time to decide what other action
to take (and is the only other option)), seemed to be the best course of action
at the time.
I agree that a permanent DNS error should result in a delivery with some kind
of annotation, at least in the logs if not on the message, about why
verification failed. That's a good default and that's what I'll be using going
forward.
However, I do plan to leave it as something an administrator can configure.
The idea of temp-failing still has some merit to me, because then a message
that can't verify due to a missing key will typically generate a first DSN
("can't deliver, will keep trying") that might get the sending domain to fix
their published keys before the final DSN gets generated. Of course I'm quite
aware that many end-users won't know what to do with that information, or know
that it's not a final failure, etc.
-MSK
_______________________________________________
dkim-ops mailing list
dkim-ops(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/dkim-ops