You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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
The text was updated successfully, but these errors were encountered:
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 thereceiving host
isuid 1001)
.Per RFC 5322 section 3.6.7, the grammar for the Received: header is
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-token
s, 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
andwith
are specified in RFC 5321 (page 60) as grammar productions that bottom out inAtom
, meaning a compliant implementation should parse thewith 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 loneTransport
unregistered clause. This runs against theSMTP servers SHOULD NOT use unregistered names
notes for all of theVia
,With
, andAdditional-Registered-Clauses
grammar productions.The text was updated successfully, but these errors were encountered: