On 2023-12-11 at 09:37:39 UTC-0500 (Mon, 11 Dec 2023 15:37:39 +0100)
Carlos Velasco via Postfix-users <carlos.vela...@nimastelecom.com>
is rumored to have said:
Bill Cole via Postfix-users escribió el 11/12/2023 a las 15:31:
On 2023-12-10 at 16:37:16 UTC-0500 (Sun, 10 Dec 2023 22:37:16 +0100)
Carlos Velasco via Postfix-users <carlos.vela...@nimastelecom.com>
is rumored to have said:
[...]
And doing the same work in 2 different places can be called software
efficiency?
No, but the "fix" here would be a divergence from how Milter has
worked
since it was created and semi-documented by Sendmail Inc. It is de
facto
controlled by the current developers of Sendmail, but I don't believe
anyone is working to make Milter better, at least not in ways that
would
break compatibility.
No one is talking here about breaking any compatibility, re-read the
messages.
What did I miss? Are you not asking for Postfix to support providing
milters with a header that none of them expect and which no other Milter
implementation supports?
That seems to me like a compatibility break. Or you could call it a
unique extension to a protocol which lacks a defined extension mechanism
or even a formal standardization. Postfix would be doing something with
a shared (if not exactly open...) de facto standard that is effectively
controlled by the Sendmail project. What could go wrong?
Beyond that, I don't think that your justifications for such an addition
have made any sense. Milters can ask for any available macros needed
explicitly, avoiding the need to parse a Received header in the milter
itself. The only reason SpamAssassin requires a synthetic header is that
it has no interface for passing the known untainted values of the
parameters it wants to use. SA knows nothing about the milter API or
"Sendmail Macros" or which MTA+milter layer you are using, so if it
needs that it can only look in a header built in the milter
e.g, as logged by the MD instance here (which logs excessively...):
Dec 11 09:31:59 shiny mimedefang.pl[13203]: 4Spkhs2mXtzXcP2f: Macros
are mail_mailer mail_addr daemon_port client_port mail_host auth_authen
auth_type j cipher _ client_connections daemon_name tls_version
cipher_bits
From those macros, MD constructed this Received header for handoff to
SpamAssassin:
Received: from skinnyclam.scconsult.com (skinnyclam.scconsult.com
[192.168.254.125])
by shiny.scconsult.com (envelope-sender
<postfixlists-070...@billmail.scconsult.com>) (MIMEDefang) with ESMTPSA
id 4Spkhs2mXtzXcP2f
for <postfix-users@postfix.org>; Mon, 11 Dec 2023 09:31:59 -0500
SpamAssassin can reliably and usefully parse out of that header the fact
that the message arrived with authentication over an encrypted session.
If one had a particular need for some other defined macro one could
request it in the milter and stuff it into a header as appropriate.
--
Bill Cole
b...@scconsult.com or billc...@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
