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 sender
Exim’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" is to make sure the SPF TXT record is correct.
NB. It seems this exim behaviour is due to the default Debian configuration. It can turned off, but I’d rather have the header check than not.
