href's of url links contained within HTML message body are not scanned by Body:Contains filter

RESOLVED WORKSFORME

Status

MailNews Core
Filters
RESOLVED WORKSFORME
15 years ago
10 years ago

People

(Reporter: Christopher Tobar, Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
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.

Comment 1

15 years ago
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

Comment 2

15 years ago
*** Bug 204557 has been marked as a duplicate of this bug. ***
mass re-assign.
Assignee: naving → sspitzer

Comment 4

15 years ago
This may qualify as a dupe of bug 144036, which is about generally filtering on 
the HTML source of a message.

Comment 5

15 years ago
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.

Comment 6

15 years ago
Created attachment 128501 [details]
example of bad linkjs

The links at the top do not work

Comment 7

15 years ago
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.

Comment 8

15 years ago
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.
(Reporter)

Comment 9

15 years ago
Created attachment 129260 [details]
Example of email with links that the filter did not find

Comment 10

15 years ago
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.

Comment 11

15 years ago
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.

Comment 12

15 years ago
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. 
Product: MailNews → Core

Comment 13

14 years ago
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.

Comment 14

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