Alberto, > Unfortunately, all Lucio's troubles are (partially) due to my fault... > I'm one of the members of the academic working group that wrote some > suggestions to its network users.
Perhaps it's time to follow your neighboring country's academic working group (Arnes) and start suggesting Postfix ;-) I'm sorry that I have limited experience with sendmail in real life, after abandoning it years ago, which certainly shows in poor help and support from me and from this mailing list to milter users. > > Also we like the idea of > > rejecting spam. And our server is at the level of less than 1000 messages > > per day. > > Yes, all our problems come from the need to reject spam Being able to reject spam is certainly a valid and probably the only good reason to stick with a pre-queue content filter setup. > (we are currently rejecting 10000 messages per day!). Actually the subset of spam that benefits from rejection is much narrower. Rejecting a high score spam majority (say: above 15 score points) is very unlikely to end up in hands of a proper and legitimate sender, and may be contributing to backscatter by itself. Using greylisting or boosting score for mail from Windows XP (based on passive OS fingerprinting) gets a long way to reduce unwanted backscatter in post-queue setups (such as dual-sendmail or Postfix), while the benefit of achieving a setup that handles congestions in a predictable and stable way is imperative for large sites. > We have 2 groups of users: > - One likes the spam rejecting. > - One likes spam tagging only, without reject. > Could you give me a configuration (policy banks ?!?!) able to > merge the 2 above needs? (rejecting + tagging in amavisd.conf). > This way, we could completely eliminate spamd! This is achievable with per-recipient maps. There is no need for policy banks for this goal - policy banks are suitable for adjusting settings which affect the message as a whole, for all its recipients, which is why policy banks are normally switched on some common characteristic of a message such as sending client's IP address. If you configure a final_spam_destiny as D_REJECT, but list recipients which prefer tagged spam as 'spam lovers', this probably already achieves what you need. > Because of mail-server performance problems, we are now trying to > partially eliminate spamd, by using the Petr Rehor's amavisd-milter. > Unfortunately, I've had some timeouts problems, and I'm waiting > for an answer from Petr... > > The log of the test, lasted about 20 minutes, is available at: > http://www.to.infn.it/~gandalf/download/mail.log > I have started up the milter with the attached startup script. I checked the log, but can't tell what could be the reason. Seems that after a while all amavisd child processes get tied up and amavisd-milter can't make further connections. Or it could be the amavisd-milter's impression is artificial, perhaps due to some race condition on (mis)managing semaphore which allows it to limit the number of connections to amavisd. Make sure the value in option -m of amavisd-milter matches the $max_servers in amavisd.conf. It may be worthwhile to check with a lsof utility on states of sockets on amavisd processes, and verify if they are indeed tied up by an idle thread of amavisd-milter or not. Also amavisd-nanny utility can give a quick overview on a state of each amavisd process. Petr, (I hope you are reading this), it may be useful to add a log entry in amavisd-milter to report just when amavisd-milter closes a socket to amavisd. Mark Mark _______________________________________________ AMaViS-user mailing list AMaViS-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amavis-user AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3 AMaViS-HowTos:http://www.amavis.org/howto/