söndag 21 april 2019 kl. 07:34:15 CEST skrev Andreas Metzler: > On 2019-04-20 Magnus Holmgren <holmg...@debian.org> wrote: > > tisdag 16 april 2019 kl. 18:46:56 CEST skrev du: > [...] > > > > I have just uploaded exim 4.92-6 to exoerimental which /should/ > > > work with sa-exim, allowing you to debug properly. > > > > Thanks. So far I haven't managed to reproduce the problem of the malformed > > body file, though. > > That is kind of good news, it suggests some temporary bakage in exim > that was fixed since.
Or I need to test with more binary data. After all, IIUC, the point of BDAT is that you can send chunks of binary data of given sizes instead of the reveiving server having to look for <CRLF>.<CRLF>. > > However, I produced a segfault in local_scan() when I fed > > exim a spam message using BDAT with report_safe = 1 in local.cf, > > SARewriteBody: 1 in sa-exim.conf and spool_wireformat = true in > > exim4.conf(.template). > > Is this reproducible? I got it multiple times, but then I built and installed a slightly modified sa-exim, and now I can't reproduce it anymore, even after I reinstalled sa- exim from testing. I'm pretty sure that I've been using the same spam mail the entire time too. But I'm thinking that if the problem actually persists, I can at least work around it by checking if body_linecount == 0, which should mean that spool_wireformat = true (or that there's no body to rewrite anyway) and disable body rewriting then. But now that I look closer, it looks like the "spool format error" message is only triggered by malformed header files, and Thomas in https:// lists.exim.org/lurker/message/20180726.174108.0620f3c0.en.html had narrowed it down to multiple messages being received over the same connection. I still haven't been able to reproduce it though. It might be stochastic. -- Magnus Holmgren holmg...@debian.org Debian Developer
signature.asc
Description: This is a digitally signed message part.
