After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 495265 - Mail Preferences/Junk: Spamassassin include remote tests setting ignored
Mail Preferences/Junk: Spamassassin include remote tests setting ignored
Status: RESOLVED DUPLICATE of bug 499644
Product: evolution
Classification: Applications
Component: Mailer
2.12.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: evolution-mail-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2007-11-09 12:12 UTC by Choose to remain Anonymous
Modified: 2009-05-27 03:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20



Description Choose to remain Anonymous 2007-11-09 12:12:25 UTC
Please describe the problem:
Evolution always launches a local spamd daemon with the --local flag. This is despite checking "Include remote tests" in Mail Preferences/Junk. On my system, I launch spamd without the -L/--local flag so it appears Evolution is ignoring the setting. While performance with -L is excellent, the remote tests are excluded which explains why :-).

Steps to reproduce:
1. Enable Spamassassin plugin.
2. Set or unset Include remote tests in Mail Preferences/Junk
3. Receive test spam (eg gtube test)


Actual results:
A local daemon is spawned by evolution even though spamd is launched without the -L/--local flag

Expected results:
Remote tests checkbox setting would be honored and Evolution would recognize system spamd.

Does this happen every time?
Yes

Other information:
This line can be added to any test email:
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

Here is output from ps ax |grep spamd. Note how a local spamd instance is spawned with running evolution even though system spamd has no -L/--local flag.

3353 ?        Ss     0:01 /usr/bin/spamd -d --pidfile=/var/run/spamd.pid
 3363 ?        S      0:03 spamd child
 3364 ?        S      0:02 spamd child
 8490 ?        Ss     0:01 /usr/bin/perl5.8.8 -T -w /usr/bin/spamd --socketpath /home/peterh/.evolution/cache/tmp/spamd-socket-path-cND3Vi --local --max-children=1 --pidfile /home/peterh/.evolution/cache/tmp/spamd-pid-file-G80hIr

The file em_junk_filter.c is likely the culprit in this function:
static void
em_junk_sa_test_spamd (void)

It seems not to detect the system spamd.
Comment 1 Choose to remain Anonymous 2007-11-10 12:21:57 UTC
Apparently, the setting on the Junk configuration screen: Include remote tests works opposite of what it indicates. Also, after changing a setting the user must quit evolution and restart for the change to take effect. When checked, ~.gconf/apps/evolution/mail/junk/sa/%gconf.xml shows:

<?xml version="1.0"?>
<gconf>
        <entry name="local_only" mtime="1194696080" type="bool" value="true">
        </entry>
</gconf>

which means that local tests are set and --local is passed to spamd

When Include remote tests is UNCHECKED, %gconf.xml looks like this:

<?xml version="1.0"?>
<gconf>
        <entry name="local_only" mtime="1194696080" type="bool" value="false">
        </entry>
</gconf>

which means remote tests WILL be performed.

I also think it should be shown on the screen that evolution needs to be restarted when this setting changes because the local spamassassin daemon has to be restarted.
Comment 2 ViktorHorvath 2008-01-07 20:05:38 UTC
The reporter is totally correct. Same behaviour and same situation here. System-wide Spamassassin with network tests exists, and Evolution spawns its own with --local when "Include remote tests" is checked. But when "Include remote tests" is NOT set and Evolution is restarted, it does NOT spawn its own spamassassin, but uses the system-wide one.

Using Debian package 2.12.2-1.
Comment 3 Akhil Laddha 2008-06-24 13:20:56 UTC
Most probably dup of bug 499644 which Matthew fixed for 2.22.
Comment 4 Akhil Laddha 2009-05-26 09:54:31 UTC
Could you please confirm if this bug is still happening at your end ? Please try in 2.24.x / 2.26.x and report back, thanks. 
Comment 5 ViktorHorvath 2009-05-26 21:12:00 UTC
Sorry for not replying earlier. Works fine with 2.22 in Debian stable (Lenny). Cannot test with later versions as their Debian versions were very unstable on my system and I reverted to 2.22 which runs fine.

Thanks for all your support and care about this great software! :-)
Comment 6 Akhil Laddha 2009-05-27 03:35:56 UTC
Thanks for taking the time to report this bug.
This particular bug has already been reported into our bug tracking system, but we are happy to tell you that the problem has already been fixed. It should be solved in the next software version. You may want to check for a software upgrade.


*** This bug has been marked as a duplicate of 499644 ***