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