GNOME Bugzilla – Bug 264455
Junk preferences are confusing/broken (per account vs global settings)
Last modified: 2021-05-19 12:28:38 UTC
Description of Problem: There are two different places to enable/disable spam filtering: 1. Tools->Settings->Mail Preferences->Junk 2. Tools->Settings->Mail Accounts->(Edit account name)->Receiving Options. I think this is confusing. It confused me, and at least one other user (who didn't see configuration page #2 at all--see bug#261192). One problem is that setting #1 appears to be a global setting. Turning this off appears to completely disable spam filtering in Evolution (but if true, this is not at all clear), regardless of the settings in area #2. My suggestions: 1. On the "Tools->Settings->Mail Preferences->Junk" page, "Check incoming mail for junk" should read something like "Allow Evolution to check incoming mail for junk". 2. The current tooltip reads "Checks incoming mail messages to be Junk". Rather than having an (obscure and redundant) tooltip, I think a clarification is important enough here to be shown as subtext, as is currently done (on the same page) for the "Include remote tests" option. I suggest that this clarification read something like "If you enable this option and have more than one mail account, you may disable junk filtering in the settings for individual accounts." 3. Assuming that "Check incoming mail for junk" is meant to be a global setting (what else would it be? a default for new accounts only?), when it is DISABLED, I suggest all junk-related, per-account settings widgets should be disabled (non-selectable) as well. Currently I can request Evolution to "Check new messages for junk contents" (in the account settings) when "Check incoming mail for junk" is disabled globally, but based on the (inadvertent) testing I've done, Evolution won't respect my account-specific sestting. Additional Information: root ~]# rpm -qa | grep snap gtkhtml3.1-3.1.20.0.200408240630-0.snap.ximian.6.1 evolution1.5-1.5.93.0.200408240630-0.snap.ximian.6.1 libgtkhtml3.1_11-3.1.20.0.200408240630-0.snap.ximian.6.1 evolution-data-server-0.0.98.0.200408240630-0.snap.ximian.6.1 libsoup2.2-2.1.13.0.200408240630-0.snap.ximian.6.1 libgal2.2_0-2.1.14.0.200408240630-0.snap.ximian.6.1
OK, it seems I may be wrong about the current behaviour. I left the global setting unchecked, and just witnessed a piece of spam get filtered out of my Inbox (for the account which has spam filtering enabled). So... whatever these options are *supposed* to do, I'd like to reinforce the idea that they are CONFUSING! I really don't know what's going on here, and I doubt that many users will be able to figure it out from the current configuration options.
I am the submitter of bug#261192. The reason I didn't see the option for junk filtering in the Receiving options is that it isn't there for POP accounts. I have an IMAP account where this option exists. So that's another point for the list of things that makes junk filtering confusing: 4) Different account types have different options wrt. spam handling.
i think this should be targetted to 2.3 since it's really confusing. also includes string changes.
*** Bug 306880 has been marked as a duplicate of this bug. ***
Apologies for any spam... cc'ing usability-maint on all Evolution usability bugs. Filter on EVO-USABILITY-SPAM to ignore.
retargetting to 2.5. "check incoming mail for junk" under "edit | preferences | mail preferences | junk | general" only refers to POP and Local delivery; and only for IMAP you must have "check new messages for junk contents" under "edit | preferences | mail accounts | edit | receiving options | options" enabled. should also be included in the docs, see bug 317223 for that.
Including harish and jessica in the cc list, since they have to approve the documentation.
This is also valid for the evolution-exchange connector package as well so should be fixed at the same time as the others.
hem, I think it is fixed by now isn't it ? svn head even received work for pluggable spam plugins and I only see one place to modify this settings (per-account option).
No. I still see option to enable it under Mail Preferences/Junk as well as in the account options (I only use the exchange connector though) in evo 2.10.1. Also in some of the crash dumps I still see references to spamassassin even though I have it all disabled including the plugin (we have 2 layers of server side SPAM filtering so I don't need it client side).
oh true, forgot about this one. Concerning spamassassin, this will be fixed in 2.12 hopefully. you can switch for spamassasin to bogofilter and it detects if bins are missing but I'm not sure it can be disabled completely (see bug #257091 for details). If the either one of the widgets is unused, it will be easy to get rid of it.
Guys, Im ideally if the global settings aren't respected at all, then it makes very sense to have them part of the account settings only. Im not sure of the impl atm for this option. Need to see the code. Or else, make the account specific options override global settings. Like if disabled (globally) all should be disabled. If enabled then you can enable/disable per account. I prefer to follow the second approach. I will try to give it some love soon.
I agree with the submitter: - Junk email option should be enabled or disabled on a per-account basis, both for IMAP and POP accounts.
Either rename the global option to reflect better what it means, and/or enhance each account type with the junk filtering option. The problem with POP accounts is that it doesn't have its own real folders, it moves its messages into On This Computer/Inbox folder, where can be piled more POP accounts, some with Junk filtering enabled, some not. Differentiate on a per-message bases would be inefficient, I'm afraid. For that the global option would matter only for the On This Computer folders, while the other accounts, which have real folders, would better receive their own junk filtering option.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/Community/GettingInTouch/BugReportingGuidelines and create a new bug report ticket at https://gitlab.gnome.org/GNOME/evolution/-/issues/ Thank you for your understanding and your help.