Allow junk mail filter whitelisting by addressee / recipient / To: address



14 years ago
9 years ago


(Reporter: johann.petrak, Unassigned)


(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [doc][workaround comment 10])



14 years ago
I think many people in the meantime have several email addresses in parallel,
somtimes as simple aliases, where an old or public email receives a lot of spam,
while some special alias is kept "secret" only within a small group of selected
users. Naturally, the latter is/are the addresses where one receives important
emails and where the likelyhood of spam is low. Therefore, in order to avoid the
risk of false positives, it would be good if the junk mail controls would allow
to whitelist these selected recipient addresses so that junk filtering is not
done on them.

Comment 1

14 years ago
Putting those addresses in your address book does not whitelist them 

Comment 2

14 years ago
No - the option that is currently present whitelists by sender, not recipient. 

Comment 3

14 years ago
I think the UI should be identical to what is already there for whitelisting by
sender: just add a new section titled "Do not mark messages a junkmail if the
recipient is in my address book". 

Apart from aliases as stated in my first comment, different recipients could
also be relevant e.g. when emails are auto-forwarded from another email address. 

Comment 4

14 years ago
Hmmm, I wonder if it would not be sufficient to just add a checkmark to the
whitelist section that would read "also check recipient". So the same address
book would be used for both the senders and allowed recipients. That would mean
less clutter than repeating the whole section for recipients (and it would make
it easier to implement the backend :) )
With that simplified UI I could probably come up with a patch. 

As far as I can see there is no way to put that into an extension, so before I
invest work into this I would like to know how one can find out if somebody
would actually be willing to check this functionality into TB?


14 years ago
Summary: Allow junk mail filter whitelisting by addressee / recipient address → Allow junk mail filter whitelisting by addressee / recipient / To: address

Comment 5

14 years ago
A very closely related enhancement is to allow specification of multiple
address books in this option.  I have my senders segregated into two 
address books, one for personal and one for work, and as it currently
stands I can't get TB to check both address books for whitelisting.

Comment 6

14 years ago
The way to implement this would probably be to modify the backend code to
respect a preference - this would be identical for Mozilla and TB - and a
frontend to set that preference - this could potentially be different between
the two. 

Comment 7

12 years ago
you can always define a message filter that checks the recipeint and marks the message as non-junk.

Comment 8

12 years ago
Junk marking doesn't seem to happen until you view the folder in question.

I have a bunch of filters that move mailing list messages to various subfolders.
These filters operate as the mail comes in, but the junk filter isn't applied
until I actually visit the subfolder.  When I open the subfolder I can see some 
messages being marked as junk and then disappearing as they are moved to the
junk folder.

Comment 9

12 years ago
(In reply to comment #8)
> Junk marking doesn't seem to happen until you view the folder in question.

That's bug 200788.  Please don't post in bugs without reading them and understanding them -- clearly, this bug has nothing to do with that problem.

Comment 10

12 years ago
In any case, if you add a filter action to mark a message as non-junk, in the same filter as moves the message, the junk filter won't fire on that message, because we don't do junk mail analysis on messages that have been already marked as non-junk.
QA Contact: general
Assignee: mscott → nobody
moving to account manager, where whitelist resides
Component: General → Account Manager
QA Contact: general → account-manager
Whiteboard: [doc][workaround comment 10]
You need to log in before you can comment on or make changes to this bug.