I have just discovered that convertToWrapped joins the output lines using LF only, but expects the input to be CRLF. This seems to be a bug, but means it's not necessary to revert back after conversion.
It also occurs to me that the correct line-length for wrapping depends on the output device. Maybe it would be sensible to set the length to a high number so the wrapped lines are completely unwrapped? This would leave the wrapping to the device. On Wed, 19 Aug 2020 at 12:05, sebb <[email protected]> wrote: > > On Wed, 19 Aug 2020 at 09:33, Daniel Gruno <[email protected]> wrote: > > > > On 18/08/2020 21.29, sebb wrote: > > > I wondered about that. > > > > > > Now that the reformat is done after MID generation, it would not > > > affect the generators. > > > And it would only need to be done for f=f types. > > > > > > Also in theory it would only need to be done for mbox imports -- > > > AFAICT live messages *should* have CRLF line terminators. > > > > > > > > > I've added a LF->CRLF conversion option to the .unflow(), but I have it > > disabled by default for now, need to figure out the unit tests as they > > would fail since the resulting body is different from PM <=0.12. > > Indeed. > > > Perhaps I need to work in some sort of version checks in the unit tests. > > I suggest leaving the conversion as an option to make testing easier. > (It does not have to default to false, as long as it can be overridden) > > Most tests would not be affected (f=f is not that common). > There could be some tests specifically to test the wrapping behaviour; > these would need to be skipped for earlier versions. > This could perhaps be done by requiring the dkim generator as an argument?
