Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Received header parsing not RFC compliant #335

Open
twopir opened this issue Jan 30, 2022 · 0 comments
Open

Received header parsing not RFC compliant #335

twopir opened this issue Jan 30, 2022 · 0 comments
Assignees

Comments

@twopir
Copy link

twopir commented Jan 30, 2022

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
@stephenegriffin stephenegriffin self-assigned this Jun 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants