UI Error hardfail for named strings SPFResult

[RobSlgm]

For the past few days, I've been encountering a recurring error for the email domain redacted.com within the UI popup on http://127.0.0.1/admin/#domains/redacted.com/dmarc:

Error: result[0].Records[0].AuthResults.SPF[0].Result: unknown value hardfail for named strings SPFResult

The overview http://127.0.0.1/admin/#dmarc/reports lists for redacted.com DMARC "quarantine"/"reject": 0/1, DKIM "fail": 1, SPF "fail" 3

Investigation:

• I've compared configurations with other functioning email domains on the same mox server and with historical configurations for redacted.com.
• The only identifiable difference is a recent DMARC report received from one counterparty with whom no prior communication has occurred.
• At first glance, the exported DMARC report (from the webmail interface) appears to have no syntax errors. It refers to a unknown IP address (which is exptected)
• mox in version v0.0.10 is used

Possible Cause:

• It's unclear whether the received DMARC report is directly causing the error. I don't know any other way to check the underlying functionality.
• Could the source code be making an unintended assumption about the relationship between DMARC reports and SPF lookups?

[mjl-]

The error message is coming from the typescript code that verifies the fields in the report against the types. "hardfail" is not a valid SPF result. If a remote server sends it, the Go code will accept it (that's how these types work in Go), but the typescript code will fail on it.

I think it's not helpful for the Go code to reject the report too. It isn't very harmful, and other valid values could be defined in future RFC's. It's better to make sure the typescript code doesn't fail on these values. Right now, all frontend code is strictly typechecking all incoming data from mox api's. Making an exception isn't great. I'll investigate if we can simply represent the SPFResult type (and similarly for dkim and dmarc results) as strings instead of a typescript enum.

[mjl-]

@RobSlgm the commit just now rewrites the not-quite-Go-enums into untyped strings so the runtime-type-checking code of the typescript api doesn't try to enforce valid enum values. the same applied to tls reports. i think i got all the not-quite-enums in the dmarc & tls reports.

[RobSlgm]

Fixed in v0.0.12