Received header parsing not RFC compliant #335
Description
The Received: (qmail 47739 invoked by uid 1001); 29 Jan 2022 20:18:48 -0000 headers generated by qmail (and without loss of generality, Postfix) are not malformed, and instead contain RFC-compliant comments, per RFC 5322 appendix A.5.
In a qmail system, the previous header represents qmail-queue getting the message via local injection. Analyzing a message containing one of these headers with your app claims a hop where the receiving host is uid 1001).
Per RFC 5322 section 3.6.7, the grammar for the Received: header is
received = "Received:" *received-token ";" date-time CRLF
received-token = word / angle-addr / addr-spec / domain
The header generated by qmail at this stage is not operating in an SMTP environment (it could be delivering a message from a local user to a local user, no SMTP involved!), and so this header is well-formed, valid, and consists of 0 received-tokens, an informational (human readable comment), followed by the required semicolon, date-time, and line separator.
In point of fact, it is Microsoft Exchange that generates headers that are problematic for an RFC-compliant implementation — both via and with are specified in RFC 5321 (page 60) as grammar productions that bottom out in Atom, meaning a compliant implementation should parse the with Microsoft SMTP Server in the following header as {with: "Microsoft"} followed by two unregistered clauses; similarly, via Frontend Transport parses as {via: "Frontend"}, followed by a lone Transport unregistered clause. This runs against the SMTP servers SHOULD NOT use unregistered names notes for all of the Via, With, and Additional-Registered-Clauses grammar productions.
Received: from BN8NAM04FT063.eop-NAM04.prod.protection.outlook.com
(2603:10b6:404:10a:cafe::70) by BN6PR13CA0013.outlook.office365.com
(2603:10b6:404:10a::23) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4951.8 via Frontend
Transport; Sat, 29 Jan 2022 20:18:51 +0000