v1.0.0

pushmails-client 1.0.0

First release. pushmails-client sends your PushMails campaigns from your own
server: it connects to the central system over one-way HTTP, pulls the mail
waiting to be sent, delivers it and reports the results. The mail leaves your
infrastructure, from your IP address — the sending reputation is yours.

What it does

• Delivers by itself. Looks up each recipient's MX and talks to it directly.
  No Postfix, no Exim, no smarthost. If you would rather keep an existing relay
  in the path, --mode relay does that instead.
• Signs every message. DKIM keys come from the central system, one per
  verified sending domain, held in memory only — nothing is written to disk and
  there is nothing to configure.
• Handles bounces. VERP envelope senders (bounce+<id>@<your bounce domain>)
  so a rejection that arrives after delivery can still be matched to its message
  and the address cleaned from your list.
• Knows when not to send. Before each round it reports what it can measure
  locally and the central system decides: a blocked port 25, a missing PTR
  record, an unverified domain or an exhausted quota stops sending with a named
  reason rather than a queue that silently goes nowhere.
• Loses no work. Claimed jobs return to the central queue if they are never
  acknowledged, so a crash or a reboot costs nothing. A stop is graceful: the
  batch in hand is finished and reported first.
• Runs behind NAT. Outbound HTTPS only; no inbound port, no persistent
  connection.

Installing

Debian, Ubuntu

sudo apt install ./pushmails-client_1.0.0_amd64.deb

RHEL, Fedora, Rocky, Alma

sudo dnf install ./pushmails-client-1.0.0-1.x86_64.rpm

Both install the binary to /usr/bin, a hardened systemd unit to
/usr/lib/systemd/system and the config to /etc/pushmails/client.cfg
(mode 0640, group pushmails). The service is not started on install — the
shipped config has no token, so it could only fail. Put your token in the file,
then sudo systemctl enable --now pushmails-client.

Windows

Run pushmails-client-1.0.0-x64.msi (or -arm64.msi). It installs the binary,
the config at C:\ProgramData\PushMails\client.cfg and registers the
pushmails-client service on manual start. Fill in the config, then:

Start-Process notepad -ArgumentList "C:\ProgramData\PushMails\client.cfg" -Verb RunAs

Then turn it on:

start sc.exe -ArgumentList "config pushmails-client start= auto" -Verb RunAs
start sc.exe -ArgumentList "start pushmails-client" -Verb RunAs

From source — Go 1.23+, go build ./cmd/pushmails-client. Plain binaries for
Linux, macOS and Windows are attached to this release as well.

Before it can send

• An agent token from the panel: Sender servers → Add server. Shown once.
• A bounce domain of yours, with the MX and SPF records the panel lists.
• In the default direct mode: outbound port 25, and a PTR record for the address
  the machine sends from. Many providers block port 25 by default and lift it on
  request. Without it, use relay mode.
• Your sending machine's address added to the SPF record of every domain it
  sends for. The include that authorises our servers says nothing about yours.

Run it once with --dry-run --log-level debug first: the connection, the token
and the job-claiming round trip are exercised, and no mail is sent.

Notes

• Upgrades keep your edited config. On RPM systems the new example lands beside
  it as client.cfg.rpmnew; on Windows the MSI leaves the file untouched.
• Removing the Windows installation deletes the config, token included. Copy it
  first if you plan to reinstall.
• Started as a Windows service the client has no console, so it logs to
  C:\ProgramData\PushMails\client.log, rolling over at 10 MB. Under systemd it
  logs to the journal as usual.
• Sending decisions — domain warm-up, content review, automatic pausing, quotas —
  stay with the central system. The client only ever receives less work; there is
  nothing to keep in sync on your side.

MIT licensed. Full documentation is in the README.