docs: log the unverified x-arf Report-Type value

Every other field in the machine-readable part was checked against RFC 5965
itself. This one follows the design document's worked example and no primary
x-arf source was reachable to confirm it, so it is recorded rather than left
as an assumption in the code.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Xj1ayFRSUQ2u7cwb3S4axE

1 files changed, 25 insertions, 0 deletions

diff --git a/docs/BACKLOG.md b/docs/BACKLOG.md
index 60405c0..780cbf5 100644
--- a/docs/BACKLOG.md
+++ b/docs/BACKLOG.md
@@ -8,6 +8,7 @@ number and gains a status rather than being renumbered.
 | 1 | Skip boilerplate namespace URLs | XS | open |
 | 2 | An IDN indicator resolves to no contact | S | open |
 | 3 | Expose kept cases so qtmaildir can tag spam | ? | open, unsized |
+| 4 | `Report-Type: phishing` is unverified against x-arf | XS | open |
 
 ## 1. Skip boilerplate namespace URLs
 
@@ -109,3 +110,27 @@ him concretely, since that phrase is doing all the work in the note, and
 whether he wants a judgement or only the facts, for instance a subcommand that
 answers "this IP appears in three kept cases" and leaves the tagging decision
 to qtmaildir. The second is much more in keeping with the rest of the tool.
+
+## 4. `Report-Type: phishing` is unverified against x-arf
+
+**Observed.** `report.feedback_fields()` emits `Report-Type: phishing` in the
+machine-readable part. Every other field there was verified against RFC 5965
+itself; this one was not, because no primary source for x-arf's own field
+semantics could be reached while building it. The abusix README documents only
+the v3 to v4 deprecation and does not define the field.
+
+**Cause.** Not a defect found in the code. The value follows the worked
+example in `docs/specs/2026-09-09-report.md`, so it is internally consistent,
+and the hybrid envelope means a strict RFC 5965 parser ignores the field
+either way (the RFC requires implementors ignore fields they do not support).
+The exposure is limited to x-arf tooling reading a field name or value that
+does not exist in the version it implements.
+
+**Approach.** Find a primary source for x-arf v4 field names, confirm or
+correct the value, and record what it was checked against. If x-arf turns out
+to name the field differently, the fix is one string and one test.
+
+**Constraints.** Low urgency: nothing here is a leak, and the failure mode is
+a field an x-arf parser skips rather than acts on wrongly. Worth doing before
+the first real report is filed, so a desk running x-arf tooling gets what it
+expects.