Captains Log: Sending Email Threat alerts to EDR via Syslog

A Practical Guide for MSP Partners

Email remains one of the most important telemetry sources in the modern MSP security stack. OpenText Core Email Threat Protection can identify spam, phishing, malware, quarantine events, and link-based activity long before a compromise reaches the endpoint.

However, getting those alerts into OpenText Core EDR in a reliable and operationally safe way is not always straightforward.

Unlike platforms that offer a native event streaming integration, OpenText Core Email Threat Protection exposes SIEM data through an API. That means MSP engineers must account for:

• poll timing and overlap
• API response handling
• duplicate suppression
• event normalisation
• Syslog / CEF forwarding

In this guide, we’ll walk through how to deploy a lightweight Linux collector that polls the Email Threat Protection SIEM API, captures all relevant alerts, normalises them, and forwards them to OpenText Core EDR via Syslog.

The configuration described here is designed to be:

• SOC-friendly
• Reliable under real-world polling conditions
• Easy to deploy and tune
• Lightweight enough for MSP operations

Intent and Purpose

The purpose of this solution is simple:

send high-value Email Threat Protection alerts into OpenText Core EDR in a format that is structured, reliable, and easy for an MSP SOC to work with.

The collector is intentionally separated into three parts:

1. Python collector
   Polls the API, parses results, applies overlap and deduplication, and emits structured local Syslog events.
    
2. rsyslog
   Matches the collector’s local messages and forwards them as CEF-formatted Syslog.
    
3. OpenText Core EDR Syslog Forwarder
   Receives the CEF messages and ingests them into the platform for search, alerting, and investigation.

This separation keeps the design predictable, modular, and operationally safe.

Lab Architecture Used in This Guide

If you plan to follow along, the configuration described in this article was tested in the following environment.

Apart from the specific package locations and service names, the overall procedure described in this article can be adapted to Windows-based Syslog relays.

Platform Requirements

Before beginning, ensure the following OpenText Core services are available.

OpenText Core EDR relies on additional platform components for endpoint telemetry collection and log storage.

Your environment must include:

Without Compliance Storage, Syslog ingestion will not be available in the OpenText portal.

Why Not Just Query the API Manually?

At first glance, it may seem enough to run a simple script on a schedule and forward the results.

In practice, API-driven collectors can miss alerts unless they are designed carefully.

Common problems include:

• events appearing slightly later than expected
• strict polling boundaries missing alerts
• re-reading windows and generating duplicates
• parsing high volumes of alerts

To solve this, the collector used in this guide was redesigned with:

• overlapping poll windows
• persistent deduplication
• live monitoring options
• tight CEF output via rsyslog

The collector is the core of the solution, so in this guide we focus there and keep the rest of the Syslog pipeline intentionally succinct.

Design Goals

To keep the deployment operationally safe and easy to maintain, we intentionally kept the design simple:

• Use a native Linux Python collector
• Use SQLite for persistent deduplication state
• Use rsyslog for local CEF forwarding
• Provide a guided installer with install, uninstall, and tune / monitor options
• Make the collector visible to engineers using poll heartbeat logging

This keeps the solution:

• effective
• easy to deploy
• robust
• lightweight

Implementation Guide

The following section walks through the deployment process step by step, starting with enabling the Syslog receiver inside OpenText Core EDR and then deploying the Linux collector bundle.

Step 1 — Configure the Syslog Source in OpenText Core EDR

Enable Syslog forwarding on an OpenText Core Endpoint Protection agent via:

Agents → More → Settings → Enable Syslog Forwarder

This agent will act as the local Syslog receiver and forwarder into OpenText Core EDR.

Step 2 — Prepare the Linux Collector Host

The collector should be installed on a Linux server that has access to (or is) a local Syslog relay.

Ensure the following are available:

• Python 3
• rsyslog
• systemd
• network access to the Email Threat Protection SIEM API
• network or local access to the OpenText Core EDR Syslog listener

If the collector is being installed on the same server as the Syslog listener, the recommended destination IP is:

127.0.0.1

This keeps the design simple and avoids unnecessary external forwarding.

Step 3 — Copy the Collector Bundle to the Linux Host

Transfer the collector bundle to the Linux server and extract it.

etp_syslogcollector.zip

Example:

unzip etp_syslogcollector_v2_bundle.zip
cd etp_syslogcollector_v2_bundle

The bundle includes:

• install.sh
• etp_syslogcollector.py
• collector.ini
• etp-syslogcollector.service
• 60-etp-syslog.conf

Step 4 — Run the Installer

Run on: Linux Collector Host

./install.sh

The installer provides three operational modes:

1) Install
2) Uninstall
3) Tune / Monitor

Select 1) Install.

The installer then prompts for the collector tuning values.

The defaults used in this guide are:

• poll every 30 seconds
• look back 5 minutes
• overlap enabled
• dedupe retention 24 hours
• target host 127.0.0.1
• target port 514
• protocol TCP

Step 5 — Validate the Collector

After installation, run a one-shot collector test.

Run on: Linux Collector Host

sudo etp-syslogcollector-test

Expected output:

poll_result window_from=2026-03-10T10:00:00Z window_to=2026-03-10T10:04:30Z api_lines=0 parsed=0 emitted=0 duplicates=0 toca=0 filtered=0

Even when no events are returned, this confirms:

• the collector can reach the API
• authentication is working
• the poll cycle completed successfully

Step 6 — Start the Service

Enable and start the collector as a systemd service.

Run on: Linux Collector Host

sudo systemctl enable --now etp-syslogcollector

Check status:

sudo systemctl status etp-syslogcollector --no-pager

The service should show active (running).

Step 7 — Watch Live Poll Results

One improvement in this collector design is that each poll writes a summary to journald.

Run on: Linux Collector Host

sudo journalctl -u etp-syslogcollector -f

This provides a live view of poll activity, for example:

poll_result window_from=2026-03-10T10:00:00Z window_to=2026-03-10T10:04:30Z api_lines=3 parsed=3 emitted=2 duplicates=1 toca=0 filtered=3

This is extremely useful operationally because it allows MSP engineers to confirm that the collector is actively polling and understand whether events are being emitted or suppressed as duplicates.

Step 8 — Watch Local Syslog Events

The collector emits normalised local Syslog messages with the program tag etp-syslogcollector.

Run on: Linux Collector Host

sudo tail -f /var/log/syslog

Example event:

etp-syslogcollector: {"event_family":"filtered_message","event_type":"email_quarantined","signature":"ETP-QUAR","severity":6,"summary":"Filtered email from attacker@example.com to user@company.com action=QUARANTINE type=SPAM"}

Step 9 — Validate CEF Forwarding

The rsyslog configuration matches the local collector messages and forwards them as CEF.

If you want to watch the forwarded traffic live, use:

sudo tcpdump -ni any -nn -s0 -A tcp port 514

This provides a live view similar to:

CEF:0|OpenText|Core Email Threat Protection|2.0|ETP-QUAR|Email Quarantined|6|...

This is particularly useful when validating that the relay is forwarding the collector’s output as intended.

Step 10 — Confirm the Event Reaches OpenText Core EDR

Generate or wait for a real Email Threat Protection alert, then search for the event in OpenText Core EDR.

Good search terms include:

• sender email address
• recipient email address
• ETP-QUAR
• ETP-BLOCK
• ETP-TOCA

This confirms that:

• the collector is polling successfully
• the event is being normalised
• rsyslog is forwarding it in CEF
• OpenText Core EDR is ingesting it

Using the Tune / Monitor Menu

One of the most useful features in this design is the built-in Tune / Monitor mode.

Run:

./install.sh

Then select:

3) Tune / Monitor

This gives operators access to:

• show current config
• edit config
• show service status
• live poll results
• live syslog events
• live forwarded CEF
• one-shot test
• restart collector

For MSP teams, this makes the collector much easier to support remotely and significantly reduces time spent remembering troubleshooting commands.

Lessons Learned — Pitfalls and How We Overcame Them

During development and testing, we encountered several issues that are worth highlighting. These are exactly the kinds of edge cases MSP engineers are likely to run into when building API-driven Syslog pipelines.

Missed Alerts Due to Poll Boundaries

The original collector design occasionally missed alerts that appeared in the Email Threat Protection portal but not in the downstream Syslog feed.

This happened because exact query boundaries assumed all events would be available immediately and with perfect timestamp alignment.

Solution

We redesigned the collector to:

• poll every 30 seconds
• query the last 5 minutes
• add overlap by default
• treat the API as eventually consistent

This dramatically reduced the chance of missing alerts.

Duplicate Events from Overlapping Windows

Once overlap was introduced, duplicates became inevitable.

Solution

We implemented persistent deduplication using SQLite and fingerprint hashes. This allowed us to overlap aggressively without flooding the SIEM with repeat events.

Limited Runtime Visibility

Early versions of the collector only made it obvious that the service was running. They did not make it obvious what each poll was doing.

Solution

Each poll now writes a heartbeat summary to journald, including:

• window start
• window end
• API lines returned
• parsed events
• emitted events
• duplicates suppressed

This made operational troubleshooting significantly easier.

TLS Certificate Validation Problems

In some environments the API could not be reached initially because the Linux host did not trust the certificate chain being presented.

Solution

We validated trust on the collector host and, where required, remediated the local certificate trust store. This resolved API connectivity without having to weaken TLS validation.

Token Format Confusion

One early pitfall was using a token identifier rather than the full authorisation token.

Solution

The collector and installer now explicitly expect the full JWT authorisation token. The prompts were updated to make that clear.

Syslog Session Behaviour

During forwarding tests, the local Syslog receiver would sometimes close connections after accepting a message. This looked alarming at first, but in practice the payload had already been delivered successfully.

Solution

We validated traffic using tcpdump and confirmed the payload was being accepted. This helped separate true delivery failures from normal receiver behaviour.

Testing with tcpdump Still Matters

When troubleshooting Syslog pipelines, it remains extremely helpful to validate each stage independently.

Run on: Linux Collector Host

sudo tcpdump -ni any -nn -s0 -A tcp port 514

If CEF appears here but not in the OpenText Core EDR portal, the issue is likely related to:

• parsing
• formatting
• platform-side ingestion settings

If CEF does not appear here, the issue is more likely related to:

• rsyslog configuration
• destination host / port
• protocol selection
• listener availability

This layered approach dramatically shortens troubleshooting time.

Final Thoughts

OpenText Core Email Threat Protection contains high-value security telemetry, but reliable SIEM integration requires more than a basic polling script.

With a lightweight Linux collector, persistent deduplication, and a clean rsyslog CEF pipeline, you can:

• capture all relevant ETP alerts
• reduce missed events
• avoid duplicate noise
• give the SOC structured email security telemetry
• support the solution with simple Linux-native tooling

For MSP partners, this approach can become part of a repeatable security integration pattern for environments that need better visibility from OpenText Core Email Threat Protection.

Once implemented, your SOC gains earlier visibility into email-borne threats — helping connect the dots between mail security, endpoint telemetry, and incident response.