Emails incorrectly marked as JUNK

[Basilt]

Hi all.

I am a new system admin and also fairly new to Zimbra. At work we are running Zimbra Collection Suite 6 on a CentOS 5 server and I am having trouble with some messages being incorrectly marked as SPAM.

I have done extensive searches and cant find a solution to my specific issue.

We have a HP MFP with the ability to scan to email, which is the root of the problem.

The network is as follows.

192.168.5.1 - Zimbra server
192.168.5.11 - Windows server with HP configuration tool (contains SMTP settings)
192.168.5.25 - HP 9050 MultiFunction Centre

The HP MFP uses DSS, Digital Sending Software, loaded onto the windows server to send the emails.
I have set the Zimbra server as the smtp gateway for the DSS.

I have tried a variety of different email addresses for the HP, adding each to the whitelist follwing steps found here. The only address I have succeeded with is my own personal email address. When I use either the email address created for the HP, h9050@example.com, or the main administration address, cba@example.com, the messages are filtered to junk. Each time I click the 'not junk' button but the messages still go to junk box.

I have included a copy of the email header for messages filtered to junk as well as the header when not filtered
The line that I notice in the junk message is

X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "To"

My guess is that Zimbra thinks that the MFP is trying to spoof the address from within the network which is why it is marked as junk everytime. Although I am unsure why it works when using my email address in the MFP.

The solutions that I thought may be feasible are:

1. Create a rule based on subject that will explicitly mark a message as safe

2. Mark the entire network here a safe zone, so an emails provided from an IP range would not be spam checked (if this is even possible)


Any help would be greatly appreciated

Regards,

Basil Twisleton

[uxbod]

Welcome to the forums

Most of your problems are caused by

FH_DATE_PAST_20XX=3.188

So fix that first by following :- [SOLVED] FH_DATE_PAST_20XX - Spamassassin bug - incorrect tagging from Jan 1, 2010 on

[Basilt]

Thank you so much. I will attempt to implement this when I get back to work.
Is it considered a solution or just a temp work around?

[uxbod]

Solution as it was a bug in the SpamAssassin ruleset which has been fixed up stream. With ZCS6.0.5 it comes bundled with the SA tools so you can update more easily.

[Basilt]

Thank you for your help. I have implemented the change in /opt/zimbra/conf/spamassassin/local.cf and performed a zmamavisdctl restart.

I also had to modify the 72_active.cf rule to match the solution provided here

##{ FH_DATE_PAST_20XX
header   FH_DATE_PAST_20XX      Date =~ /20[2-9][0-9]/ [if-unset: 2006]
describe FH_DATE_PAST_20XX      The date is grossly in the future.
##} FH_DATE_PAST_20XX

The emails are still going to junk and the header now reads.

X-Spam-Status: Yes, score=6.63 tagged_above=-10 required=6.6
	tests=[ALL_TRUSTED=-1.8, AWL=0.674, BAYES_50=0.001,
	INVALID_DATE=1.245, MIME_QP_LONG_LINE=1.396, TVD_RCVD_IP=1.931,
	TVD_RCVD_IP4=3.183]

The INVALID_DATE flag has only shown up today since modifying the local.cf and adding

score FH_DATE_PAST_20XX 0.0

One more quick question in regards to the SPAM score.

could you please tell me what these lines are a and why they would be giving such a high score.

TVD_RCVD_IP4=3.183
TVD_RCVD_IP=1.931

Regards,

Basil Twisleton

[uxbod]

Rules/TVD_RCVD_IP - Spamassassin Wiki

You could always whitelist that device : Improving Anti-spam system - Zimbra :: Wiki

[Basilt]

Thanks uxbod,

I looked at that page containing information about the TVD_RCVD_IP information but I am having trouble understanding why it is triggered with such high scores and how I would reduce them, If possible/secure to do so.

I have tried to whitelist the device by IP previous to the FH_DATE fix but it was still being marked as SPAM.

Should I attempt again now that the AS rule has been corrected?

Would the correct guide be this one?


Regards,

Basil Twisleton