Created attachment 3948 [details]
example message that is parsed/rendered by Outlook but not parsed by SpamAssassin

example message that is parsed/rendered by Outlook but not parsed by
SpamAssassin

Clicking the Security Team checkbox in Bugzilla. Apparently default is now to
leave a new security bug visible. At least we no longer also by default mail it
to the public list.

Does anyone know how to configure Bugzilla to fix this part too?

(In reply to comment #2)
> Clicking the Security Team checkbox in Bugzilla. Apparently default is now to
> leave a new security bug visible. At least we no longer also by default mail it
> to the public list.
> 
> Does anyone know how to configure Bugzilla to fix this part too?
> 

Are you sure that bugs marked as "Security" visible publicly? I know I could
never see bugs marked as this before I got a higher user level in BZ.

there's the two bits that need checking, and usually only people select one of
them.  there's no way to tell bugzilla to auto-check the second one, but I wrote
in a small hack into our BZ code to do it.  I'm not sure if that got taken out
at some point since we converted to the ASF BZ.  (in theory our customizations
should still be there, but...)

since I'm not a member of the security team, that 2nd checkbox didn't even
appear to me until someone else checked it.

[in reply to Coment #3]

> Are you sure that bugs marked as "Security" visible publicly?

That's determined by the checkbox, not Component == Security. Perhaps you never
happened to look at such a bug before someone in the Security group noticed and
fixed it. I know that at least once I discovered that a Security bug was visible
when I tried to add a comment and discovered that I was not logged in.

Anyway, I'm seeing more of these now.... Does anyone have any comments?

Created attachment 3950 [details]
another example.  a plain html URI this time.  Outlook renders this one just fine, as well.

Note that all the parts were encoded as binary.  Also, this was not an image
URI, this is a clickable URI.

Let's see if I understand this correctly. In the second example, as far as I can
tell SpamAssassin parses the URIs ok, so that isn't a problem. Thunderbird also
displays it as HTML, so Outlook is not being particularly confused in this case.

In the first example, you have multipart-related with the type of the first part
declared to be multipart-alternative, which it is. That first prt is a
multipart-alternative with two parts, a text and an html part, both consisting
of a blank line. After the final end-of-section marker for the message, there is
some HTML text which contains the spam message.

You are claiming that Outlook renders an HTML document that comes after the
final MIME end of message indicator, and Spamssassin ignores it, or at least
doesn't parse it as HTML.

Can anyone else who has a copy of Outlook reproduce this? Which versions of Outlook?

Does Outlook Express do the same thing?

Do you have any idea how Outlook decides that this thing is supposed to be HTML
and renders it that way when there is no MIME header indicating that it is HTML?

(In reply to comment #9)
> Let's see if I understand this correctly. In the second example, as far as I can
> tell SpamAssassin parses the URIs ok, so that isn't a problem. Thunderbird also

I don't think that SpamAssassin parsed the URIs okay, because otherwise a URIBL
hit on that domain would have appeared.  

> displays it as HTML, so Outlook is not being particularly confused in this case.
> 
> In the first example, you have multipart-related with the type of the first part
> declared to be multipart-alternative, which it is. That first prt is a
> multipart-alternative with two parts, a text and an html part, both consisting
> of a blank line. After the final end-of-section marker for the message, there is
> some HTML text which contains the spam message.
> 
> You are claiming that Outlook renders an HTML document that comes after the
> final MIME end of message indicator, and Spamssassin ignores it, or at least
> doesn't parse it as HTML.

Ah; I see, now.  In that case, this is a duplicate of
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=5393 and also confirms
that Outlook 2003 and 2007 are vulnerable to this, and are being increasingly
exploited.

> 
> Can anyone else who has a copy of Outlook reproduce this? Which versions of
Outlook?

2003 and 2007 render the first example.  I can provide a screenshot if you'd
like.  If necessary, I can provide a vm image (for any vm host) of WinXP with
both Outlook 2003 and 2007.

> 
> Does Outlook Express do the same thing?
> 

I don't know, but again, I would be glad to provide a vm image for testing.

> Do you have any idea how Outlook decides that this thing is supposed to be HTML
> and renders it that way when there is no MIME header indicating that it is HTML?
> 

Good question... maybe Outlook is "smart" that way. :)

*** This bug has been marked as a duplicate of 5393 ***

I'm removing the security designation of this bug. It isn't a general way to
bypass SpamAssassin filtering as it only works for a few MUAs (and makes things
worse for the spammer on the rest of the MUAs), and it is a duplicate of a bug
report that is already public.