mb.kludge: emit FLAGS kludge without colon separator

FTS-4001 §4 specifies `^AFLAGS flag_string`, space-separated, no
colon.  fmail's jamfun.c:321 ("FLAGS ") and ftr.c:113
("\1FLAGS DIR\r") both emit the same form; HPT's ctrl-buffer
parser accepts it verbatim without a colon.

BuildKludgePrefix was previously emitting `^AFLAGS: DIR` with a
colon, which caused consumer parsers (NR's ParseKludges, HPT's
getFlags, fmail's getKludge) to miss the FLAGS kludge entirely.
In NR that manifested as FLAGS DIR / IMM routing being silently
ignored -- the message would fall into normal routing instead of
direct/immediate delivery, and the outbound pkt's destination
node ended up unset (from the route resolver rather than the
message's actual destination).

One-line fix: drop the colon, keep the rest of the kludge
emission unchanged.  MSGID: / REPLY: / PID: / CHRS: / TZUTC:
keep their colons per their respective specs (FTS-0009, FRL-1028,
FSC-0054, FSC-0093).
This commit is contained in:
2026-04-19 15:47:19 -07:00
parent 95b7a529ef
commit cd2cc900a7

View File

@@ -282,7 +282,11 @@ begin
AppendKludge(Result, 'REPLY:', attrs.Get('replyid', ''), True);
AppendKludge(Result, 'PID:', attrs.Get('pid', ''), True);
AppendKludge(Result, 'TID:', attrs.Get('tid', ''), True);
AppendKludge(Result, 'FLAGS:', attrs.Get('flags', ''), True);
{ FTS-4001: FLAGS kludge uses a space separator, NOT a colon.
(fmail's jamfun.c:321 and ftr.c:113 both emit "\1FLAGS <flags>\r"
with no colon. FTS-4001 §4 Kludge Line Form matches.) Bare
name + single space so AppendKludge's ' ' join lands correctly. }
AppendKludge(Result, 'FLAGS', attrs.Get('flags', ''), True);
AppendKludge(Result, 'CHRS:', attrs.Get('chrs', ''), True);
AppendKludge(Result, 'TZUTC:', attrs.Get('tzutc', ''), True);
AppendKludgeLines(Result, 'Via', attrs.Get('via', ''), True);