Error with EMTPY_MESSAGE

[Glenn Steen]

2008/9/14 Hugo van der Kooij <hvdkooij at vanderkooij.org>:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Glenn Steen wrote:
>> 2008/9/13 Hugo van der Kooij <hvdkooij at vanderkooij.org>:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> Glenn Steen wrote:
>>>> 2008/9/13 Hugo van der Kooij <hvdkooij at vanderkooij.org>:
>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>> Hash: SHA1
>>>>>
>>>>> Hugo van der Kooij wrote:
>>>>>> Hi,
>>>>>>
>>>>>> It seems to me that SA is flagging just about any message as EMPTY_MESSAGE.
>>>>>>
>>>>>> Is anyone else seeing this too?
>>>>> I just had quite a bit of a discussion about malware that just walks
>>>>> past MailScanner with multiple AV scanners active.
>>>>>
>>>>> It seems that it might be related to postfix. Where MailScanner is
>>>>> trying to decode postfix queue files but not doing the right thing.
>>>>>
>>>>> My result on 3 sample queue files was 0% through MailScanner. But
>>>>> decoding them with postcat allowed me to hit 100% of the files.
>>>>>
>>>>> So the issue may require all postfix users to look very carefully into
>>>>> their messages and the ability to scan them properly.
>>>>>
>>>>> Hugo.
>>>>>
>>>> Can I get a sample, please? Send it off-list.
>>>> Do you do milters? Which milters? Version of postfix?
>>> I use postfix 2.3.2 as it is the normal shipped package for Centos 5.
>>>
>>> Hugo.
>>>
>> Just to give a little update:
>>
>> I've received queue files from Jules and Alex B. I've fed these
>> through both a testbed and our current production .... And they simply
>> worked as expected(!)... The zip-file they included got unpacked
>> nicely, the filename _and_ filetype got it into the quarantine, as
>> well as all my AVs firing like mad:-).
>> This was on a Mandriva 2008.1 running perl 5.10.0 with MailScanner
>> 4.71.10 ... latest stable and beta are essentially the same, so ...
>>
>> I'm leaning toward this being related to CentOS 5.2, possibly the
>> relevant perl modules.
>> Further than that is pretty hard for me to check, since I cannot
>> reproduce the problem.
>> I might get onto Alexs' testbed, to do some further debuging... But I
>> do suggest that you who have a CentOS 5.2 box and are affected by the
>> "non-unpacking" (should be easily determined... look for "Your
>> internet access is going to get suspended" subjects that are either
>> improperly unpacked (in the quarantine) or that slip by entirely...
>> grab one and start feeding it through your system, varying your perl
>> modules (mainly MIME-Tools related stuff, I'd guess).
>
> I have only seen the issue with queue files from Alex. And the odd
> EMPTY_MESSAGE report I found myself.
Yes, well... they seem to be indacations of the same thing. So far
only observed on CentOS 5.2 boxes (I've had reports that it's working
OK on Slackware as well as Mandriva).
The problem is that the "exploding" of the message as read from the
queue file fails. It simply returns nothing.
Not that the message is malformed in any special way.
Since I don't have this problem (with Alex files), I can't go much
further there.

> I shoot down almost all other stuff on non FQDN issues and blacklisting
> dialup networks based on keywords in their hostname in postfix itself.
> So I can not recall to have seen messages sneak past with attachments in
> them.
As do we all, so it is a very marginal thing,if a problem at all. I think:-).

> The attachment thing might be a combined thing of a new postfix building
> queue files slightly differently. But beyond the test messages I have
> never seen that issue arise.
There is no difference that the queue file decoding code would fall
afoul of. The same code Just Work(tm) for me on my testbeds (and on my
production, used for reference during my testing:-).

> But if a beta version can be created that allows one to use postcat
> instead of a native MailScanner parser of the raw queue file just to see
> if it is a factor then I can test that as my MailScanner server is
> pretty low in traffic.
Not really doable, not really where the problem is at, unfortunately.
It's more insidouos than that:-).

> Hugo.
>

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se