Hi,
On 07.06.2018 23:28, exim-users--- via Exim-users wrote:
> Exim mainlog show the corrupted message as second mail sent over one TCP
> connection (linux kernel mailing list server is the only server that
> sends more than one mail per TCP connection, other servers do not send
> those volumes).
On 06/06/2018 09:00 PM, Heiko Schlittermann via Exim-users wrote:
> @Jeremy: Maybe we should announce that sa_exim will have
> some end-of-life in the near future?
I'm happy to add to the docs chapter that discusses the spool file
formats that they are specifically regarded as not being a stable
i
exim-users--- via Exim-users (Do 31 Mai 2018 21:52:51
CEST):
..
>
> >> 1fOL7J-0001BL-DC-H
> > …
> >> 031 X-Spam-Relay-Country: US US **
> >> 090 Subject: [tip:perf/urgent] perf tools: Fix perf.data format
> >> description of
> >> NRCPUS header
> >> 065 X-SA-Exim-Version: 4.2.1 (built Tue, 0
Hello Heiko,
thanks for your fast analysis.
On 31.05.2018 17:38, Heiko Schlittermann via Exim-users wrote:
> I'm not sure how the sa_exim processing works, I do not use it for long
> time now. Does it see the original spooled message and modifies it?
> After this step, Exim does its own processes
Hi,
it looks as if the last SA-Exim header eliminated the blank line that
separates header and body.
I'm not sure how the sa_exim processing works, I do not use it for long
time now. Does it see the original spooled message and modifies it?
After this step, Exim does its own processessing, splitt
Hello,
as this gets quite long a short overiew in advance: After upgrading to
exim 4.90_1 (Ubuntu 18.04), I observe message corruption in the queue in
rare cases. All corrupted messages are from linux kernel mailing list. I
can eliminate file system as reason for corruption.
Whole story:
Since u
