On Wed, 31 May 2023, Matus UHLAR - fantomas wrote:
[snip..]
milter adds own synthetised Received: header at the very beginning, which is
mosts possibly the correct reason.
spamass-milter should add this header behind locally added
Authentication-Results: headers, but it needs change in spamass-milter.
tl;dr if those 'Authentication-Results: headers' are generated by the MTA itself
the milter may not ever see them.
Which agent in the whole MTA system is adding those 'Authentication-Results:
headers'?
Is it the master MTA itself (EG: postfix or sendmail) or is it some other milter
component?
A milter can only work with what it's handed by the master MTA, if the
Authentication-Results: headers aren't in its input stream then it cannot work
with them.
In the original sendmail incarnation of the milter API it was designed so that a
milter received the message input stream -before- local headers were added, thus
the need for spamassassin 'glue' milters to do that Received: header synthesis.
If those Authentication-Results: headers are being generated by another milter
then the solution is easy, just set the MTA configuration to run that milter
before the spamassassin 'glue' milter. Milter results are chained so any headers
explicitly added by one milter are passed on to succeeding milters.
If those headers are being generated by the MTA then it may not be possible for
milters to see them with out hacking the MTA itself.
--
Dave Funk University of Iowa
<dbfunk (at) engineering.uiowa.edu> College of Engineering
319/335-5751 FAX: 319/384-0549 1256 Seamans Center, 103 S Capitol St.
Sys_admin/Postmaster/cell_admin Iowa City, IA 52242-1527
#include <std_disclaimer.h>
Better is not better, 'standard' is better. B{
