-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Andy Jezierski writes: > Andy Jezierski <[EMAIL PROTECTED]> wrote on 09/13/2004 10:13:01 AM: > > > I've got a question as to whether you think this is a milter error or a > > spamd error. I'm thinking milter. > > > > I'm running milter-spamc 0.24 along with sendmail 8.13 on one box, which > is > > calling spamd 3.0rc3 (haven't had a chance to go to rc4 yet) running on > > another box. Everything works just fine, except, when I run an sa-learn > on > > the box running spamd. > > > [snip] > > I got a reply from the milter author saying this is a problem with > spamd.... > > > Sep 13 09:36:31 viper milter-spamc[40625]: 34482 i8DEYOCH096305: timeout > > before input from SPAMD server > > Sep 13 09:36:31 viper milter-spamc[40625]: 34482 i8DEYOCH096305: SPAMD > > status line failure > > Sep 13 09:36:44 viper milter-spamc[40625]: 34486 i8DEYake096312: timeout > > before input from SPAMD server > > Sep 13 09:36:44 viper milter-spamc[40625]: 34486 i8DEYake096312: SPAMD > > status line failure > > This is the problem with spamd, its not truely threaded and gets hung up > when ever more than one process (spamd, sa-learn, spamassassin) access > the token/database files. > > The second set up errors from sendmail could be avoided by increasing > the sendmail-milter timeout in the INPUT_MAIL_FILTER line, but this is > not guaranteed solve overall problems with SA. > > Essentially, the problem lies with SA perl bloat and lack of decent > threading. > > You could try increasing the milter-spamd timeout, but if you do this > you must increase the sendmail-milter timeout to account for this. > > Should I open a bugzilla on this or is there no way around the problem for > now? what's the time spent waiting for spamd? what's the milter's default timeout? It sounds a lot like SpamAssassin's potential latency (up to 10 seconds if a db operation is in progress, waiting for the db to be unlocked; possibly higher if network tests are being used; plus a few seconds for the non-db, non-network tests) is higher than the milter expects to have to deal with. This is not a bug; spamc, for example, can wait for up to 10 minutes for spamd to complete before giving up. that's pretty extreme though. I don't think I've ever seen spamd take that long. The correct behaviour of the milter should be to either: (a) wait for spamd to return a response although it may take a while, (b) pass the message through and deliver as nonspam, or (c) queue the message for later checking, probably not possible from a milter. (I'm disregarding the ignorant comments about "bloat" and threading.) - --j. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFBRy82QTcbUG5Y7woRAvK4AKC6fe4Mz819THlGlCfcQu2rlqnj6gCcDEP/ E6X5LLpjm/vdTl024tMxdxw= =DhOT -----END PGP SIGNATURE-----
