Bug#949370: Acknowledgement (spamass-milter: synthesized received header sometimes use the sendmail start time instead of current time)

2020-01-25 Thread Don Armstrong
On Tue, 21 Jan 2020, Bjørn Mork wrote: > The issue could probably be fixed in sendmail by moving the initsys(e) > call in front of milter_envrcpt(). But reading the milter docs, I am > not convinced this is the "most correct" fix. I believe the bug really > is in spamass-milter assuming that the

Bug#949370: Info received (Bug#949370: Acknowledgement (spamass-milter: synthesized received header sometimes use the sendmail start time instead of current time))

2020-01-21 Thread Bjørn Mork
Control: tag -1 +patch Although I believe sendmail is functioning as designed and documented, this bug makes it clear that milters expect and depend on several sendmail macros in the milter_envrpct() stage. The macros which are set and updated by initsys() can easily be made available by simply

Bug#949370: Acknowledgement (spamass-milter: synthesized received header sometimes use the sendmail start time instead of current time)

2020-01-21 Thread Bjørn Mork
Based on my understanding of the milter API docs, I believe this is a spamass-milter bug aided by confusing sendmail docs and API. I looked at the sendmail code and did some additional milter tests. Both confirm the root cause: The "$b" macro is not necessarily updated the when the first envrcpt

Bug#949370: Acknowledgement (spamass-milter: synthesized received header sometimes use the sendmail start time instead of current time)

2020-01-20 Thread Bjørn Mork
Control: clone -1 -2 Control: reassign -2 sendmail Control: severity -2 normal Control: retitle -2 sendmail: milter expansion of "$b" macro is unreliable Control: found -2 8.15.2-14~deb10u1 The underlying bug appears to be in sendmail. But I'm keeping the spamass-milter bug open since the use of