Ben Wylie wrote: > I have just gone through a few logs of expiration an message testing, and > have some more questions. > > First of all, with the expiry, there are two stages which take a long time. > On my slow (450MHz, Windows) system once it has got to this line: > debug: bayes: expiry max exponent: 9 > it takes seven minutes before it moves on. > > What exactly is it doing at this stage? Why does it take so long, and is > there a way to reduce the time it takes to do this?
SA is removing the least recently used tokens from your bayes database to keep it from growing without bound. If you have a lower bayes_expiry_max_db_size this will run more often, but it will run much faster. However, your bayes accuracy will go down. > > Now looking at a log of a message being scanned, it seems to check all > relays to see which ones are trusted. > > score ALL_TRUSTED 0.0 0.0 0.0 0.0 > > ============================ > debug: metadata: X-Spam-Relays-Trusted: [ ip=127.0.0.1 rdns= helo= > by=arkbb.co.uk ident= envfrom= intl=0 id= auth= ] > debug: metadata: X-Spam-Relays-Untrusted: [ ip=80.168.70.64 > rdns=mx4.mail.uk.clara.net helo=mx4.mail.uk.clara.net by=server. ident= > envfrom= intl=0 id=M2005052411250114443 auth= ] [ ip=213.47.158.114 > rdns=chello213047158114.22.11.vie.surfer.at helo=autochair.co.uk > by=mx4.mail.uk.clara.net ident= envfrom= intl=0 id=1DaWas-0009VL-Bh auth= ] > ============================ > > Is there any reason for it to continue to carry out these checks if all > trusted score set to 0 in my local.cf file? YES. Trust paths are used in MUCH more than just the ALL_TRUSTED rule. In fact, by zeroing ALL_TRUSTED you're just covering up the most obvious sign of a broken trust path, but it's not the only problem you suffer from. If you can, fix your trust path ASAP. http://wiki.apache.org/spamassassin/TrustPath > > I've noticed that SpamAssassin adds up the score as it goes along. If all > the uri tests hit, my scoring means that those emails are deleted > automatically my my mailserver as it has reached a high enough score. > However SA continues to check all rules before returning the result. Is it > possible to get it to stop tests once a specific score has been reached? No, it was a feature but was removed because it caused FP's. This is because some rules are negative scoring. The overall message score could wind up starting off high, but then drop down low due to a negative-scoring rule. You could force SA to run all the negative rules first, then all the positive, but that was tried and it turned out to be on average slower than running all the rules because SA had to make multiple passes at scanning the message. Even in the best case the performance gain was rather tiny, and didn't justify the massive increase in average scan time. > If this is possible, then is it possible to change the order in which SA > carries out the tests so i can put the uribl tests at the beginning, and > avoid having to carry out all of the others if all the uribl tests hit? No, because SA would have to scan the message body twice. Once to parse out URIS, then later run it all again to do the body rules. That's much more expensive than any performance gains you suggest here. Same as the score-sorting issue. > Is there any way to do some kind of spf test, in this kind of case where > most emails are going through one or two proxies before reaching SA? SA > should be checking the spf record for atta.cl for the ip address > 213.47.158.114. Is there a way to tell SA that this is what it should be > doing? Yes, fix your trust path. If you trust the proxies to not forge headers, add them to your trusted_networks. SA will consider the "first untrusted" host to be the "source" of the message. > > It looks like SA is detecting something funny itself, from the log below: > > =========================== > debug: X-Envelope-From header found after 1 or more Received lines, cannot > trust envelope-from > debug: Return-Path header found after 1 or more Received lines, cannot trust > envelope-from > > Why can't it trust the X-Envelope-From? As it said, it occurs after some received: lines, therefore it was not created by the local host and could be forged by an upstream server. <snip> Sorry man, I'm ignoring the rest of the message. There's WAY too many questions here for me to have time to answer. Many of them all seem to relate back to similar problems of trust path.
