[exim-dev] [Bug 1821] New: old spamd response parsing code

トップ ページ
このメッセージを削除
このメッセージに返信
著者: admin
日付:  
To: exim-dev
題目: [exim-dev] [Bug 1821] New: old spamd response parsing code
https://bugs.exim.org/show_bug.cgi?id=1821

            Bug ID: 1821
           Summary: old spamd response parsing code
           Product: Exim
           Version: 4.87
          Hardware: x86-64
                OS: Linux
            Status: NEW
          Severity: bug
          Priority: medium
         Component: Content Scanning
          Assignee: tom@???
          Reporter: wbreyha@???
                CC: exim-dev@???


After I added a new variant to the spamd support (see #1820) I recognized that
exim complained with...
spam acl condition: cannot parse spamd [127.0.0.1]:10783 output

I came to the conclusion that this was triggered by using
REPORT SPAMC/1.3
for expurgate instead of
REPORT SPAMC/1.2
the classic spamd code uses.

Since I did not change the response parsing the same code was used for
expurgate.

Looking into it I found spam.c:569:
  if (sscanf(CS spamd_buffer,
       "SPAMD/%7s 0 EX_OK\r\nContent-length: %*u\r\n\r\n%lf/%lf\r\n%n",
       spamd_version,&spamd_score,&spamd_threshold,&spamd_report_offset) != 3)


It seems that this code reflects to a note in
http://svn.apache.org/repos/asf/spamassassin/trunk/spamd/PROTOCOL
...
section for REPORT:
"Note that the superfluous-score/threshold-line bug that appeared in
SpamAssassin 2.5x is fixed."

The official variants for REPORT are:
SPAMC => 1.3
SPAMD/1.x 0 EX_OK\r\n
Content-length: xxxx\r\n
Spam: True ; xx.x / x.x\r\n\r\n

and
SPAMC <= 1.2
SPAMD/1.x 0 EX_OK\r\n
Spam: True ; xx.x / x.x\r\n\r\n

The PROTOCOL document does not define this, but spamd code does it. Definition
says "Content-Length is required for >=1.2", but spamd REPORT only uses it for
>=1.3. Reading the comment besides the "if" in spamd this is most likely a bug

not fixed for compatibility. It seems 1.2 uses the odd combination of
content-length on client side sending the REPORT command and no content-length
in the response.

According to the Exim git history the parsing code comes from exiscan and was
never changed since. It seems that it was written at a time the "superfluous"
bug mentioned above was not fixed.

I think the code should be optimized to check for the common/correct version
first and try the bugged version as fallback. Or the code gets removed since
support for a bugged spamd version from years ago is not needed anyway. People
still using SpamAssassin 2.5x most likely wont update Exim as well.

Upgrading to protocol 1.5... don't know. Not really necessary as it seems.
Maybe nice to have.

--
You are receiving this mail because:
You are on the CC list for the bug.