From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mx.sdf.org ([205.166.94.24]) by ewsd; Fri Oct 23 03:06:02 -0400 2020
Received: from sdf.org (IDENT:nicolagi@faeroes.freeshell.org [205.166.94.9])
	by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 09N75xxZ000390
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO)
	for <9front@9front.org>; Fri, 23 Oct 2020 07:06:00 GMT
Received: (from nicolagi@localhost)
	by sdf.org (8.15.2/8.12.8/Submit) id 09N76OEi023147
	for 9front@9front.org; Fri, 23 Oct 2020 07:06:24 GMT
Message-ID: <7A1325C96275F1E2919974762BE7F001@sdf.org>
To: 9front@9front.org
Subject: Re: [9front] upas/fs imap fetch failed
Date: Fri, 23 Oct 2020 08:05:53 +0100
From: nicolagi@sdf.org
In-Reply-To: <20201022205236.GA1322@wopr>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mx.sdf.org id 09N75xxZ000390
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: out-scaling database strategy general-purpose controller 

> On Thu, Oct 22, 2020 at 09:20:36PM +0100, nicolagi@sdf.org wrote:
>> parseattachments 42d380 5350 bonudary --000000000000a53d3b05b2093efc
>=20
> I pushed a fix for this typo ("bonudary") but of course it is not the
> problem.

=E2=98=BA

>> upas/fs: imap: fetchrsp: read: tls hungup
>=20
> Something is getting disconnected.  Do you know wha

Hmm. I'm not sure this is a symptom or a cause.
I don't know if you'll agree with my thoughts:

Seeing that fetchrsp's job seems to be parsing a response from the
server, I thought maybe there was a problem parsing one of the
responses, and that sent the server into a bad state, unable to parse
further responses.  To put this theory to the test, I went in and
deleted the attachment delimited by --000000000000a53d3b05b2093efc
(with mutt) and started upas/fs again.  Now I see all mail.  (BUT:
Also note how your e-mail text was clipped.  It wasn't me.  "bad
chars" and "reducing size" seem to be good hints.)

When this happens again, what's the best way to step through the
response parsing?  On another system I would perhaps capture the
packets and look at them and at fetchrsp() at the same time, but I
don't know if that can be done here.  And I'm sure there are smarter
ways.  :-)

Thank you