GNOME Bugzilla – Bug 257091
Junk UI shouldn't appear without actual spam filtering support
Last modified: 2013-07-08 11:39:53 UTC
The Junk UI bits should not show up at all if spamassassin is not installed, since we require it's presence for anything to actually function. Or, the buttons, settings, menuitems, etc... should all be made insensitive.
p-d team, what's your preference? there are two posibilities dobey mentioned plus we may show an info/warning dialog when SA is not working.
Actually keeping the product but assigning first to the design team.
No dialogs. We should move all this stuff out into an EPlugin.
*** Bug 302680 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.
Spam assasin has been put in a plugin, However there should be nothing wrong in having UI even if the plugin is not enabled and spam assasin is not functioning. Messages marked as junk, will still be put into the junk folder, just that junk info "will not be learnt". Groupwise mailer doesn't rely on spam assasin for its junk filtering. So checking merely spam assasin and disabling UI is out of question.
Having used Microsoft Outlook, I can appreciate an opinion that the Junk UI should appear, since it allows users to perform Junk actions (albeit only a subset of them) that doesn't really have any useful effect (actions such as Add sender to junk sender list, etc., which has no useful effect since spammers tend to forge from addresses). Nevertheless, the rationale that two plugins could possibly provide some kind of Junk filtration functionality is not sufficient, and your WONTFIX tends to suggest a lack of developer time rather than a solid reason not to do this. Please explain this decision and let us know if you need help implementing or designing a better solution to this problem. People don't like one person dictating policy with no mandate.
hi Michael I think i explained this: Let me be more clear We cannot disable the UI just because spamassasin is not running, since in providers like "groupwise" that UI makes sense as it still learns spam mail adress and puts it to the server with the help of that UI. Groupwise doesnot rely on 'spamassasin' at all but still needs that UI. Same thing is going to be with exchange provider though not implemented yet. But it will need that UI. This functionality is written in provider code, and not in the plugin. So we _cannot_ disable the UI just because spam assasin is not running, as spam assasin is just one learning mechanism, can never be conclusive for that UI to be there or not. If the UI stays as it is and spamassasin is not installed: 1. Groupwise provider will still learn junk on clicking on "Mark junk action" and put that item in junk folder 2. Same is going to be with exchange provider in near future 3. Mailer with IMAP and other providers will put the mail in junk folder and no additional action will be taken like learning junk etc. [he won't see messages like 'Learning junk' and will be well aware of it] These three points probably conclude that keeping Junk UI is crucial irrespctive of the spam assasin being there. I hope I am clear enough, still I am ready for more discussion. I had no intention of dictating any policy, sorry if it sounded like that.
Let me clarify then. I don't care if it is spamassassin or bogofilter or what. The UI should not appear if the functionality is not there. Marking a message as junk or not junk does absolutely nothing useful. The user will think that if they get the exact same e-mail again, it would go into the junk folder, which is not the case. The current behavior is very misleading. The UI should be moved into the plug-in or be abstract enough to detect whether a sufficient plug-in is available or not. Given your mention of how groupwise works above, then it should also be smart enough to know whether or not you are actually using groupwise or something that supports the actions required for the UI. The largest portion of our userbase does not use groupwise. Having UI that effectively does nothing, is not useful.
Want to second this bug report. The current situation is very irritating. I've no spam-filter installed and corresponding plugin disabled still all the spam-filtering-part show up everywhere, which is very misleading and bad usability-wise IMHO. I understand the point about Groupwise, but then there has to be a solution where this only shows up, if you use the Groupwise-functionality, cause as Rodney already pointed out, most of us just don't. Also all the points about Groupwise are not valid for the preferences stuff. Why do I have a "Junk"-Item in Mail Preferences, where I can choose to "Check incoming Mail for Junk", when I actually can't? Especially for unexperienced users this is very irritating, Evolution tells them that they are now filtering their messages for spam, while it lets it all through. Result: Users gets frustrated at how crappy Evolutions spam filtering is.
afaik each spam filtering provider are available as eplugins. What about (for a start) making each plugin check for what it needs before activating the relevant UI or eventually issue a warning. Of course if multiple providers are available, one should be enough to activate the UI. What would be ideal is to get the UI activated only in the relevant context but afaik, this is not possible with current API. thoughts ?
This sounds like the correct solution to me. Let the plugins have a "are you capable" callback, and call them all. If none return success, then don't display (or make inactive; I don't think the usability guys responded) the UI. I'll work on a patch for this.
I agree with Bug 259506, which also recommends being able to intentionally disable the Junk UI. It might be easiest to solve both problems in a single patch. For example, my POP account provider does spam filtering for me, so I have no need of any spam-filtering functionality whatsoever. I want all the Junk-related UI features to go away, even though Fedora has pre-installed the Spam Assassin plugin for me. I would not have thought to go to "Edit -> Plugins" to turn off Junk UI elements; it seems like all of that should be handled from the "Junk" tab in "Mail Preferences". There is already a checkbox there to disable filtering of incoming mail (but confusingly you can also do that on a per-account basis, which I have also done). If there were no plugins capable of filtering incoming mail, I would expect this entire tab to be replaced by a message directing me to install an appropriate plugin. If there were a checkbox to intentionally remove the Junk-related UI elements, I would expect to find it on this tab. I suppose some people might want to keep the Junk UI elements while still not filtering incoming mail, since you can select messages or folders to be filtered, and do it at your convenience, rather than having it done as the messages arrive. This is still an issue in evolution-2.10.3-4.fc7, which is what I am using.
*** Bug 551089 has been marked as a duplicate of this bug. ***
*** Bug 259506 has been marked as a duplicate of this bug. ***
It would also be good to disable the keyboard shortcuts, which is likely an automatic consequence of removing the UI but I thought I'd mention it anyway. I've hit Ctrl-J by accident a few times and without Junk filtering support active didn't even think to look into the Junk folder.
IMAP servers can monitor a designated folder for junk messages, such that any messages moved there will train the server-side filter. Our IMAP backend now supports this behavior, such that clicking Junk on a message will move it to the designated folder instead of simply tagging it as junk. So even if there's no local junk filtering software installed, the Junk UI can still be useful. Closing as WONTFIX.
"can monitor" is kinda key here -- yes, and I even implemented that myself (dovecot antispam plugin), however it doesn't necessarily play well with the UI maybe the IMAP backend behaviour should be a special junk plugin instead?