Hi Rafters -
FromTheRafters said:
Below is the type of Swen message that has been stopped by the OE Rule now
in place as I have described. This type of message is showing up in my
Inbox.
[snip]
FROM: "MS Security Services" <
[email protected]>
TO: "Customer" <
[email protected]>
Sorry I'm so slow to understand, but is the effective rule here
the "From contains 'MS'" rule or the "not addressed to me"
rule.
You can update the information on this by reviewing your reply on 10/03/03
at 7:48p above in this thread regarding the rules I have had in place, and
testing with. And, my answer on 10/03/03 at 9:38p (this only to save
resources by not repeating the same information..<bg>). I did try the 'not
addressed to me', but it proved useless overall, even with the rest of the
messages. Seemed none but the spam care who the message was addressed to.
But, yes...the Rule is 'From contains M, MS, Microsoft'.
The following message is a sample of the type that is being downloaded in
spite of the Rule in place.
[snip]
FROM: "Microsoft Security Center" TO: "Client" <jpykttgv .dororv@supp
Here, "From:" still contains "M", but "To:" doesn't have it's own line.
There was an issue some time ago where an AV product parsed the
header for "Content-Type" to check for "Incorrect MIME type" or
was it "Malformed header" vulnerability, a vulnerability in that routine
was found in that the "Content-Type" search was looking for an exact
(case sensitive) occurrence of "Content-Type" whereas the e-mail
system didn't specify that string be an exact case sensitive string
in order to work. E-mails crafted with "cOntEnt-TypE" were treated
by the e-mail programs as legitimate, but the AV would entirely miss
them and find no "Content-Type" to check against the filename for
a type mismatch.
Yes...in regards to your comment on the case-sensitive issue...as I did try
various settings using all lower case, all upper case, normal
capitalization, etc. One thing I did find..using the same text format as in
the message does not 'always' work. So, I came to the conclusion, and
perhaps wrongly, that the issue might be more the exact wording, and not so
much the text case.
'k.....as an example, in a message regarding ..eh....Viagra....where the
Subject line contained V I A G R A, as opposed to Viagra. In keeping with
the theory of replicating the exact wording, I entered this in the Rule.
This did not stop the message with V I A G R A from coming through. Then I
went back and used V i a g r a, and I did not get any more messages that had
V I A G R A in the subject line. Now...at other times, the exact wording
worked just fine, such as with messages about ...ahmm ... well..... various
personal adjustments. So...go figure???
So is this another case of "brain dead" OE not even seeing "FROM:"
as "From:" and "TO:" as "To:" when filtering is being used?
I don't know...while for the most part there seems to be consistency in how
the rules work, there are times when OE appears to be oblivious to what it
is being fed.
...and does OE's filter algorithm only look for the from and to
as the start of a new line?
It would seem that it needs specific information before it seems to even
realize something is there. This is something that is built into the
program. The whole idea seems to be, to get the message downloaded to the
hard drive. It does not appear able to deliver it's payload if it is not
downloaded, so the whole intent is get it downloaded. MailWasher is not an
MS program, but OE is. Perhaps if someone is capable of writing a program to
use and affect MS programs and products to such an extent, is it not perhaps
possible that they have found a away to cloak these messages from the OE
brain works? However, this is mere speculation on my part, I really don't
know. But, it would seem that if they are capable of writing something this
damaging, they could be capable of anything.
A "yes" to either of those questions wouldn't really surprise me.
Hopefully someone with SMTP knowledge will help here. If the RFC
doesn't specify that "From:" be used rather than "FROM:", and that
each of the "From:" and "To:" be on a separate line, then OE should
have its filters make up for the disparity by checking for each of the
possibilities.
But Rafters, is it capable of doing this? Perhaps it is because it has not
run into this situation before, so, it does not know how to adjust to look
at data in any other way than it has been initially programmed to do. It has
been pointed out in this thread in various ways, OE can't think for itself,
it can only see and react to what it has been programmed to see and do. It
just runs data, it does not create data. It can not change the way it sees
or reacts to specific data as it is presented at it's door. But, that is
not to say that someone can't change the data on the other side of the door
to confuse. ???
I am in hopes that someone can shed some specific light on this. We know
Swen is not going to go away soon, and from the looks of it, it will be
taking on many different forms to find a way to deliver it's payload. That
is it's only objective.
Curiosity it what unlocked the secrets of the universe. To merely dismiss,
is to miss an opportunity to learn and grow.
Thank you very much for your time and additional input and information. I do
appreciate it.
