Re: [exim] spool format error: size

Page principale
Supprimer ce message
Répondre à ce message
Auteur: Magnus Holmgren
Date:  
À: exim-dev
CC: exim-users
Anciens-sujets: Re: [exim] spool format error: size
Sujet: Re: [exim] spool format error: size
Thursday, 26 July 2018 kl. 19:41:08 CEST exim-users--- via Exim-users wrote:
> On 26.07.2018 13:33, Jakobus Schürz via Exim-users wrote:
> > Hi there!
> >
> > I get a lot of this errors:
> >
> > 4d  6.6K 1fhLuL-0003Kp-6q <systemd-devel-bounces@???>
> >     *** spool format error: size=7871 ***
> >           jakob@localhost


> I ran into this issue some weeks ago after updating to latest LTS Ubuntu
> (Exim 4.90.1-1ubuntu1). Tracked this down to sa-exim which is screwing
> up things as soon as more than one message is delivered over one
> connection. By looking at the spool files I saw that random data was
> missing/inserted.


I'm trying to figure this out so that the next Debian release can have
local_scan enabled again, but haven't been able to reproduce it so far. I
thought it must have to do with CHUNKING and spool_wireformat, since that's
new, but the error only indicates a broken -H file, doesn't it (errno =
ERRNO_SPOOLFORMAT is set by spool_read_header())? Was body rewriting even
enabled when breakage occurred? If it only happens when receving more than one
message over the same connection, that would seem to suggest that some static
variable isn't reset properly, but I can't find any.

Nevertheless, can anybody please briefly explain how the body file differs
when the header file has the -spool_file_wireformat flag? The SMTP read
abstractions are a bit tricky to pierce through and the documentation only
says that "some -D files can have an alternate format" and that users of the
local_scan API have to be aware of that. It also says "Lines are terminated
with an ASCII CRLF pair. There is no dot-stuffing (and no dot-termination)." I
see now that CRs are kept, but is there dot-stuffing otherwise? Anything else
to keep in mind?

I did find one other problem though, namely that sa-exim doesn't expect CRLF
and only strips LF when looking for the empty line that terminates the header.

Thanks,
-- 
Magnus Holmgren        holmgren@???