mixandClaude Opus 5.5
af130e268a
Technical review (Opus) and security review (Fable) of 5be109b..5154bba;
reports in the session's scratchpad. Nothing above low from security; one
bug and three risks from the technical review. Migration 0009 is not
deployed, so it was extended.
- Bug: two refusals of one second swapped their NOQUEUE lines (each line
went to the newest lineless row). AttachRefusalLine now matches the
client address too (send_log.client_ip, written by the journal milter -
Postfix's line names the client and the sender, never the login: the
sasl_username part of the pattern never matched and could be fed by HELO,
security F1/F2), takes the nearest row in time and the oldest of equals,
and a line already on a row goes on no other (security F6).
- Waiting lines and recoveries lived only in memory while the saved offset
moved past them: a stop within 30 s lost them. The tracker now never saves
an offset past the oldest waiting item in its file (tracker.hold,
refusalLines.oldest) - for a recovery, the client= line that names its
login - so they are read again; the "once" guards make that harmless.
- A recovered row whose login the tailer did not see was nobody's: its
domain_id falls back to the envelope domain's.
- The fingerprint's file identity is the inode alone: the device number can
change across a host reboot and make the same log look rotated.
- A refused row carries its queue id; UpdateStatus's "newest row" now skips
refused rows, so a later message with that id does not flip it to sent.
- The alive mark: its age is read first and kept from then on, so asking
supervisord for 30 s cannot make it stale; the entrypoint removes it with
the sockets - a container restart is not the check's downtime, and a mark
from before would have counted the whole outage as "≈".
- Security F3: the sender check prints no ";" of the client's in the From:
text of its reply, and the tailer reads the envelope after the first ";"
- Postfix's own text.
- A refused row with a queue id and no stored lines says so (it was told the
mail.log text of 2.2.0); the fact's em dash is the house hyphen.
- Docs: architecture (client address, no login), guide § Health (warns on
either count), help topics log and sender-check (design 1ca87f2).
- e2e: refusals_show_postfixs_line wants the refusal's own sender in the
line; refusal_recovered_from_the_log waits past the tailer's 30 s and
checks that a refusal the panel wrote got no recovered twin.
Not changed, written down: review 9 (mail.log.1 read to its end at that
moment; postlogd may still write to it until the reload), 10 (a log under
512 bytes has no fingerprint, so places fall back to time briefly after a
rotation), 6 (a 451 at MAIL FROM of another milter reads the same - the
client and sender must match too now), security F5/F12 (info). Review 12:
the refused and closed-by-the-panel variants of out-message were shown to
the owner as pictures of the real templates, not drawn in out-message.html:
the guard ties every drawn screen to a page of the engine, and a variant
has the page's outline.
Evidence on the test server for this tree: go vet clean, go test ./... 23
packages ok, make e2e exit 0 (refusal_recovered_from_the_log 70 s).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
31 lines
2.0 KiB
SQL
31 lines
2.0 KiB
SQL
-- What Postfix wrote about a refusal (audit 2026-10-12, stage 2b). A message
|
|
-- the journal milter refuses at MAIL FROM - a level-2 limit, a client address
|
|
-- off the application's list - has no queue id, and Postfix's one line about
|
|
-- it, "NOQUEUE: milter-reject: MAIL from ...", was nowhere the message's page
|
|
-- could find it. The log tailer puts it on the row it belongs to. A message
|
|
-- refused for its From: line has a queue id (cleanup gives one before the
|
|
-- headers are judged), and its lines are found by it like any other's.
|
|
-- DDL only; a row written earlier has '' and says so on its page.
|
|
ALTER TABLE send_log ADD COLUMN refusal_line TEXT NOT NULL DEFAULT '';
|
|
-- The client a refusal at MAIL FROM came from, as the milter saw it: Postfix's
|
|
-- line names the client and the envelope sender and nothing else - no login
|
|
-- - so the two together are what finds the line's row; the sender alone would
|
|
-- let one application's line land on another's row of the same sender
|
|
-- (security review of stage 2b).
|
|
ALTER TABLE send_log ADD COLUMN client_ip TEXT NOT NULL DEFAULT '';
|
|
|
|
-- A refusal row the panel did not get to write - the sender check answers 550
|
|
-- and writes the row a moment later, and a panel stopped in between wrote
|
|
-- none - is written by the log tailer from Postfix's line about it, and marked
|
|
-- so: recovered = 1.
|
|
ALTER TABLE send_log ADD COLUMN recovered INTEGER NOT NULL DEFAULT 0;
|
|
|
|
-- The Sender check card counts two things apart (the owner, 2026-10-14):
|
|
-- deferred stays the connections Postfix turned away while the check did not
|
|
-- answer, and messages are those deferred in the middle, when the check
|
|
-- stopped answering after a message had begun (cleanup's warning). estimated
|
|
-- marks a day whose downtime was taken from the alive mark alone, because
|
|
-- supervisord could not say at start since when Postfix ran: an upper bound.
|
|
ALTER TABLE sender_check_days ADD COLUMN messages INTEGER NOT NULL DEFAULT 0;
|
|
ALTER TABLE sender_check_days ADD COLUMN estimated INTEGER NOT NULL DEFAULT 0;
|