Is MCP "deliver" option working at all?

[Quentin Campbell]

Is anybody using the MCP "deliver" option with MS 4.55.* and can verify
that it is working? 

It is it working what do your MCP options values look like?

What does the "MCP Error" option value in MailScanner.conf do? How does
it interact with the other MCP options?

I am running MailScanner 4.55.7-1 & SpamAssassin 3.1.3 with Sendmail
(8.13) on Red Hat Enterprise Linux AS release 4. The relevant settings
in MailScanner.conf are:

MCP Checks = yes

# Do the spam checks first, or the MCP checks first?
# This cannot be the filename of a ruleset, only a fixed value.
First Check = mcp

# The rest of these options are clones of the equivalent spam options
MCP Required SpamAssassin Score = 1
MCP High SpamAssassin Score = 10
MCP Error Score = 1

MCP Header = X-%org-name%-MailScanner-MCPCheck:
Non MCP Actions = deliver
MCP Actions = deliver
High Scoring MCP Actions = delete
Bounce MCP As Attachment = no

MCP Modify Subject = no
MCP Subject Text = {MCP?}
High Scoring MCP Modify Subject = yes
High Scoring MCP Subject Text = {MCP?!}

Is Definitely MCP = no
Is Definitely Not MCP = no
Definite MCP Is High Scoring = no
Always Include MCP Report = yes
Detailed MCP Report = yes
Include Scores In MCP Report = yes
Log MCP = yes

MCP Max SpamAssassin Timeouts = 20
MCP Max SpamAssassin Size = 100k
MCP SpamAssassin Timeout = 75

MCP SpamAssassin Prefs File = %mcp-dir%/mcp.spam.assassin.prefs.conf
MCP SpamAssassin User State Dir =
MCP SpamAssassin Local Rules Dir = %mcp-dir%
MCP SpamAssassin Default Rules Dir = %mcp-dir%
MCP SpamAssassin Install Prefix = %mcp-dir%
Recipient MCP Report = %report-dir%/recipient.mcp.report.txt
Sender MCP Report = %report-dir%/sender.mcp.report.txt

The syslog records for a typical message scored by MCP for delivery:

...
Sep  5 06:15:16 cheviot4 sendmail[7250]: k855FG8A007250:
from=<nxxx at cpx.ncl.ac.uk>, size=1086, class=0, nrcpts=1,
msgid=<EBAC7D3C7B22BE458D41F7BDEC5DBFD21FFA85 at SANMAIL01.campus.ncl.ac.uk
>, proto=ESMTP, daemon=MTA, relay=stromberg.ncl.ac.uk [10.8.234.172]
Sep  5 06:15:16 cheviot4 sendmail[7250]: k855FG8A007250:
milter=milter-link, action=header, continue
Sep  5 06:15:16 cheviot4 sendmail[7250]: k855FG8A007250:
milter=milter-link, action=eoh, continue
Sep  5 06:15:16 cheviot4 sendmail[7250]: k855FG8A007250:
milter=milter-link, action=body, continue
Sep  5 06:15:16 cheviot4 sendmail[7250]: k855FG8A007250: Milter add:
header: Received-SPF: pass (cheviot4.ncl.ac.uk: 10.8.234.172 is
authenticated by a trusted mechanism)
Sep  5 06:15:16 cheviot4 sendmail[7250]: k855FG8A007250: Milter accept:
message
Sep  5 06:15:16 cheviot4 sendmail[7250]: k855FG8A007250:
to=<inquiry at learningemall.com>, delay=00:00:00, mailer=esmtp, pri=31086,
stat=queued
Sep  5 06:15:19 cheviot4 MailScanner[12258]: Message k855FG8A007250 from
10.8.234.172 (nxxx at cpx.ncl.ac.uk) to learningemall.com is MCP,
MCP-Checker (score=1, required 1, MCP_OOO_2 1.00) 
Sep  5 06:15:19 cheviot4 MailScanner[12258]: MCP Actions: message
k855FG8A007250 actions are deliver 
Sep  5 06:15:21 cheviot4 sendmail[7309]: k855FG8A007250: done;
delay=00:00:05, ntries=1

Note _no_ Sendmail "stat=Sent" record. It is as if MailScanner simply
dropped the queue files for the message and did not put them in
/var/spool/mqueue.

Quentin
---
PHONE: +44 191 222 8209    Information Systems and Services (ISS),
                           Newcastle University,
                           Newcastle upon Tyne,
FAX:   +44 191 222 8765    United Kingdom, NE1 7RU.
------------------------------------------------------------------
Opinions expressed above are mine.