[exim-dev] [Bug 758] New: CVS-HEAD generates invalid spoolfi…

Αρχική Σελίδα
Delete this message
Reply to this message
Συντάκτης: Stefan Kaltenbrunner
Ημερομηνία:  
Προς: exim-dev
Καινούρια Θέματα: [exim-dev] [Bug 758] CVS-HEAD generates invalid spoolfiles with content scanning, [exim-dev] [Bug 758] CVS-HEAD generates invalid spoolfiles with content scanning
Αντικείμενο: [exim-dev] [Bug 758] New: CVS-HEAD generates invalid spoolfiles with content scanning
------- You are receiving this mail because: -------
You are on the CC list for the bug.

http://bugs.exim.org/show_bug.cgi?id=758
           Summary: CVS-HEAD generates invalid spoolfiles with content
                    scanning
           Product: Exim
           Version: N/A
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: bug
          Priority: critical
         Component: Content Scanning
        AssignedTo: tom@???
        ReportedBy: stefan@???
                CC: exim-dev@???



It seems that a recent commit in -HEAD introduced a rather serious bug. The
following commit:

http://git.infradead.org/exim-src.git?a=commit;h=1e34ce2f312fd0e6a372d80fd706cfd3fa6871d0

adds support for $spam_score, $spam_bar, and $spam_report to be saved in in the
spoolfile without considering the fact that spool_in.c does not seem to be able
to cope with multiline entries in the spool file.
So every mail sent through spamassassin using it's default reporting format is
going to result in a spoolfile that spool_in.c is unable to parse causing the
mail to get deferred with "    *** spool format error: size=1996 ***"


a (slightly edited) spoolfile looks like:

1Kd0tW-0000vl-Hd-H
Debian-exim 105 106
<b.zwinger@???>
1220957786 0
-helo_name mastermind.kaltenbrunner.cc
-host_address 217.196.146.217.50067
-interface_address 217.196.146.217.2525
-received_protocol esmtp
-aclm 1 12
asdasdasdasd
-aclm 0 23
stefan@???
-aclm 2 3
sol
-body_linecount 4
-max_received_linelength 414
-deliver_firsttime
-spam_score_int 1017
-spam_score 101.7
-spam_bar +++++++++++++++++++++++++++++++++++++++++++++++++++
-spam_report 101.7/13.0 ---- Start SpamAssassin results
* 100 USER_IN_BLACKLIST From: address is in the user's black-list
* 0.0 MISSING_MID Missing Message-Id: header
* 0.0 MISSING_DATE Missing Date: header
* 1.6 MISSING_HEADERS Missing To: header
* 0.1 RDNS_NONE Delivered to trusted network by a host with no rDNS

---- End SpamAssassin results
XX
1
test@???


what seems to happen here is that spool_in.c reads through that line by line
until it hits the -spam_report line reads that line to the variable and goes on
passing the next line onto:

if (Ustrncmp(big_buffer, "XX\n", 3) != 0 &&
  !read_nonrecipients_tree(&tree_nonrecipients, f, big_buffer,
big_buffer_size))
    goto SPOOL_FORMAT_ERROR;


which is going to barf on the next line passed in:

3590 sender_local=0 ident=unset
3590 Non-recipients:
3590 --> 100 USER_IN_BLACKLIST From: address is in the user's black-list [0]
3590 ---- End of tree ----
3590 Format error in spool file 1Kd0tW-0000vl-Hd-H
3590 LOG: MAIN
3590 Format error in spool file 1Kd0tW-0000vl-Hd-H: size=1996
3590 search_tidyup called
3590 >>>>>>>>>>>>>>>> Exim pid=3590 terminating with rc=0 >>>>>>>>>>>>>>>>


this one seems rather serious and I wonder a bit about the impact of actually
allowing untrusted (as in data text sent from an external tool) data to get put
into the spool file in addition to the fact that HEAD is simply broken with
contentscanning


--
Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email