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. -MSK
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
