Mailing List Archive

Marc:
>
>
> I recently had an issue where mail was temporarily rejected because clamav-milter/spamass-milter could not connect to clamd/spamd. Clamd/Spamd are a tasks that can automatically change hosts and thus their ips. A simple restart of the milter fixes this (resolves the new ip).
>
> However, it would be nice if something could be added to the milter code that, if it can't contact spamd, it tries to re-resolve the ip address automatically.
>
> ps. as you can deduct from the text I am not a 100% sure which milter caused this actually.
>
> pps. even nicer would be, the ability to use srv records and use dynamic ports.

spamass-milter spawns a new spamc process for each incoming message. It
does not keep around any such state and wouldn’t need a restart for a
changed spamd host.

On 2023-03-06 at 06:59:03 UTC-0500 (Mon, 6 Mar 2023 11:59:03 +0000)
Marc <Marc@f1-outsourcing.eu>
is rumored to have said:

> I recently had an issue where mail was temporarily rejected because
> clamav-milter/spamass-milter could not connect to clamd/spamd.
> Clamd/Spamd are a tasks that can automatically change hosts and thus
> their ips. A simple restart of the milter fixes this (resolves the new
> ip).
>
> However, it would be nice if something could be added to the milter
> code that, if it can't contact spamd, it tries to re-resolve the ip
> address automatically.

That would be an interesting feature in a milter. You should suggest it
to the developers of whichever milter(s) you are using. The ASF
SpamAssassin project does not maintain any milters, but there may be
people on this list who use the same tool can help you.

> ps. as you can deduct from the text I am not a 100% sure which milter
> caused this actually.

Are you not aware of IP changes by spamd?

> pps. even nicer would be, the ability to use srv records and use
> dynamic ports.

Sounds great. Out of scope for SA itself, but it would be fine for a
milter.


--
Bill Cole
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

On Mon, Mar 06, 2023 at 11:59:03AM +0000, Marc wrote:
>
>
> I recently had an issue where mail was temporarily rejected because clamav-milter/spamass-milter could not connect to clamd/spamd. Clamd/Spamd are a tasks that can automatically change hosts and thus their ips. A simple restart of the milter fixes this (resolves the new ip).
>
> However, it would be nice if something could be added to the milter code that, if it can't contact spamd, it tries to re-resolve the ip address automatically.
>
> ps. as you can deduct from the text I am not a 100% sure which milter caused this actually.

It's clamav-milter doing dumb things. Looking at the source code it just
resolves the address at startup and keeps using the IP indefinitely. That's
not how a software is supposed to work. File a bug report to ClamAV, and
good luck since the milter code seems practically unchanged since 2009. :-)

Henrik K skrev den 2023-03-06 17:12:

> It's clamav-milter doing dumb things. Looking at the source code it
> just
> resolves the address at startup and keeps using the IP indefinitely.
> That's
> not how a software is supposed to work. File a bug report to ClamAV,
> and
> good luck since the milter code seems practically unchanged since 2009.
> :-)

clamav milter is part of clamav, despite spamass-milter is 3dr party,
hmm :)

if spamassassin did the milter itself it would be lots of more stable
imho, no ?

clamav-milter is just not designed to dynamic ip changes, so keep
127.0.0.1 lol

also when clamd changes to new cmake thay breaked tcp sockets ://///

>
> > I recently had an issue where mail was temporarily rejected because
> > clamav-milter/spamass-milter could not connect to clamd/spamd.
> > Clamd/Spamd are a tasks that can automatically change hosts and thus
> > their ips. A simple restart of the milter fixes this (resolves the new
> > ip).
> >
> > However, it would be nice if something could be added to the milter
> > code that, if it can't contact spamd, it tries to re-resolve the ip
> > address automatically.
>
> That would be an interesting feature in a milter. You should suggest it
> to the developers of whichever milter(s) you are using. The ASF
> SpamAssassin project does not maintain any milters, but there may be
> people on this list who use the same tool can help you.
>
> > ps. as you can deduct from the text I am not a 100% sure which milter
> > caused this actually.
>
> Are you not aware of IP changes by spamd?

No, I would even like to have a situation where they would scale automatically. :)

>
> > pps. even nicer would be, the ability to use srv records and use
> > dynamic ports.
>
> Sounds great. Out of scope for SA itself, but it would be fine for a
> milter.

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.
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.

On 2023-03-07 at 08:38:42 UTC-0500 (Tue, 7 Mar 2023 13:38:42 +0000)
Marc <Marc@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
bill@scconsult.com or billcole@apache.org
(AKA @grumpybozo and many *@billmail.scconsult.com addresses)
Not Currently Available For Hire

On Mon, Mar 06, 2023 at 11:04:09PM +0100, Benny Pedersen wrote:
> Henrik K skrev den 2023-03-06 17:12:
>
> > It's clamav-milter doing dumb things. Looking at the source code it
> > just
> > resolves the address at startup and keeps using the IP indefinitely.
> > That's
> > not how a software is supposed to work. File a bug report to ClamAV,
> > and
> > good luck since the milter code seems practically unchanged since 2009.
> > :-)
>
> clamav milter is part of clamav, despite spamass-milter is 3dr party, hmm :)
>
> if spamassassin did the milter itself it would be lots of more stable imho,
> no ?

What's so special about milter anyway that SA project would need to make
it's own? There already exists 100 times more flexible things for that,
like amavisd-milter/amavisd-new and mimedefang.

ClamAV can be called from either and even from SA itself, there's very few
use cases for clamav-milter as a standalone component.