Hello SmarterTools team,
I am running:
- SmarterMail 100.0.9714.*****
- Ubuntu Server 22.04
- Cyren Premium Antispam purchased as a one-year subscription in December 2025
- Current production installation, not a test environment
I have now disabled Cyren Premium Antispam and Cyren IP Reputation because the Cyren service stopped returning usable results and began producing large numbers of connection and resolver errors. You know it...
This is not based only on the dashboard or on a single test button. I reviewed and correlated the SmarterMail delivery, spam-check, administrative and system-journal logs.
Timeline from the production logs
Before the incident, Cyren Premium Antispam completed virtually every message scan:
| Date | Scans started | Scans completed | Completion rate |
|---|
| August 15 | 518 | 515 | 99.4% |
| August 16 | 349 | 347 | 99.4% |
| August 17 | 674 | 673 | 99.9% |
| August 18 | 727 | 726 | 99.9% |
| August 19 | 743 | 742 | 99.9% |
| August 20 | 740 | 739 | 99.9% |
| August 21 | 550 | 529 | 96.2% |
| August 22 | 246 | 243 | 98.8% |
| August 23 | 364 | 137 | 37.6% |
| August 24, until disabled | 230 | 0 | 0.0% |
The sustained degradation began on August 23, 2026 at 05:19:27 CEST. Until 04:59, the hourly completion rate had still been 100%. From 05:19 onward, individual scans repeatedly failed to return a completed Cyren result.
The last successful Cyren Premium Antispam message result was recorded at:
2026-08-23 21:42:47.538 CEST
[Cyren Client] Done Scanning Message
After that, Cyren started further message scans but returned no completed message results. From 22:00 onward, the completion rate was zero.
The first explicit connection failure after the last successful result was:
2026-08-24 00:38:58.774 CEST
[Cyren Client] Cyren Error:
Connection refused (127.0.0.1:8088)
On August 24, SmarterMail started 230 Cyren message scans, but Cyren completed none of them. SmarterMail generally continued processing the messages with a Cyren result of Unknown, so I did not observe a complete mail-flow outage. However, the paid Cyren component was no longer providing useful message classification.
Cyren IP Reputation continued responding for a while longer. Its final recorded IP reputation result was:
2026-08-24 13:24:57.167 CEST
[CyrenIP Client] Done Scanning IP Address
This means the two Cyren components did not fail at exactly the same time:
- Cyren Premium Antispam stopped returning message results after August 23 at 21:42:47 CEST.
- Cyren IP Reputation returned its last result on August 24 at 13:24:57 CEST.
Deactivation
Because of the failed scans and the growing number of errors, I disabled both Cyren checks in SmarterMail at approximately 13:28 CEST on August 24.
The administrative log records two updates to the spam settings at:
2026-08-24 13:27:56.099 CEST
2026-08-24 13:28:02.700 CEST
I then restarted the SmarterMail service. The service stopped at 13:29:20 and was running again at 13:29:35.
The current SmarterMail API configuration confirms:
Cyren Premium Antispam: disabled
Cyren outbound blocking: disabled
Cyren IP Reputation: disabled
Cyren IP inbound blocking: disabled
No Cyren or CyrenIP message scans have been performed since the latest restart. Therefore, the disabled checks are no longer contributing to spam decisions.
The unexpected part
Although both Cyren checks are disabled, SmarterMail continues to start the bundled Cyren processes:
/opt/smartermail/Cyren/bin/ctasd.bin
/opt/smartermail/CyrenIP/bin/ctipd.bin
ctasd continues trying to contact:
resolver1.stools.ctmail.com
resolver2.stools.ctmail.com
resolver3.stools.ctmail.com
Since I disabled Cyren, the SmarterMail journal has accumulated at least:
706 resolver connection timeout entries
130 FindCenterUrgent exceptions
53 GetServices errors
4 SingleEngine communication errors
Typical messages include:
Failed to connect to resolver1.stools.ctmail.com port 80:
Connection timed out
GetServices error - Still unable to connect to Datacenter
CSessionBroker::FindCenterUrgent() - Got unknown exception
Comm error [SingleEngine] - daemon will retry in background
Put less technically: Cyren has stopped scanning, but it has not stopped calling home. That is a rather unusual interpretation of “disabled” — the employee has clocked out, but is still phoning headquarters every few seconds to announce that he is not working.
I would expect a disabled paid add-on to stop processing messages and to stop starting its daemons and contacting remote Cyren infrastructure.
My questions
- Is this a known issue in SmarterMail build 9714 on Linux?
- Why are
ctasd and ctipd still started when both Cyren checks are disabled? - Is there a supported SmarterMail setting that completely disables these processes on Linux?
- Can this be done without manually editing bundled configuration files, renaming binaries, killing processes or making changes that may be overwritten by a SmarterMail update?
- Are the
resolver*.stools.ctmail.com services currently operational? - Was there a known Cyren service incident beginning on August 23 or 24?
- Is a fix planned so that disabled Cyren modules remain stopped?
I do not want to improvise by modifying files under /opt/smartermail, because this is a production system and such modifications may be unsupported or overwritten during an update.
I purchased the one-year Cyren Premium Antispam subscription in December 2025. The paid service is now unusable on my server, and I had to replace it with another antispam component to maintain protection.
I would therefore like to request a refund for the Cyren add-on—at minimum a pro-rata refund for the unused remaining subscription period, calculated from the point at which the service stopped returning results or a switch to Message Sniffer. If this is considered a temporary service problem, please instead provide:
- a concrete restoration date,
- confirmation that the Linux issue will be resolved,
- and an appropriate extension of the Cyren subscription for the unavailable period.
I can provide sanitized excerpts from the delivery, spam-check, and system-journal logs, including scan IDs and exact timestamps, privately through a support ticket.
Thank you for investigating this.
George A. Rauscher