Kmail: A filter won't work until re-OK'd

One of my filters won’t work until I go into Configure Filters, select it, and click OK. Then I can run “all filters” on the Inbox and the relevant emails are moved. The filter is looking at the “site:” and "
Sent from (referer):" fields to identify emails coming through my blog, most of which are spam.

This is the first filter on the list. The filter lower down that directs emails addressed to my blog host email address into the local folders inbox works, the emails that the first filter should divert into a special folder end up in the local Inbox.

All other filters, and I have plenty of them, are working. Well, usually, occasionally I have to manually run the filters, or run “check mail” again.

This is an upgrade from 42.3.

Un-checked the “If this filter matches, stop processing here” option under “Advanced” in Settings > “Configure filters…”.

A bit obvious, now I see it.

It seems that once the filters have been run, they won’t run again unless there are new emails or the filters have been modified or added to, and just clicking OK is enough to signal a change. Even though the “move to inbox” filter comes well down the list as displayed, evidently it is actioned first.

No, that didn’t work. But I notice that the Site: “http://andygoss.net.au”, which in the source is plain text, is showing as a link in the email itself in some instances where it is interpreted as part of the email body.

After much research, the situation is as follows:

Some filters are not applied on incoming emails. Those that are applied are the ones that redirect emails from their initial inbox (I have several email addresses) to the local inbox or to other folders, based on the To and From fields. Other filters are not applied, even though the first group are set to not stop checking if met.

However, if, after the start of the session, the Settings > Configure Filters utility is opened, and one filter, it doesn’t matter which, is selected, and OK pressed, then filters can be run manually on a folder, and any subsequent incoming emails during the session will be fully filtered.

This is not ideal, is this fixable?

Today the filters appear to be working as they should. I must assume a recent update contained a fix.

I’ve been intending to open a thread on this exact problem, and I logged a KDE bug report at 400770 – Erratic Kmail filtering (startup problem?) on 7th November.

I’ve found no filters are run when mail is initially downloaded, as shown by running the filter-log viewer in the “tools” menu. However manually running all filters on an email after downloading queued messages (or manually running filters twice before downloading) seems to galvanise filtering into action.

Two other problems seem to be associated, as noted in the bug report.

(1) When the Kmail GUI is started, the download progress-bar is usually displayed immediately at 0% even though no download should be happening (Retrieval Options > Check mail on startup is off), and checking mail doesn’t appear to work. Restarting Kmail then resets it.

(2) Sometimes two copies of a filtered email which was directed to another mailbox appear. One seems perfectly OK, but a second apparently has no bodypart, is permanently flagged as “unread”, and cannot be deleted. Other effects are unpredictable; I’ve seen an instance now where the same two copies also appeared in a scratch folder (created to save a copy of some incoming emails) but one copy with a blank bodypart was successfully deleted. The only way of recovering from the first situation is to rename the folder, create a new version and update the relevant filter, move all wanted emails, and delete the renamed folder altogether.

These sound very much like race conditions to me, particularly involving Akonadi database operations.

David L.

Kmail does seem to have a variety of problems. Mine does not always run the initial download on startup, and in the past I have had duplicated, but identical, emails, but I’m not getting the same problems you are. My filter problem has now returned, after a brief period of working. I’ll attach myself to the bug.

I’m afraid that was a little misleading. The first attempt to manually run filters appears to enable the filtering process, and the second results in output from the filter-log viewer. Sending an outgoing message after downloading also results in viewer output, and I think a second download is properly filtered. Fairly obviously, filtering isn’t started properly until poked. Sometimes I see popup windows displaying messages related to filtering startup, usually not.

I wonder whether the Kmail “download” module assumes it runs continually, and this is related to the filtering startup problem. In my case, I start the Kmail GUI manually, and a scheduled download task then has to wait for a Kwallet password in order to retrieve the mailbox password. It’s as though the first scheduled download task fails because it has no mailbox password, but the second succeeds because it has one. Is filtering startup dependent on the download module?

None of this seems relevant to the duplicate-message issue, which is a real pain because fixing it requires some reconfiguration. I think that might be an Akonadi database issue.

David L.