Bug 74888 - change fallback action for POP filtering from "download later" to "download"
Summary: change fallback action for POP filtering from "download later" to "download"
Status: RESOLVED DUPLICATE of bug 79694
Alias: None
Product: kmail
Classification: Applications
Component: filtering (show other bugs)
Version: 1.6.1
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-10 23:51 UTC by Giovanni Venturi
Modified: 2009-12-19 00:05 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Giovanni Venturi 2004-02-10 23:51:47 UTC
Version:           1.6.1 (using KDE 3.2 BRANCH >= 20040204, compiled sources)
Compiler:          gcc version 3.3.2
OS:          Linux (i686) release 2.6.2

I think the policy of POP3 filters of KMail is not correct. A POP3 filter has to filter emails in case of setted rules.
I think the standard policy has to be: download email, but if I set some rules the mail have to be checked with these rules and if not corresponde to these ones the email has to be downloaded without KMail ask me.
If you want a better solution can be to change KMail standard policy. You can set this to download email later like is now, but I can change the standard policy into a configuration dialog of POP3 filter.
Microsoft Outlook Express use the standard downloading of emails if no rules correspond and it's the right way to do, but if we developers/users of KDE want to do better my suggest can be take in mind: set a standard policy and have the possibility of change it.
I hope you don't close this bug with a non valid reason. IMHO is a bug and not a wishlist. If you think I can try to understand understand KMail and write myself this feature, but you can do this faster because you know perfectly how POP3 filters works. Let me now something.
Comment 1 Andreas Gungl 2004-02-11 09:47:22 UTC
On Tuesday 10 February 2004 23:51, Giovanni Venturi wrote:
> I hope you don't close this bug with a non valid reason. IMHO
> is a bug and not a wishlist. If you think I can try to understand
> understand KMail and write myself this feature, but you can do this
> faster because you know perfectly how POP3 filters works. Let me now
> something.

There are perhaps some glitches in the POP3 filter configuration. But when you file a bug report, then the programmers can expect you to

a) have understood how KMail deals with a certain issue
b) describe _clearly_ what (in your opinion) needs to be improved
c) have understood that improvements are usually _no_ bugs

Please understand that I have to close this report because it doesn't 
contain enough valuable information. Feel free to file a new wishlist 
report with a detailed and clear description.
Comment 2 Ingo Klöcker 2004-02-11 14:08:43 UTC
Actually I do understand what Giovanni is talking about. At least I'm pretty sure I do. ;-)

Currently the standard action for messages which don't match a POP filter is "download later". Giovanni proposes to change this to "download" and to optionally allow the user to change the fallback behavior.

But that's definitely a wish and not a bug.
Comment 3 Giovanni Venturi 2004-08-26 17:14:00 UTC
So, for a next KMail version we can do something to do this? I think it's very 
annoyng to reply KMail dialogs what to do if a rule doesn't match. We can fix 
a standard policy to download and the possibility to change that policy. This 
is a good usability request. If you're coding some other part ok KMail code 
tell me you is responsable for POP3 filter. Tank you.

Comment 4 Gilles Schintgen 2005-04-03 18:33:22 UTC
It would definitely be nicer if the default action would be "download". After all, POP filtering is only intended to filter out some unwanted messages.
This is also mentioned in bug 79694, so this one could perhaps be marked as a dupe of 79694 (which combines most of the usability problems with pop filtering).
Comment 5 Björn Ruberg 2009-12-19 00:05:04 UTC

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