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.
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: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.