On 2/18/23 8:41 PM, Murray S. Kucherawy wrote:
On Sat, Feb 18, 2023 at 8:27 PM Michael Thomas <m...@mtcc.com> wrote:
Beyond this SHOULD, I think we need to consider whether the
caller needs to be told specifically when a failure occurs
for this reason. Right now an implementation might return
just a PERMFAIL without noting that it's because of "x="
versus the signature failing for some other reason. Should
the caller be given this extra detail to enhance the
decision tree, or will this just complicate things?
Why would it permfail? Does it permfail email without a
signature too?
Absent p=reject, there is nothing wrong with unsigned email.
I'm using the language of the DKIM RFC, so "PERMFAIL" here refers
to evaluation of the signature, not of the message.
But DKIM doesn't return status to anybody. That's completely
internal to the verifier. At most they might want to create an
A-R, but that isn't required and it's definitely not sent back to
the sender.
I think we're talking about different layers here. Otherwise, DKIM has
to return status someplace, otherwise why do the evaluation? That
status might be in the form of an A-R header field, or a recommended
final action, or a log entry, or whatever that operator wants.
The RFC just talks about returning PERFMAIL when the evaluation fails
for one reason or another. It's abstract, of course; the implementer
is free to decide what that actually means in each case. In the
implementation I did, the library receives all the details and returns
a status (with its own detail) about each signature, and the caller is
free to do what it wants with that information.
From the standards standpoint a signature either verifies or not
(modulo DNS glitches), but from a verifier's standpoint signatures and
the covered parts of the message contains a wealth of other information
that a filter module could use as inputs to make its decisions. That may
or may not be distilled into a single status, but that is completely up
to the receiver so PERMFAIL is just conceptual, not real. x= in
particular is rather vague about what a receiver should make of an
expired signature, and completely silent on what a low value might
imply. I've always thought of it as "I don't take responsibility for
this anymore" from the sender's standpoint, but others are free to have
a different opinion and that's fine (in particular, the HER EMAILS crowd
certainly wouldn't care).
Mike
_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
