<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[hMailServer 6.2.17: relayed mail could stall after end-of-data with no 250]]></title><description><![CDATA[<p dir="auto">If your server accepts inbound mail from a trusted relay, a Proxmox/Postfix front end for example, and you run SpamAssassin, messages could stall after end-of-data and never get a 250. Reception was never the problem. The stall was in the accept/save work that runs after the terminating dot and before the reply.</p>
<p dir="auto"><strong>What the upgrade involved</strong></p>
<p dir="auto">No database change. Schema version stays at 6005.</p>
<p dir="auto">The same audit found other unbounded waits, not fixed here: synchronous DNS lookups in the spam tests have no application-level timeout, the database connection pool has no acquisition deadline, event scripts have no execution limit, and the ClamAV read/write timeout on delivery is ineffective.</p>
<p dir="auto"><strong>Why it only ever hit relayed mail</strong></p>
<p dir="auto">For a trusted incoming relay, hMailServer defers the whole spam battery to after end-of-data. For a direct or authenticated sender those tests run earlier, during MAIL FROM/RCPT TO, on the connection thread. The post-DATA work runs on a bounded pool, 15 threads by default, and holds the thread that sends the 250. SpamAssassin's wait had no overall ceiling: the connection's idle timeout is re-armed on every byte received, so a scanner that stalls or dribbles holds the thread indefinitely. Against a blackholed SpamAssassin endpoint, one message was acknowledged after 120 s. Eighteen concurrent messages produced zero acknowledgements: 15 workers blocked, the rest with no worker at all.</p>
<p dir="auto"><strong>The fixes</strong></p>
<ul>
<li>SpamAssassin's wait is bounded. Hard ceiling of SAMaxTimeout + 30 s, after which the message is accepted without a verdict, the same outcome as spamd being down.</li>
<li>New <code>FinalizationTimeout</code>, default 240 s, inside Postfix's 600 s data-done timeout, 0 disables it. Acceptance past that answers 451 4.3.1 and the sender retries. The check runs on the accepting thread and only before anything is saved, so it cannot duplicate mail.</li>
<li>Acceptance is timed per stage and each spam test timed individually. A slow stage is logged at APPLICATION level, not only under debug: <code>Spam test: SpamTestSpamAssassin, Score: 0, Time: 120031 ms</code>.</li>
</ul>
<p dir="auto">Upgrading is enough to turn silent stalls into either a completed delivery or a clean 451 retry. Enable debug logging and the per-stage timings name the scanner, DNS lookup or event script responsible.</p>
<p dir="auto">Also in this release: regression coverage for clients that vanish mid-operation (aborted DATA, truncated BDAT, IMAP APPEND literals cut short, POP3 disconnects during RETR), plus an installer smoke test on a clean machine.</p>
<p dir="auto"><a href="https://www.progressiverobot.com/hmailserver-downloads/" rel="nofollow ugc">Full release notes, checksums and signatures</a></p>
]]></description><link>https://www.hmailserver.co.uk/topic/28171/hmailserver-6.2.17-relayed-mail-could-stall-after-end-of-data-with-no-250</link><generator>RSS for Node</generator><lastBuildDate>Wed, 23 Sep 2026 04:32:13 GMT</lastBuildDate><atom:link href="https://www.hmailserver.co.uk/topic/28171.rss" rel="self" type="application/rss+xml"/><pubDate>Wed, 12 Aug 2026 02:31:29 GMT</pubDate><ttl>60</ttl></channel></rss>