Jump to content

IMAP fetch body[text] problem


stemly
 Share

Recommended Posts

Implementation of Email protection IMAP protocol command FETCH number BODY[TEXT] is wrong in ESET Enpoint Antivirus version 5.0.2228.1.

For some reason Antivirus protection rewrite request to FETCH number (UID BODY[HEADER] BODY[TEXT]).

Unfortunately it does not rewrite response to just BODY[TEXT] part it could cause trouble for some clients.

We identify it when testing Java Mail library version 1.4.5+.

Java mail does not expect that response contains more then just text part of body.

Link to comment
Share on other sites

  • ESET Staff

Can you be more specific please? What kind of trouble are we talking about? Do you have a sample code that causes this behavior? What is your planned usage for the library? Thanks.

Link to comment
Share on other sites

Here is sample what you get when you call FETCH number BODY[TEXT]
 

? FETCH 2 BODY[text]
* 2 FETCH (BODY[text] {238}
--089e0115f0a2e0591904f93927a8
Content-Type: text/plain; 
charset=UTF-8

sample body

-- FLAGS 
(\Seen))
? OK FETCH completed

 and here is what you get when Email client protection is enabled

? FETCH 2 BODY[TEXT]
* 2 FETCH (UID 47 BODY[HEADER] {2701}
Received: from fernet.xx.sk ([172.19.2.100])
          by mark.xx.sk (Lotus Domino Release 8.5.3FP3)
          with ESMTP id 2014051221432296-70770 ;
          Mon, 12 May 2014 21:43:22 +0200
Date: Mon, 12 May 2014 21:43:04 +0200
Message-ID: <CAFAYK4GK1xb0ucfnWt6JJEWvuP-YmkhFQP=VS+Qa=K__wFWeQQ@mail.www.com>
Subject: test
From: Stefan *** <stefan.***@www.com>
To: "Test" <test@xx.sk>
Content-Type: multipart/alternative; boundary=089e0115f0a2e0591904f93927a8
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=www.com; s=20120113;
        h=mime-version:date:message-id:subject:from:to:content-type;
        bh=e8X/iuYRN/E8j7XazY5VETM56uX3v3uCX0W+7+r4zSQ=;
        b=uLkZRVRQxSBYqDFVa05QnVwkVxm7DKxngseDVTwHlb6jDJGo4Xy+5xnPHc/pfRGP2O
         zK6RCCK7PzeIUDKozRT7nTTHV31VuVYCj78dZ9I2Jf+J1IBB25vgTvP4XYRSleRSiJzv
         JDh/whdLiyeaewrCB345A85ujashq+SctgfgKaAEY9xBd78w+WNEZMXykTODS3bW8rgZ
         X33Vfjo6xMrcKneg6ecxrroXjDNtW0iq3Zq+Gc9P1dtKiDB9X7APyC1T2kL5R8+ywA6b
         z8jbs8AGtrr3tTFMKAiZjx5Gf58zGO4/gRMO1GRA1gzOz9KMctK+mc3YLdYQkxFwv5A/
         ySsA==
MIME-Version: 1.0
X-Received: by 10.58.123.71 with SMTP id ly7mr24644964veb.11.1399923784307;
 Mon, 12 May 2014 12:43:04 -0700 (PDT)
X-Virus-Scanned: Maia Mailguard 1.0.2a
X-Spam-Status: No, hits=-1.72 tagged_above=-999 required=5 tests=AWL=-0.340,
 BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SPF_PASS=-0.001,
 TVD_SPACE_RATIO=2.219
X-Spam-Level:
X-MIMETrack: Itemize by SMTP Server on Mark/xxx Bratislava(Release 8.5.3FP3|November
 15, 2012) at 12. 05. 2014 21:43:22
X-TNEFEvaluated: 1

 ENVELOPE ("Mon, 12 May 2014 21:43:04 +0200" "test" (("Stefan ****" NIL "stefan.***" "www
.com")) (("Stefan ***" NIL "stefan.***" "www.com")) (("Stefan ***" NIL "stefan.***" "www.com")) (("Test" NIL "test" "www.sk")) NIL NIL NIL "<CAFAYK4GK1xb0ucfnWt6JJE
WvuP-YmkhFQP=VS+Qa=K__wFWeQQ@mail.www.com>") BODY[TEXT] {238}
--089e0115f0a2e0591904f93927a8
Content-Type: text/plain; charset=UTF-8

sample body

--089e0115f0a2e0591904f93927a8
)
? OK FETCH completed

So problem is that Java library asked by IMAP  command ? FETCH 2 BODY[TEXT] and is expecting just text part of Mail body, but Email client protection rewrite request to

? FETCH 2 (UID BODY[HEADER] BODY[TEXT])

and response contains more data than Java mail library is expecting
 

Edited by stemly
Link to comment
Share on other sites

  • ESET Staff

What you're describing here looks more like a problem in the mentioned Java library, since it understands only a subset of allowed IMAP constructs instead of parsing everything the server is allowed to send. In particular the RFC never mentions that the server SHOULD, SHALL or MUST send only the requested items. Somewhat to the contrary it allows the server to send FETCH responses by unilateral decision (see hxxp://tools.ietf.org/html/rfc3501#section-7.4.2).

 

The reason I'm asking for sample code and intended usage is that I can change the protoscan behavior so that it can be used with the Java library. From the communication you sent it is e.g. not clear why the client is requesting only message body and no headers. Are the headers cached client-side? In such case the clients are usually robust enough to handle such counter-intuitive responses. Or was it sent during previous communication? Protoscan attempts to cache such transmissions, and asks for headers only if they're not cached.

Edited by MMx
Link to comment
Share on other sites

  • 2 weeks later...
  • 8 months later...
Guest
This topic is now closed to further replies.
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...