User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 Most of the junk email I receive has a generic sender address like @yahoo. or @hotmail.com. Most have an unsubscribe option contained within the body of the email that say "click HERE to unsubscribe". The "HERE" word is highlighted because it contains a link. the "BODY" filter option should be able to search these links for text as well because the link is very consistant, whereas the sender address is not. Reproducible: Always Steps to Reproduce: 1. In mail, click on tools, filters, and edit or add a new filter 2. The filter should be set to "match any of the following" 3. set the BODY to CONTAINS any link, like www.junkmail.com Actual Results: The messages were not filtered out Expected Results: It should have found the link text in the body of the email and performed the appropriate MOVE action.
Original summary: "when incoming mail is filtered, url links that are contained within the body of junk email are not searched." duplicated with 1.3 Final, 1.4b-0430
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: when incoming mail is filtered, url links that are contained within the body of junk email are not searched. → href's of url links contained within HTML message body are not scanned by Body:Contains filter
*** Bug 204557 has been marked as a duplicate of this bug. ***
Assignee: naving → sspitzer
This may qualify as a dupe of bug 144036, which is about generally filtering on the HTML source of a message.
I think I see this bug in non-junk e-mails on build 2003072204. In the attached message, the links at the top of the page do not work in Mozilla, but do work in IE.
The links at the top do not work
I think I now see this all html mail messages. For example, the Sun Core Java Technologies newsletter. The article links which refer to links such as "/#2" return "is not a registered protocol" message when clicked.
James Rome, I believe you have misunderstood this bug entirely. This has nothing to do with whether links 'work'; it has to do with whether the href of the link is parsed by message filters.
I keep getting accused of not searching the database before I file a new bug, so I will transfer my comments to a new bug 215248.
Still present in 1.6. I tried to set a filter for a particular spam I've been getting, but the filter won't recognize the url.
This problem has been occuring ever since mail filtering was introducted. and still exists in Mozilla 1.6 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 If I understand the reported bug correctly, then the filter will not scan for "asd.asd" in the following example, but will find "dfgdfg." <A href="asd.asd"> dfgdfg </a> and yes, that is the exact problem that I am having. My immediate question is why it appears to be scanning the rendered html rather than the RAW message format.
I have tried this and agree that it is a bug and should be fixed. It would be very valuable in eliminating spam if I could use a URL link contained in the body of an email to identify it as spam.
I've tested this in TB 1.5 and SM 1.1 -- it's working now for the general case, for POP. (No body search for IMAP, of course... bug 67421.) I noticed that if I download headers-only, the fetch of the actual message doesn't seem to be filtered, but I think that may be a general issue with filtering on the body when headers-only is enabled.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.