NOD32 for Linux Mailservers crashes on 1-line text message

A one line text message, properly encoding and containing just the following line, causes the error "not scanned (archive error)" and the message is rejected and send back to the sender.

Text line:
Content-Type: multipart/; boundary="-"

This is NOD32 for Linux Mailservers Version 2.70.
The same error was already reported for Version 2.52:
https://www.wilderssecurity.com/showthread.php?t=130775

Logfile (msgid removed):

Object AV scanned with status 'not scanned (archive error)'
vdb=9896, agent=mda, msgid=<...>, object="email message", name="mail", virus="is OK", action="", info="", lines=2
vdb=9896, agent=mda, msgid=<...>, object="email message", name="mail -> MIME -> part000.txt", virus="is OK", action="", info=""
vdb=9896, agent=mda, msgid=<...>, object="", name="mail -> MIME -> part000.txt -> MIME", virus="", action="", info="error occurred while reading archive"

As this error also occures sometimes on normal MIME messages with multiple attachments, I use the following workaround filter which captures the error and forwards the message unscanned with a warning added later to the subject "[NOD32 failed NOT scanned vor Virus!]":

if ! tee $TMPFILE | nod32mda -oi -oMr virusscan-ok $*; then
cat $TMPFILE | formail -I "X-NOD32Result: error" | exim4 -oi -oMr virusscan-error $*
fi

 

are you saying that a message that purports to be multi-part and yet isn't is the problem?

 

There's no purpose of using such a one line message, NOD32 has evaluated it correctly IMHO.

 

I have kind of thinking the same thing - if a text only email pretends to be the start of a multi-part message and then fails to deliver anything more, it's a bogus email with no potential for harm anyway - right?

 

The problem of course is not that one line message itself. The error occurs with some normal MIME messages with attachments and with virus attached messages. The virus messages are not a problem as they are thrown away anyway, but the error with normal messages is a problem. To reduce the problem to its simplest form, that one-line message is used.

That one-line message is a valid MIME message. As you can see in the first attached message below, the header does not tell anything about multipart-MIME and does not define a MIME-boundary, so the text-line in the body is just normal text and is not to be interpreted by any MIME parser.

The 2nd attached message throws the same error in NOD32 and is a multipart-MIME message as you can see by the definition of a MIME-boundary in the header. The one-line text is in this case just normal text, too and not to be interpreted as the MIME-boundary is already defined in the header.

**************************************************************

Mime-Version: 1.0 (Apple Message framework v752.3)
X-Gpgmail-State: !encrypted
Content-Type: text/plain;
charset=US-ASCII;
format=flowed
Message-Id: <[...]>
Content-Transfer-Encoding: 7bit
From: <from@sender.com>
Subject: test
Date: Thu, 24 May 2007 11:02:08 +0200
To: <some@address.com>

Content-Type: multipart/; boundary="-"

**************************************************************

Mime-Version: 1.0 (Apple Message framework v752.3)
Message-Id: <[...]>
Content-Type: multipart/mixed;
boundary=Apple-Mail-1--93349897
To: <some@address.com>
From: <from@sender.com>
Subject: test
Date: Fri, 25 May 2007 09:15:12 +0200


--Apple-Mail-1--93349897
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=us-ascii;
format=flowed

Content-Type: multipart/; boundary="-"

--Apple-Mail-1--93349897
Content-Type: multipart/appledouble;
boundary=Apple-Mail-2--93349897
Content-Disposition: inline


--Apple-Mail-2--93349897
Content-Transfer-Encoding: base64
Content-Type: application/applefile;
name=test.png
Content-Disposition: inline;
filename="test.png"

AAUWBwACAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAJAAAAMgAAAAoAAAADAAAAPAAAAAoAAAAAAAAA
[...]
ABAAQmlsZCAxLnBuZw==

--Apple-Mail-2--93349897
Content-Transfer-Encoding: base64
Content-Id: <[...]>
Content-Type: image/png;
x-mac-type=0;
name=test.png;
x-unix-mode=0644;
x-mac-creator=0
Content-Disposition: inline;
filename="test.png"

iVBORw
[...]
FTkSuQmCC

--Apple-Mail-2--93349897--

--Apple-Mail-1--93349897--

**************************************************************

 

are you saying that ALL multipart messages are skipped?

 

No, only some multipart messages are causing the error. Maybe it depends on the characters used for the MIME-boundary string. As the workaround with capturing the exitcode worked, I did not investigated the problem further.