On 15/07/11 15:36, Phil Pennock wrote: > On 2011-07-14 at 08:54 -0700, David Mathog wrote: >> I don't have a grasp on the relative benefits of doing the spam checking >> in these two different ways, beyond the observation that the sa-exim one >> ends up with the headers spamassassin is configured to add. Since there >> is usually no free lunch, I'm guessing sa-exim is slower, user more >> resources, or has some other problem I don't know about yet... > > I don't use SA and hadn't looked at sa-exim's implementation before now. > > Make sure you set "SAspamcSockPath" to get to use the daemon instead of > parsing all the Perl modules for every spam received. > > Otherwise, there's a little more overhead even then from sa-exim but not > enough to worry about on any modern system (reads a config file, exec's > another binary; on the same order of the work that Exim does routinely > anyway, so I don't expect it to be an issue).
sa-exim is the old way to do it isn't it? You should be able to do everything you would normally do with sa-exim, with the newer built in version. After poking around for a bit, it seems the only real difference is when the scanning is called. The spam verb is called whenever it is found and the result is cached, some variables set, and then it is handled entirely in ACL. In the other, there is just a throw off to SA just prior to accepting the message and all decisions are made by SpamAssassin. I'd have to agree with using the spamd socket though - the startup time of spamassassin compared to spamd & spamc is HUGE. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
