Open
Bug 180138
Opened 23 years ago
Updated 3 years ago
filter rule for domain is/isn't in my address book (cards)
Categories
(MailNews Core :: Filters, enhancement)
MailNews Core
Filters
Tracking
(Not tracked)
NEW
People
(Reporter: tomm, Unassigned)
References
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021113
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021113
For the anti-spam effort I think it makes more sense to manage a list of people
I will accept mail from rather than the list I will reject. The first list is
much shorter. With 1.3 I can accept only email from addresses already in my
Address Book - it is great. But client personnel change. So, in my dreams, I
would like a managed list of domains I would accept email from regardless of
username. E.g., mail from tom@myclient.com and/or email from myclient.com if I
added myclient.com to domain list. With these two features I control who can
reach my inbox.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
With regular filters you can do "from" "contains" "@myclient.com"
In what way does this request extend that?
I don't think it's the job of the address book to contain just domains, and
creating a seperate component just to store such a list would seem to me to be
WONTFIX.
Comment 2•23 years ago
|
||
I think this is a valid request. In addition to "is in my address book" and
"isn't...", there could be criteria: "domain is among the domains of email
addresses in my address book" and "domain isn't...". As that's just a tiny bit
too long, I'll leave the rewording for a native English speaker. ;-)) The point
is, Sander, we don't need a special component for storing domain names, nor do
we need to store domain names in address books. We can simply use the domains
from email addresses.
Ah, agreed. Confirming, although I still it'd be overkill. :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•22 years ago
|
||
Can we get the view by Sent To option added, as it is very ddifficult to sort
sent items easily without it.
Updated•21 years ago
|
Product: MailNews → Core
Comment 6•18 years ago
|
||
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Comment 7•18 years ago
|
||
mod summary
related bug 237924
QA Contact: laurel → filters
Summary: Request ability to create filter rule which will process email based upon senders domain. → filter rule for domain is/isn't in my address book (cards)
Comment 8•18 years ago
|
||
(In reply to comment #0)
[...]
> For the anti-spam effort I think it makes more sense to manage a list of people
> I will accept mail from rather than the list I will reject. The first list is
> much shorter.
[...]
I believe both approaches will make sense for different people. My approach is that anyone may send me mail, but it had better not be UCE/UBE in nature. I have an already substantial list of "known friendly sources" (between 10 and 20 I think, not counting the whole of my address book) and a much, much shorter list of "known hostile sources" (one or two known trolls); anything else will be handled (cautiously at first) by eye and hand, after Bayesian pre-sorting among the Junk and Inbox folders. Personally I don't feel the need for a long blacklist but of course, other people may... In my experience, trying to catch spammers by means of a fixed blacklist is a thankless job because spammers use constantly-varying phony fromlines anyway. (Online DNSBLs, some of which will list an IP-quad within hours of onstart, and unlist it a day or so after cessation, are a different matter.)
Tomm, I might say that to me too, it makes sense to manage a list of people and domains whose mail I shall always accept, but for the opposite reason to yours: my blocklist is so small it could never become a hassle. :-)
Assignee | ||
Updated•17 years ago
|
Product: Core → MailNews Core
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•