On 2023-03-07 at 08:38:42 UTC-0500 (Tue, 7 Mar 2023 13:38:42 +0000) Marc <m...@f1-outsourcing.eu> is rumored to have said:
[...]
If the spamc constantly gets spawned on the milter side, it does not look very efficient. But at least this resolving of ip's is not an issue. I don't get also the logics behind spawning a spamc client, I thought that milters should just 'pipe' the data to spamd and that is it. But I am not really familiar about how this design/communication is.
Milters can be consulted by an MTA at each step of the SMTP transaction. For SA and ClamAV, the step that matters is the "end of DATA" call, when the full message has been received. The MTA asks each milter for its judgment, but the milters themselves don't handle delivery or communication with the sending side.
Spamd has its own much simpler protocol that any program can implement but which is already fully implemented in spamc, which we support. It is unsurprising that the author of a minimalist milter for SA chose to use the existing working implementation of the protocol that they did not need to maintain. This mode of operation is not the most efficient, but it works.
I would even say that a milter implementation could be generic, and does not depend on if the backend is a clamd or a spamd. It just parses the content and the result is received.
That is the whole point of the milter interface. Some milters (MIMEDefang, MailMunge, Amavis) support multiple filtering backends so one can do both spam and virus determination with one MTA interface.
The other trick used by those milters for efficiency is to not use spamd at all, but to instead load the SpamAssassin Perl module and use it directly.
-- Bill Cole b...@scconsult.com or billc...@apache.org (AKA @grumpybozo and many *@billmail.scconsult.com addresses) Not Currently Available For Hire
