I am still struggling with some messages being reported as spam, despite these messages being sent from my own servers with an authenticated account, to an existing address.
Our MailArchiva server (IP 1.2.3.4) sends daily reports from xxx@domain.com to e-mail yyy@domain.com.
To do so, it connects to mail server (IP 5.6.7.8) and authenticates as user xxx@domain.com.
The mail is received correctly but is seen as spam: X-AxigenSpam-Level: 10, despite DKIM, DK and SPF being correct / exempt. (I have already put in a rule to ignore SPF and MX entries.)
Any idea how to completely avoid the spam filter for certain mails / ip addresses etc?
sorry for the delay … got some personal matters to take care of.
Both servers are using Cyren and Spamassassin “out of the box”.
So far I managed to get some e-mails delivered correctly by whitelisting the address under Antivirus & Antispam.
However: Some E-Mails are still seen as spam, despite being sent with authorisation from an account hosted on that same server.
ie: archiving server sends status report once a day, authorized as @.*** to an alias of the exact same account.
This is the result in the source:
Received-SPF:
X-AXIGEN-SPF-Result: Ok
X-AXIGEN-DK-Result: Ok
DomainKey-Status: good
X-AXIGEN-DKIM-Result: Ok
DKIM-Status: good
X-CTCH-RefID: str=0001.0A0C020C.5DA8E464.006F,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0
X-CTCH-Flags: 0
X-AxigenVirus-Level: 1
X-CTCH-AV-ThreatsCount: 0
X-CTCH-VOD: Unknown
X-AxigenSpam-Level: 9
X-CTCH-Spam: Unknown
This issue is still not resolved … and it is getting worse:
Customer employee JP answers to an e-mail which has a spam rating of 1.
He answers his customers and CCs in a few colleagues: KN and IN.
Both in KNs and INs mail boxes, JPs e-mails land either in SPAM (SPam rating 7+) or even Trash (Spam Rating 10 in these cases)
This is an answer to an external, clean and legitimate e-mail sent by an authenticated user (OLK Connector) to legit users in his own domain!
I know you always advise to only use Cyren - but Cyren is a complete black box, where we have no influence on its actual functioning.
Because you are using 2 Anti Spam solutions (Cyren and Spamassassin) the value of X-AxigenSpam-Level header is set by the last filter that scan the message. To determine which filter is the last one that scan the message increase the log level for PROCESSING service to Protocol Communication, send a message and check the resulting logs.
However based on additional headers added by Cyren most probably SpamAssassin is the last one that scan the message and mark it as spam:
X-CTCH-Spam: Unknown -> indicates that the message is not detected as spam by Cyren
To confirm this you may disable SpamAssasin and send a test message.
Note that for a message detected as spam by Cyren the value of X-CTCH-Spam is “Confirmed”
So, if I understand correctly, you are complaining about that False Positive from Cyren.
Bedside reporting directly to Cyren (please ask how to do it on the support channel) I bet that JP was not in the office but at home / using his mobile and Cyren was tagging his answer as “spam” because of the WAN IP from which the message originates (in this case JP’s home router). Is this correct?
Let’s assume this is correct so I’ll present a workaround that was recommended to one of our customer that send us similar reports.
The workaround will remove the first “received” header for authenticated sessions via an advanced routing rule:
Last 2 actions are not mandatory (you could safely omit them) but will save some information into the message that otherwise will be lost due to removal of the “received” header
Please let us know if this workaround is useful for you.
regarding Cyren: The Cyren Engine is embedded in Axigen, by Axigen.
This is not something that I have implemented myself, as opposed to SpamAssassin.
It’s quite the black box inside Axigen, apart from stopping and / or disabling it and fiddling around with the sliders, there’s not too much I can do.
Axigen Documentation delivers 0 results, the Knowledge base 4, of which those relevant to Axigen 10 date back to 2016 and 2017.
The only reason why I have not yet opened up a support ticket with Axigen is the simple reason that this behaviour is annoying - but my customer should know, that they always should have a look at their Trash and Spam folders - just in case.
Just for fun I have implemented the workaround.
We’ll see what happens, as working from home or on the road will increase over the next weeks and months.
My answer was not to claim you have changed something to the Cyren “black box” but to share a workaround we have used for another customer.
Beside having fun implementing the workaround have you double-checked that first “Received” header was removed so, for example, when sending an authenticated message to an external domain (like Gmail) the WAN IP of your house router is not present into the “Received” headers?
so I’ll present a workaround that was recommended to one of our customer that send us similar reports.
Last 2 actions are not mandatory (you could safely omit them) but will save some information into the message that otherwise will be lost due to removal of the “received” header