Make FakeSmtp docker image runable on ARM chip

[quantranhong1999]

Today, the FakeSmtp image is outdated and only supports AMD64 CPU architecture. It is even outdated that with the AMD64 emulator, I still can not run the tests that used FakeSmtp on my Mac (M1 chip).

We have the Dockerfile: https://github.com/ambled/rest-smtp-sink/blob/master/Dockerfile

Let's try to upgrade the Node version + build multi-architecture (AMD64/ARM) to ease running tests on ARM chip (which seems impossible today)

Note: This FakeSmtp still runs well on AMD64 chip and CI, not a priority for now, putting in backlog.

[chibenwa]

Or how about to drop it in favour of our MockSmtp thing ?

https://github.com/apache/james-project/tree/master/server/mailet/mock-smtp-server

[quantranhong1999]

Or how about to drop it in favour of our MockSmtp thing ?

Yes. It sounds possible.

Also MockSmtpServerExtension as the extension of it?

[chibenwa]

Analysis

Where the image is wired in

The FakeSmtp image is referenced by a single constant:

• server/testing/src/main/java/org/apache/james/util/docker/Images.java:23

  String FAKE_SMTP = "quanth99/rest-smtp-sink:1.0"; // Original Dockerfile: https://github.com/ambled/rest-smtp-sink/blob/master/Dockerfile

It is consumed by server/testing/.../utils/FakeSmtp.java, which:

• starts the container with node cli --listen 80 --smtp <port>,
• polls GET /api/email (expects a JSON array of mails with at least id, from, subject),
• purges via GET /api/email/purge/{id}.

Test consumers (all docker-based integration tests):

• mpt/impl/smtp/core/.../ForwardSmtpTest.java
• server/mailet/integration-testing/.../smtp/SmtpContentTypeTest.java
• server/mailet/integration-testing/.../smtp/SmtpAuthorizedAddressesTest.java
• server/mailet/integration-testing/.../mailets/GatewayRemoteDeliveryIntegrationTest.java
• server/mailet/integration-testing/.../mailets/DirectResolutionRemoteDeliveryIntegrationTest.java
• server/mailet/integration-testing/.../transport/mailets/GroupMappingRelayTest.java

So the James-side change is a one-liner in Images.java; the real work is producing a multi-arch image.

Why the current image is AMD64-only

The upstream Dockerfile (ambled/rest-smtp-sink) is the root cause:

FROM progrium/busybox
RUN opkg-install curl bash git libstdcpp && \
    ... \
    curl -s http://nodejs.org/dist/v0.10.36/node-v0.10.36-linux-x64.tar.gz | gunzip | tar -xf - -C /
ENV PATH /node-v0.10.36-linux-x64/bin:$PATH

Two hard blockers for ARM:

1. progrium/busybox is an AMD64-only base image (no arm64 manifest).
2. Node is pulled as a hardcoded node-v0.10.36-linux-x64 tarball — Node 0.10 (EOL ~2016) and x64-only, so it cannot execute under arm64 even via emulation reliably.

Hence: unusable on M1/arm64, and even x64 emulation on Mac is flaky, exactly as the ticket reports.

The catch: a naive base-image bump won't work

The app's package.json pins a 2015-era dependency tree:
simplesmtp@^0.3, mailparser@^0.4, knex@^0.7, sqlite3@^3.0, express@4, bluebird@2, lodash@3.

• simplesmtp is deprecated/unmaintained and won't build/run on a modern Node LTS.
• sqlite3@3.0 needs native compilation and won't reliably build on current Node/arm64.

So simply swapping FROM progrium/busybox for FROM node:lts-alpine is unlikely to produce a working image — the JS needs porting.

Recommended approach

Follow the precedent already in this same Images interface: linagora/mock-smtp-server:0.7 is a linagora-hosted image living in its own repo. Do the same for FakeSmtp:

Option A (recommended) — reimplement the tiny sink against modern libs and publish multi-arch under linagora/.
The whole app is ~200 lines (cli.js + index.js). Rewrite it preserving the contract James depends on:

• CLI flags --listen / --smtp,
• endpoints GET /api/email and GET /api/email/purge/{id},
• per-mail JSON fields used in assertions (id, from, subject, plus the deserialized body/headers).

Modernize the internals:

• simplesmtp -> smtp-server,
• old mailparser@0.4 -> current mailparser,
• drop knex/sqlite3 in favour of a simple in-memory array (this is a throwaway test sink — no persistence needed, which also removes the native-build headache).

Then:

docker buildx build --platform linux/amd64,linux/arm64 -t linagora/rest-smtp-sink:<tag> --push .

and update Images.FAKE_SMTP to the new tag. Verify with docker manifest inspect (both linux/amd64 + linux/arm64 present) and by running the six tests above on both architectures.

Option B — resurrect the original code as-is on a modern arm64-capable base. More faithful, but fighting simplesmtp/sqlite3@3 on modern Node is likely more effort than Option A for no functional gain.

Option C — reuse the existing linagora/mock-smtp-server. Not a drop-in: its API and mail-inbox shape differ from /api/email, so every assertion in the six tests would need rewriting. Larger churn, not recommended just to solve the arch problem.

Notes

• The image source should not live inside james-project (it's referenced by tag, like mock-smtp-server); host it in a dedicated repo/Docker Hub namespace under linagora/.
• Consistent with the ticket, this is backlog priority: the current image still works on AMD64/CI; the goal is unblocking ARM contributors.

---

Generated automatically

[chibenwa]

🤖 Session stats

32 turns | 289s | in=3455 out=21497 cache_read=752429 cache_write=49944 | cost=1.4311 USD

[quantranhong1999]

Option C — reuse the existing linagora/mock-smtp-server. Not a drop-in: its API and mail-inbox shape differ from /api/email, so every assertion in the six tests would need rewriting. Larger churn, not recommended just to solve the arch problem.

I think we could try to plan to replace FakeSmtp using MockSmtpServerExtension. I remember trying before, and not too many changes were needed to adapt the tests.

[chibenwa]

Analysis

Where it lives

The FakeSmtp image is pinned in a single place:

• server/testing/src/main/java/org/apache/james/util/docker/Images.java:23

  String FAKE_SMTP = "quanth99/rest-smtp-sink:1.0"; // Original Dockerfile: https://github.com/ambled/rest-smtp-sink/blob/master/Dockerfile

• Wrapped by server/testing/src/main/java/org/apache/james/utils/FakeSmtp.java, which starts the container with node cli --listen 80 --smtp <port> and talks to it over HTTP.

quanth99/rest-smtp-sink:1.0 is a third-party re-publish of ambled/rest-smtp-sink. Its Dockerfile is built on progrium/busybox and downloads Node v0.10.36 (a 2015 x64 tarball) — hence AMD64-only and, as reported, no longer runnable even under the AMD64 emulator on M1/M2.

API surface actually used

FakeSmtp.java only relies on a tiny REST contract:

• GET /api/email — list received mails (assertions in assertEmailReceived)
• GET /api/email/purge/{id} — cleanup between tests
• SMTP ingest on the mapped port, REST served on port 80

Consumers (~6 test classes): ForwardSmtpTest, SmtpContentTypeTest, SmtpAuthorizedAddressesTest, DirectResolutionRemoteDeliveryIntegrationTest, GatewayRemoteDeliveryIntegrationTest, GroupMappingRelayTest.

Two possible directions

Option A — Rebuild the Node image multi-arch (matches the issue literally)

• Fork ambled/rest-smtp-sink, bump the base image to a current Node LTS, and build with docker buildx build --platform linux/amd64,linux/arm64, publishing under the linagora/ namespace (e.g. linagora/rest-smtp-sink).
• Then the only James change is the tag in Images.FAKE_SMTP — near-zero code churn.
• Risk: the ~2015 cli.js/index.js app may need small tweaks to run on a modern Node; and it adds yet another image for us to maintain/publish.

Option B — Retire FakeSmtp in favour of the existing linagora/mock-smtp-server

• We already ship and maintain a mock SMTP server in this repo: server/mailet/mock-smtp-server (Images.MOCK_SMTP_SERVER = "linagora/mock-smtp-server:0.7", MockSmtpServerExtension).
• It is built with jib from eclipse-temurin:21-jre-jammy (server/mailet/mock-smtp-server/pom.xml:125), which is inherently multi-arch (amd64 + arm64) — so it already runs on ARM, and is used today by the remote-delivery and vacation-relay integration tests.
• Downside: it exposes a different REST API (/smtpMails, /smtpBehaviors) than rest-smtp-sink's /api/email, so the ~6 test classes' assertions and the FakeSmtp helper would need to be rewritten against MockSmtpServerExtension.

Recommendation

Strategically Option B is the better long-term move: it removes a stale, unmaintained third-party image, gives us ARM support "for free" via a Java/jib image we already own, and collapses two mock SMTP servers into one. The cost is a one-time migration of ~6 test classes.

If the goal is just the quickest unblock for ARM contributors (the issue is flagged low-priority/backlog), Option A is the smaller change — a single multi-arch rebuild plus a one-line tag bump in Images.java.

Either way the blast radius on the Java side is contained to Images.java + FakeSmtp.java (Option A) or those plus the listed test classes (Option B).

---

Generated automatically

[chibenwa]

🤖 Session stats

21 turns | 163s | in=3366 out=9724 cache_read=390072 cache_write=32336 | cost=0.7852 USD