[LBBS-147] net_imap: Long header values cause header parsing to fail
On certain emails, this error has been observed:
[2026-03-14 09:38:05.915] WARNING[241413]: imap_server_fetch.c:330 send_filtered_headers: Unexpected end of headers:
tdhordgvmhgrihhlrdgtohhmtggrshhtrdhnvghtpdhinhgvthepleeirdduudehrddvvdehrddufedupdhmrghilhhfrhhomhepthhhohhmrghsshhmihhthhegfeeisegtohhmtggrshhtrdhnvghtpdhrtghpthhtohepmhgvghhsvggrrhhssehntghfrdgtrgdprhgtphhtthhopehsphhrrgihnhhosehgohhoghhlvghgrhhouhhpshdrtghomh
In this example, that appears to be caused by this header:
X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedujedrvddvtddgvdehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuvehomhgtrghsthdqtfgvshhipdfqfgfvpdfpqffurfetoffkrfenuceurghilhhouhhtmecufedtudenucesvcftvggtihhpihgvnhhtshculddquddttddmnegoufhushhpvggtthffohhmrghinhculdegledmnegfrhhlucfvnfffucdlqdefmdenucfjughrpeffhffvkfgjfhfugggtrfgkofhisegrtdersgertdejnecuhfhrohhmpefvjffqofetufcuuffokffvjfcuoehthhhomhgrshhsmhhithhhgeefieestghomhgtrghsthdrnhgvtheqnecuggftrfgrthhtvghrnhepvedvlefhtddtfffhudehteekjeeviefgtefhieehledvudffuddvfeegleeijefgnecuffhomhgrihhnpegvvhhmshdrvgguuhdptghovhhiugdulegtrhhithhitggrlhgtrghrvgdrtghomhdpghhlohgsrghlrhgvshgvrghrtghhrdgtrgdpfigvshhtohhnrghprhhitggvrdhorhhgpdhnihhhrdhgohhvpdhnrghtihhonhgrlhhosghsvghrvhgvrhdrtghomhdpihgrqhhrvghsohhurhgtvgdrtggrpdgsihhomhgvuggtvghnthhrrghlrdgtohhmpdgtudelshhtuhguhidrtghomhdpghhoohhglhgvrdgtohhmnecukfhppeeliedrudduhedrvddvhedrudefuddpieelrdduudegrdefuddrudehkeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehogigrphhpqdgrshguqddvtdhordgvmhgrihhlrdgtohhmtggrshhtrdhnvghtpdhinhgvthepleeirdduudehrddvvdehrddufedupdhmrghilhhfrhhomhepthhhohhmrghsshhmihhthhegfeeisegtohhmtggrshhtrdhnvghtpdhrtghpthhtohepmhgvghhsvggrrhhssehntghfrdgtrgdprhgtphhtthhopehsphhrrgihnhhosehgohhoghhlvghgrhhouhhpshdrtghomh
X-Xfinity-VMeta: sc=-54.00;st=legit
The header value of X-Xfinity-VAAS alone is 1,246 characters, and is all on one continuous line - clearly in violation of the SMTP RFCs dictating line lengths of no more than 998.
While Xfinity is violating the RFC, this is probably an example where we need to be more liberal in what we receive for compatibility.
Comments
You must be logged in to leave a comment.