Message-ID is not recognized

[maurizio-emmex]

In my fdm.conf I have:
$key = "%[message_id]"
match string $key to "" action "store_to_spam" continue

The Message-ID in the email:

Date: Fri, 17 Feb 2023 15:38:11 +0000
Message-ID:
PA4PR04MB78241F668550B8CC3C149147ADA19@PA4PR04MB7824.eurprd04.prod.outlook.com
Accept-Language: it-IT, en-US

is not recognized by %[message_id], $key is "" .

Thank you for your work.

Maurizio

[thimc]

I had a similar issue where I specifically tried to set a variable to the Message-ID.
I think that I've finally found the issue, looks like it's some sort of a syntax error which fdm -n can't recognize but I am not entirely sure.

Please try:

$key = "%[message_id]"
match string "${key}" to "" action "store_to_spam" continue

Also, keep in mind that even if this rule matches, the mail evaluation loop will not stop because you have a continue at the end of that rule set.

[maurizio-emmex]

Thanks for the suggestion, I'm trying it.

[bbbrumley]

I had a similar issue; after some basic testing, my gut tells me it's somehow related to multi-line Message-ID headers.

I worked around it by using a different key -- total hack.

[bbbrumley]

YAAAY I finally made some progress on this

Apparently some MSFT Exchange configurations are sending messages like

Message-ID:  <AM0P194MB0529D547C84D9BFD0D49A785B4DFA@AM0P194MB0529.EURP194.PROD.OUTLOOK.COM>

note the TWO (2) spaces after the colon.

In those cases, the following fdm rule is matching:

match string "%[message_id]" to "" ..

I am not familiar enough with RFC822 and RFC2822 to say what is right in this case. Either way, the reality is, MSFT Exchange is doing that 🤷

This is my shameless hack:

match "^Message-ID:[ \t]*<(.*)>" action tag "message_id" value "%1" continue

[bbbrumley]

I can also confirm the same fdm rule matches on MSFT Exchange messages I've seen arrive that look like

Message-ID:
 <AS8PR07MB7927CF301E4A4F4E194E5946815CA@AS8PR07MB7927.eurprd07.prod.outlook.com>

(so, multi-line.)

[nickalcock]

Any number of spaces after the colon is absolutely permitted: really fdm should be collapsing them to one space. (White space there is not required: for consistency, really fdm should provide a way to canonicalize it somehow. This is doubly important because of the bewildering variety and complexity of types of whitespace permitted in RFC*822. Even procmail provides more tools than fdm in this area, though procmail's implementation -- the various TO_ etc regexes -- is deeply disgusting and absolutely must not be emulated :) )