> We are using the CommuniGate Pro mail server, which allows Outlook user
> to submit messages using the Microsoft's MAPI protocol to submit
> messages across the IMAP port. The problem that we are having is that
> although the messages are submitted directly from an authenticated
> client connection, spamassassin does not recognize the protocol, which
> triggers a host of RBL rule hits on the messages. If I change the
> submission header on the message to indicate ESMTPSA the same message
> receives a minimal score. (Below is the result of spamc using an
> adulterated received header.)

It seems to me both the MTA and the IMAP services run on the same node. If
you could split these services in two different nodes, you could use the
'msa_networks' setting to indicate to SA that the MAPI node was a MSA.

Giampaolo


> 
> 
> +++++++   Original Message   +++++++++++++++++++++
> Received: from [216.156.83.74] (account redacted-u...@domain.com)
>    by ssaihq.com (CommuniGate Pro IMAP 5.3.3)
>    with XMIT id 9561773; Mon, 07 Jun 2010 11:15:10 -0400
> 
> ...............................................
> 
> 5.9/5.0
> Spam detection software, running on the system "mail.domain.com", has
> identified this incoming email as possible spam.  The original message
> has been attached to this so you can view it (if it isn't spam) or
> label
> similar future email.  If you have any questions, see
> the administrator of that system for details.
> 
> Content preview:  Thanks, B. Yes, I do think that we need to have
> representation.
>     R.
> 
> Content analysis details:   (5.9 points, 5.0 required)
> 
>   pts rule name              description
> ---- ----------------------
> --------------------------------------------------
>   0.0 RCVD_IN_SORBS_DUL      RBL: SORBS: sent directly from dynamic IP
> address
>                              [216.156.83.74 listed in dnsbl.sorbs.net]
>   0.8 RCVD_IN_SORBS_WEB      RBL: SORBS: sender is an abusable web
> server
>   2.7 RCVD_IN_PSBL           RBL: Received via a relay in PSBL
>                              [216.156.83.74 listed in psbl.surriel.com]
>   1.4 RCVD_IN_BRBL_LASTEXT   RBL: RCVD_IN_BRBL_LASTEXT
>                              [216.156.83.74 listed in
> bb.barracudacentral.org]
> -0.5 LOCAL_SERVER_CGP_MAPI  Decreases score if submitted to server via
> CGP
>                              MAPI connector
>   1.5 SUBJ_ALL_CAPS          Subject is all capitals
> -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
>                              [score: 0.0000]
>   1.9 MISSING_MIMEOLE        Message has X-MSMail-Priority, but no X-
> MimeOLE
> 
> 
> +++++++   Modified Message   +++++++++++++++++++++
> Received: from [216.156.83.74] (account redacted-u...@domain.com)
>    by ssaihq.com (CommuniGate Pro SMTP 5.3.3)
>    with ESMTPSA id 9561773; Mon, 07 Jun 2010 11:15:10 -0400
> 
> ...............................................
> 
> 0.0/5.0
> Spam detection software, running on the system "mail.domain.com", has
> identified this incoming email as possible spam.  The original message
> has been attached to this so you can view it (if it isn't spam) or
> label
> similar future email.  If you have any questions, see
> the administrator of that system for details.
> 
> Content preview:  Thanks, B. Yes, I do think that we need to have SSAI
> representation.
>     R.
> 
> Content analysis details:   (0.0 points, 5.0 required)
> 
>   pts rule name              description
> ---- ----------------------
> --------------------------------------------------
> -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
> -0.5 LOCAL_SERVER_CGP_MAPI  Decreases score if submitted to server via
> CGP
>                              MAPI connector
>   1.5 SUBJ_ALL_CAPS          Subject is all capitals
> -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
>                              [score: 0.0000]
>   1.9 MISSING_MIMEOLE        Message has X-MSMail-Priority, but no X-
> MimeOLE
> 
> 
> 
>   I've created a local rule which reduces the message score based on a
> locally added header, but I am reluctant to have it adjust the score
> enough to counteract the scores added by the various RBLs. My
> preference
> would be to have all locally authenticated messages, using any
> submission method (CGP also accepts messages via AIRSYNC, XMPP and
> others) identified and treated the same. Is there any way to have
> spamassassin treat these other protocols like ESMPSA?
> 
> SpamAssassin 3.3.1

Reply via email to