In this journal entry, I documented a solution to an initial failure in using the Plusnet mail servers as a smarthost. That solution is entirely incorrect.
An attempt to send a mail to a GMail address via Plusnet resulted in the following error:
2025-02-01 10:53:12 1teB7g-000j1P-2t rewrite: missing or malformed local part 2025-02-01 10:53:12 1teB7g-000j1P-2t H=avasout-peh-004.plus.net [212.159.14.20]\ X=TLS1.2:ECDHE_X25519__ECDSA_SHA256__AES_256_GCM:256 CV=no F=<> rejected after\ DATA: header syntax (missing or malformed local part: failing address in "From\ :" header is: <>): missing or malformed local part: failing address in "From:" \ header is: <>
I had assumed that the error was from Plusnet, due to a failure of
exim to provide an acceptable From: address. In fact, the error was
generated by exim, in response to a bounce-back message from
Plusnet. The evidence was found in the exim reject log
/var/log/exim4/rejectlog. This showed the following:
Envelope-from: <>
Envelope-to: <someone@example.com>
Received: from avasout-peh-004.plus.net ([212.159.14.20])
by ash with esmtps (TLS1.2) tls TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 Exim 4.96)
id 1teB6q-000j1P-1t
for someone@example.com;
Sat, 01 Feb 2025 10:52:20 +0000
Date: Sat, 01 Feb 2025 10:52:19 +0000
From: <>
To: someone@example.com
Subject: Mail delivery failed: returning message to senderExim’s header check does not like a From: value of <>.
The cause of the bounce-back was my failure to setup an DNS SPF TXT record containing Plusnet, which meant that GMail would reject all mails relayed through Plusnet.
So, the "fix" in this specific case is to make sure the SPF TXT record is correct.
It seems the exim behaviour is due to the default Debian header check configuration, which I initially thought I should leave in place.
However, in the general case of a bounceback message from Plusnet
(say, an attempt to send to an invalid email address), I’d get this
message regarding a malformed From address, and have to remember what
it really meant. To ease my cognitive load, the exim header check is
now turned off, by adding the following line to the file
/etc/exim4/exim4.conf.localmacros:
NO_CHECK_DATA_VERIFY_HEADER_SYNTAX = YES
