The consideration with this is that you have no idea or control over the setup or onfiguration of any of the mail servers that the mail may pass through or land on on it’s journey.
It might be that spam senders hitting seconary servers are hoping to stumble across a misconfigured server operating as an open relay.
I have setup a new mail processing server at mx.librem.one running on Debian Trixie with checks for SPF, DKIM and DMARC. This will eventually replace mx1.librem.one which is running on an old version of PureOS and had error with DKIM checks, so all checks were disabled.
If you are running your own mail server, you can help test it.
You can install msmtp and create ~/.msmtprc on your mail server with
account <your_username@domain.tld>
host mx.librem.one
from <your_username@domain.tld>
Then create a text file test-mx-libremone.txt
From: <your_username@domain.tld>
To: <steliosadmin at librem.one>
Subject: Testing mx.librem.one service
via mx.librem.one
msmtp -a <your_username@domain.tld> -t <test-mx-libremone.txt
If you have postfix, you can add /etc/postfix/transport
librem.one :[mx.librem.one]
.librem.one :[mx.librem.one]
This will route all mails via mx.librem.one and you can use your normal email client to send an email to steliosadmin at librem.one.
I have updated /etc/postfix/transport on ms.librem.one so all Librem.One to Librem.One mails are passed through mx.librem.one as part of testing. The test mail I sent was delivered successfully.
Authentication-Results: OpenDMARC; dmarc=pass (p=reject dis=none) he
ader.from=librem.one
Authentication-Results: mx.librem.one; dmarc=pass (p=reject dis=none
) header.from=librem.one
Authentication-Results: mx.librem.one;
dkim=pass (2048-bit key; unprotected) header.d=librem.one he
ader.i=@librem.one header.a=rsa-sha256 header.s=ms header.b=fJB1W05A;
dkim-atps=neutral
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=5.78.113.60; helo=ms.librem.one; envelope-from=steliosadmin at librem.one; receiver=librem.one
Received: from ms.librem.one (ms.librem.one [5.78.113.60])
by mx.librem.one (Postfix) with ESMTPS id 6F8FC20D7A
for <steliosadmin at librem.one>; Mon, 27 Apr 2026 00:54:17 -0700 (PDT)
puri.sm to librem.one delivery was also tested successfully in the same way.
This procedure has always worked hitherto, I send an email with a pdf attachment from work, I I modify the attachment in GIMP, then reply to my own email, re-attach the pdf, then send it back. Using T-Bird.
Workaround: I switched my sender in T-Bird to my gmail address in order to send it.
Looks like it needs the attention of @praveen.arimbrathodi
If I were he, I would be asking you to enable a connection (session) log on the client side and supply it. However I assume that he will have access to adequate logs on the server side anyway.
I could be wrong but I think Thunderbird used to have a sane UI to enable logging but it seems that that is not the case.
Update, I also get the same error without an attachment.
I wonder did mx.librem.one become mandatory? I am set to smtp.librem.one.
Technically, MX is for inbound email i.e. sent to librem.one from outside that domain - whereas, if I understand your scenario correctly, you are talking about outbound email i.e. sent from librem.one to another domain.
mx1 (current inbound), mx (new inbound) and smtp/ms (outbound) all appear to be distinct servers.
Ok, then I should change imap.iibrem.one to mx.librem.one.
Do I still set it to port 993?
Edit:
After changing it to mx, I tried sending an email from myself to myself on librem.one same error.
Also tried sending one from outside librem.one (gmail) to myself, nothing after 5 minutes. I changed it back to imap, then it showed up.
No, sorry.
By inbound I was distinguishing between the two scenarios of mail server ↔mail server, not mail server → end user.
When the server was rebooted for copy.fail kernel update, postfwd (postfix firewall/rate limiting) service did not start automatically. This is fixed now, let me know if you are still having problems. Sorry for the unexpected downtime.
In this case, mail from gmail will be received by mx(2).librem.one and will do the domain authentication settings (ip addresses allowed to send mail for gmail.com and digital signature added by gmail.com). Mails that pass authentication checks will be passed to imap.librem.one and others discarded. Users will always check mails via imap.librem.one. Only the intermediary server between other mail servers and end user receiving server is changing. So this can only be tested by people running their own mail servers.
I have now activated mx.librem.one as the preferred mx server which now enforces dmarc for sending domain authentication. A test mail sent from my debian.org was validated correctly. More people confirming they are able to receive mails with the new mx server would be great.
Received: from mx.librem.one (mx.librem.one [5.78.194.171])
by imap.librem.one (Postfix) with ESMTPS id 8D83581654
for <steliosadmin at librem.one>; Mon, 4 May 2026 08:53:25 +0000 (UTC)
Authentication-Results: OpenDMARC; dmarc=pass (p=none dis=none) header.from=debian.org
Authentication-Results: mx.librem.one; dmarc=pass (p=none dis=none) header.from=debian.org
Authentication-Results: mx.librem.one;
dkim=pass (2048-bit key; unprotected) header.d=debian.org header.i=@debian.org header.a=rsa-sha256 header.s=smtpauto.stravinsky header.b=nrnFEqia;
dkim-atps=neutral
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2001:41b8:202:deb::311:108; helo=stravinsky.debian.org; envelope-from=praveen at debian.org; receiver=librem.one
Received: from stravinsky.debian.org (stravinsky.debian.org [IPv6:2001:41b8:202:deb::311:108])
by mx.librem.one (Postfix) with ESMTPS id D57E31F50B
A test message worked fine about 0707 EDT.