Shells Angels

What rspamd's neural module is actually learning

Mon, 18 May 2026 11:00:00 +0200

If you have switched on rspamd’s neural module, watched it tick along for a quarter, and noticed that the network is contributing almost nothing useful — NEURAL_HAM firing on most of the inbound stream, never moving the score in any direction that matters — the explanation is usually not a bug. The module is doing what the config tells it to. The mental model in your head doesn’t match.

The thing to internalise first is what the network actually reads. The body of the message never reaches it. There is no tokeniser, no embedding, no representation of “what spam looks like” learned from bytes on the wire. The inputs are the firing pattern of every other enabled rspamd symbol for the message being scored: BAYES_SPAM, DKIM_REJECT, your noisy RBL_FOO, the MULTIMAP-derived greylist hint, the spamtrap signal, whatever else you have wired in. That floating-point vector goes through a small feedforward network — one hidden layer in stock, two if somebody tuned it, tanh activation, small enough to evaluate in microseconds on the same core that did the regex pass — and the network emits one scalar that becomes the contribution of one more symbol (NEURAL_SPAM or NEURAL_HAM) to the final score.

What `set -e` actually does (and why your script still leaks)

Tue, 12 May 2026 08:00:00 +0200

You’ve seen this line. You probably wrote it this morning. Almost every “robust bash script” preamble on the internet starts with some variant of:

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'

It is, line for line, the most copy-pasted snippet in the DevOps world. And almost every engineer I have worked with, including (until embarrassingly recently) me, has been wrong about what set -e does.

This post is about the rules. Not the folklore.

SIGSEGV at 03:14 — when forbid(unsafe_code) doesn't save you

Tue, 28 Apr 2026 09:30:00 +0200

The first page came in on a Tuesday. 03:14 AM local. Not 03:00, not 03:30. 03:14, for four nights in a row.

The journal entry that woke me up:

[2026-04-22T03:14:07.882Z] worker[7]: received signal: SIGSEGV (11)
[2026-04-22T03:14:07.882Z] worker[7]: fault address: 0x7f9c1afc0000 (not mapped)
[2026-04-22T03:14:07.882Z] worker[7]: dumping core to /var/crash/inventory-7.core.gz
[2026-04-22T03:14:08.014Z] worker[7]: exit code 139
[2026-04-22T03:14:08.014Z] systemd[1]: inventory-svc.service: Main process exited
[2026-04-22T03:14:08.015Z] systemd[1]: inventory-svc.service: Scheduling restart in 5s.

The service is in Rust. Seventeen crates in the workspace, every one with #![forbid(unsafe_code)] at the top. Rust services crash, but they crash so seldom that this one woke the whole team within an hour. By the third night we had a war room.

io_uring for people who already know epoll

Mon, 30 Mar 2026 11:00:00 +0200

If you have written a network service in C or Rust on Linux in the last twenty years, you know epoll. You know the dance: epoll_create1, epoll_ctl, epoll_wait, set non-blocking, read until EAGAIN, write until EAGAIN, mind the edge-triggered semantics, mind EPOLLRDHUP, mind EPOLLET + EPOLLONESHOT and the dozen footnotes attached to each.

io_uring is the Linux answer to “what if we stopped doing one syscall per I/O and did batched, async, completion-based I/O instead.” It landed in 5.1 (2019) and has been growing every kernel release since. By 2026 the API surface is large and the ecosystem has finally caught up.

About

Mon, 01 Jan 0001 00:00:00 +0000

What this is

Shells Angels is the tech blog of NETitwork . The kind of thing you bookmark on a Sunday afternoon to learn something new from people that live on the boundaries of technical challenges or daily operational routine in enterprise networks. Each post is meant to be a reference — something that survives skimming and still rewards careful reading.

The topics that come up here:

Unix shells & POSIX trivia — the weird edges of bash, zsh, fish, dash; signal handling; subshells; pipelines with exit codes nobody respects.
Kernel & systems internals — Linux/Unix process model, syscalls, namespaces, eBPF, the io_uring saga.
Exploit dev & defensive security — heap shapes, mitigations, sandbox escapes; the angel/devil dichotomy in our threat models.
Distributed systems failure prevention — what happens at 03:14 AM and why it’s almost never the thing on the dashboard.
Tooling & ergonomics — terminals, debuggers, profilers, and the slow art of building a workshop you trust.
Cool tech & solutions - Cool tech from environments with the highest possible demands in stability, security and/or compatibility

What this isn’t

A newsletter. Plug in the RSS feed and you’re done.
A list of ten things, including the one that will shock you.
Anywhere your data goes. There is no analytics script, no third-party font, no cookie banner because there are no cookies.
A money source. We take the TED approach: “Ideas worth sharing”.

How it’s built

The full source — including this page — is plain markdown, plain CSS, and ~3 KB of optional JavaScript that handles theme switching and some bling bling. Everything still works with JS disabled; the content is the point.