From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Thu Sep 10 17:12:32 EDT 2020 Received: from abbatoir.fios-router.home (pool-74-101-2-6.nycmny.fios.verizon.net [74.101.2.6]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id c3a36c54 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO); Thu, 10 Sep 2020 14:12:23 -0700 (PDT) Message-ID: To: theinicke@bss-wf.de, 9front@9front.org Subject: Re: [9front] [Bug] [PATCH] Mail cannot cope with multi-line header fields Date: Thu, 10 Sep 2020 14:12:22 -0700 From: ori@eigenstate.org In-Reply-To: <1E9189D603E4A86EC6969A0C7524340A@bss-wf.de> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: webscale ORM over AJAX base-oriented content-driven cloud > Maybe we should just get rid of the line breaks altogether (either at info file generation or possibly even before), because this would probably honor the following part of rfc2822 (this is identical in the newest rfc5322): > >> Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. > > -- > Tobias Heinicke In that case, yes. If the newlines are not intended to be semantically meaningful, let's strip them. It simplifies consumers.