http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4695
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #3341 is|0 |1
obsolete| |
------- Additional Comments From [EMAIL PROTECTED] 2006-01-25 03:48 -------
Created an attachment (id=3342)
--> (http://issues.apache.org/SpamAssassin/attachment.cgi?id=3342&action=view)
patch take 3
3341 is bad news :(
It turns out that use of HTML::Parser->empty_element_tags() allowed a number of
HTML obfuscations past, demonstrated by uri.t test failures:
t/uri....1..82
# Running under perl version 5.008007 for linux
# Current time local: Tue Jan 24 18:39:55 2006
# Current time GMT: Wed Jan 25 02:39:55 2006
# Using Test.pm version 1.25
got URIs: http://163.125.6.199/ATV, http://2742879943/ATV, http://66.92.69.222,
http://0x425c45de, mailto:[EMAIL PROTECTED], http://66.92.69.221,
http://66.92.0x45.221, http://66.92.69.223, http://1113343455,
http://[EMAIL PROTECTED]/, http://1113343456/, http://66.92.69.224/,
http://62.16.101.59/livesex.htm, mailto:[EMAIL PROTECTED],
http://spamassassin.org, http://spamassassin.org, spamassassin.org
ok 1
ok 2
not ok 3
# Failed test 3 in t/uri.t at line 45
not ok 4
# Failed test 4 in t/uri.t at line 46
not ok 5
# Failed test 5 in t/uri.t at line 47
If we ignore that and instead 'hack' fix with a simple s/// substitution, it
works, and those obfuscations are caught again. so this patch just does that.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
