SA is kind-of doing the right thing -- Outlook Express highlighted several 
lines of text in your message as URLs.

Since they are theoretically clickable-upon, it makes sense to check them as 
URLs.

I'm attaching a screenshot so you can see what I mean.

I don't see the screenshot attachment, but I don't think that Outlook Express
finding URLs in my bug report means anything in this case.

My bug report does have URL looking things that begin with http://. But part of
the bug is that SpamAssassin added those http:// strings itself... They were not
in the message body.

And first of all, SA should not be looking for URIs in the rawbody text of MIME
attachments. That should be done in the decoded body.

Secondly, looking at PerMsgStatus.pm I see that SA is trying to guess at
relative URLs. It is true that if a host name like www.foo.com or ftp.bar.edu
appears in the body then some mail software will make it a hot link. SA deals
with that by prefixing http:// to it in order to make it a URI. That seems to be
what is going on here. But H86QL96YG:6YG('1A<lotsofstuff>0,;V8@=&AE does not
look like a www.* or ftp.* host name and should not be treated the same way.

It appears that foo:bar is treated as a URI, www.example.com is turned into
http://www.example.com and is treated as a URI. foo:bar<baz>glug is turned into
http://foo:barglug and is treated as a URI and that is wrong. If the 'foo:' is
treated as a URI scheme, then it definitely should not have http:// tacked on to
the beginning of it. And what sense does it make to remove the embedded <...>
string?

Plus all this is being done to raw BASE64 characters that certainly are not URIs.

I'm afraid that I am not familiar enough with Perl to know how to fix the
relatively complicated code in PerMsgStatus.pm that handles the URIs. My guess
is that the problem is somewhere in do_body_uri_tests, but perhaps it is also in
how it is called.

Subject: Re: [SAdev]  URI processing turns base64 strings into http URI's which then match rules

For some reason, I can't access Bugzilla at the moment to post the image, so
it can be seen at http://blazing.arsecandle.org/~rod/urls.png

Ok, I see the screenshot. The strings that Outlook Express is underlining have
nothing to do with the strings that SA thinks are URIs. All this shows is that
Outlook Express can get very confused when handed BASE64 encoded files as plain
text. If anything it just emphasizes that SA's URI parsing should not be done on
the rawbody in the first place. Note that Outlook Express would never see these
strings in this way, it would decode the BASE64 MIME attachment first.

Is that even Base64 encoded?  It looks like UUEncoding to me.

Dan.

Duh! Yeah. Is it too late to change the title of the bug repoort? :-)

Replace every mention of 'BASE64' above with 'uuencoded'. Sorry about that. But
the bug still stands. The Word attachment still was flagged with three different
kinds of spammy URIs that are not there.

Does anyone want to try it out with BASE64 attachments to see if it still happens?

Subject: Re: [SAdev]  URI processing turns base64 strings into http
 URI's which then match rules

Right, and therein lies the problem - SA doesn't decode UUencoded stuff 
(yet?).

I've got some code that plugs into my earlier posted mail parser to do 
UUE extraction, but I think both Craig and I discovered that SA needs a 
bit of a re-write in order to make use of a proper mail parser (either 
MIME::Tools based or my parser based).

Matt.

There's still another bug besides not decoding uuencode.

I don't know enough Perl to propose a patch yet, but I think I found the 
offending line of code. In PerlMsgStatus.pm lines 1318 to 1321 in my current 
cvs version, it says

 # Does the uri start with "http://", "mailto:", "javascript:" or
 # such?  If not, we probaly need to put the base URI in front
 # of it.
 if ($uri !~ /^[a-z]+:/i) {

But $uri was set using an expression that includes $uriRE which is defined in 
terms of $schemeRE and $schemelessRE in line 1246. There you see that the 
scheme can have non-alphabetic characters before the :. The result of this bug 
is that a URI with nonalphabetic characters gets a http:// tacked on in front 
of it.

An approximate fix would be to change the if expression above to

 if ($uri !~ /^[a-zA-Z][a-zA-Z0-9.+\-]*:/)

which better matches the definition of $schemeRE, or even better if this works 
(remember I don't know Perl)

 if ($uri !~ /^$schemeRE:/)

ok, I've locked that down by explicitly listing protocols.
I don't think that's going to cause any more trouble than it
already is ;)