On Monday 06 October 2003 11:58 am, Praedor Atrebates wrote: > I also run spamassassin (daemon mode) on my desktop system (much better > hardware: Athlon XP2700+, 512 MB Ram vs Celery 366 and 256 MB Ram in my > laptop, for instance) and even though my desktop is stuck with a dialup it > still processes emails in one second or less - using bayes and the same > rules. My laptop uses an ethernet connection and takes no less than 20 > seconds per message. The main difference between the systems with regards > to spamassassin is that the laptop has had a lot more sa-learn data > applied. I use the laptop to acquire the vast bulk of my emails so it has > had more opportunity to learn spam.
Are you downloading messages? If so, to two separate machines? How do you reconcile which machine, laptop or desktop, gets which mail? Or do you have multiple accounts, each going to a different machine? On my desktop machine, I run Postfix and retrieve mail with fetchmail and use Postfix to deliver locally. I then use IMAP to allow me to read mail remotely while leaving mail stored on the local machine. Because the spamassassin check is done as mail is received, I don't need to worry about the specific timing of how long spamassassin takes per message. > > As your reply did help out a bit with my understanding of the checks, I > altered my rbl check to 5 instead of 10. > > I would consider no more than about 2 or 3 seconds per messages the max, > given what it does to the usability of kmail. Again, if you pull your mail from the spool after spamassassin has been run with procmail (via fetching mail, filtering with procmail and then delivering to the local spool), Kmail's performance becomes immaterial because the filtering is done prior to retrieval by Kmail. I would recommend some similar setup on your laptop, that way, your mail is all stored in a central place, but you still have access to it from remote as long as you have a connection to the machine. If you need to pull mail down to your laptop machine, why not let fetchmail pull the mail, run through procmail and then use procmail to deliver directly to the local spool and you can use Kmail to retrieve from the local spool. You won't need to worry about process time that way since mail is processed in the background, separate from what Kmail is doing. > > In any case, concomittent to sending the first message, I altered my filter > list so that list mails are before spam analysis (using kmail). The expert > list is good about not receiving spam in it but other lists I am a member > of get spam posted fairly regularly so I have been passing all messages > through spamd to hit them. > > The main problem with the long processing times is that kmail is entirely > unusable while the check is ongoing. You cannot even write an email > because the entire app is is limbo while the spam analysis (per message) > goes on. If it didn't hang kmail for the length of time the spam check was > ongoing I wouldn't mind as much as I could read emails that made it through > and send/queue messages for sending but as it is... See above. Having Kmail route to procmail would appear to be your complaint, not spamassassin. If you let procmail do it's business with spamassassin prior to attempting to gather mail with Kmail, the delay becomes a non-issue and Kmail is always usable. -- Bryan Phinney Software Test Engineer
Want to buy your Pack or Services from MandrakeSoft? Go to http://www.mandrakestore.com
