From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Wed Sep  9 15:50:28 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 1b987e63 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO);
	Wed, 9 Sep 2020 12:50:19 -0700 (PDT)
Message-ID: <94E808D19B9A5E6B039FDEF2737B325A@eigenstate.org>
To: theinicke@bss-wf.de, 9front@9front.org
Subject: Re: [9front] [Bug] [PATCH] Mail cannot cope with multi-line header fields
Date: Wed, 09 Sep 2020 12:50:18 -0700
From: ori@eigenstate.org
In-Reply-To: <9F25A73CBD8CC78F01ECC148912FD5C0@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: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: leveraged private SOAP just-in-time metadata full-stack locator 

> Having received a mail with line breaks in the subject I have noticed that Mail cannot deal with this. That is the current implementation assumes that each header field resides at a particular line inside the upasfs(4) info file.
> 
> Fixing this bug without touching the info file is probably error-prone, hence I'd like to propose two ways to correct this:
> 
> 1. Replace newline characters with some other character - resulting in a minimal change and not breaking any scripts relying on the interface as it is currently provided
> 
> 2. Add a field name to the entries in info file - then there is no need to make up some arbitrary character for encoding newlines; also this is probably more correct
> 
> Note that plan9port does not suffer from this; this is because each entry in the info file is prefixed with a field name. Given the fact that we are already incompatible to plan9ports upasfs maybe breaking the interface is neglectable.
> 
> Inlined is a patch which prefixes each entry in the info file with a field name and fixes Mail to work with it accordingly. In this first implementation Mail ignores the presence of any additional lines. Thoughts?


Will look at the code in more detail soon, but my first question is what happens when the
subject of a message is something like: 'the subject is\nsubject: blah'? If we're going to
make a breaking change, let's make sure that there's no ambiguity at all -- possibly
prefixing line splits with a space, or quoting the fields.