Missing attributes in OpenTelemetry tracer

Issues
1

Issue Description

The OpenTelemetry tracer misses some attributes when comparing logs with the stdout tracer.

Example:
When I receive an email, I get the following log in the stdout tracer:

2026-09-05T07:55:55Z INFO SMTP EHLO command (smtp.ehlo) listenerId = "smtp", localPort = 25, remoteIp = 2607:f8b0:4864:20::32c, remotePort = 44344, domain = "mail-ot1-x32c.google.com"

The OpenTelemetry collector (in my case Grafana Alloy) receives the following:

ResourceLog #0
Resource SchemaURL: 
Resource attributes:
     -> telemetry.sdk.version: Str(0.31.0)
     -> telemetry.sdk.language: Str(rust)
     -> telemetry.sdk.name: Str(opentelemetry)
     -> service.version: Str(0.16.17)
     -> service.name: Str(stalwart)
ScopeLogs #0
ScopeLogs SchemaURL: 
InstrumentationScope stalwart 
LogRecord #0
ObservedTimestamp: 2026-09-05 07:55:55.702819789 +0000 UTC
Timestamp: 2026-09-05 07:55:55 +0000 UTC
SeverityText: INFO
SeverityNumber: Info(9)
Body: Str(SMTP EHLO command)
Attributes:
     -> spanId: Int(327816221705649664)
     -> domain: Str(mail-ot1-x32c.google.com)
Trace ID: 
Span ID: 
Flags: 0

Expected Behavior

All attributes that the stdout traces logs should be in the OpenTelemetry tracer as well.

Actual Behavior

remoteIp and remotePort are missing in the OpenTelemetry trace.

Stalwart Version

v0.16.x

Installation Method

NixOS

Database Backend

PostgreSQL

Blob Storage

PostgreSQL

Search Engine

PostgreSQL

Directory Backend

Internal

I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.

on

I have searched this support forum (open and closed topics) and confirm this is not a duplicate.

on

I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.

on

2

Confirmed by looking at the tracing implementation: this is expected given how the OpenTelemetry log exporter is built, and it looks like a gap in that exporter compared to the stdout/text writer.

In the stdout (text) tracer, each log line is built by merging the parent span’s attributes with the event’s own attributes (crates/trc/src/serializers/text.rs, write_keys, which chains span_keys.iter().chain(keys.iter())). The remoteIp/remotePort/listenerId/localPort attributes are set once on the span-start event (e.g. the SMTP connection span), not repeated on every child event like “SMTP EHLO command.” The text writer pulls them in from the parent span, which is why you see them in stdout.

The OpenTelemetry log record builder (crates/common/src/telemetry/tracers/otel.rs, build_log_record) only iterates event.keys, i.e. the attributes attached directly to that specific event, and never looks at event.inner.span’s keys. So any attribute that only exists on the parent span (like remoteIp/remotePort) never makes it into the exported OTel log record’s attributes, only into the OTel span data (attached to the span itself, not each log line).

So functionally: remoteIp/remotePort should still show up as attributes on the enclosing span exported to your collector (the SMTP connection span), just not repeated on each log record/event within that span, unlike the stdout tracer which repeats them per line. If your OTel span exporter is enabled and you check the span for that connection rather than the individual log record, the attributes should be present there.

This isn’t something covered by current published docs as a known limitation, it’s something I found directly in the tracer source code, so I can’t point you to a docs page confirming intended behavior either way.

This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.

3

Fixed in v0.16.21 (yet to be released).