From Newsgroup: alt.os.linux.mint
On Tue, 7/14/2026 3:26 PM, Graham J wrote:
Paul wrote:
[snip]
Well, the 3 minute delay "smells of networking" :-)
The machine connects to the internet to update itself and install packages.-a To use this machine I connect to it over my LAN using RDP from a Windows PC.-a So I think the networking is OK.
I picked a couple sentences that look like "a failure to communicate".
While this is an old posting, I don't think issues like this have gone away. >>
https://askubuntu.com/questions/233576/msmtp-hangs-instead-of-delivering-the-message
-a-a-a-a "you can try setting tls_starttls off in the defaults section of ~/.msmtprc.
-a-a-a-a-a Also check that the port is correct."
I do have the correct port.-a Other (Windows) machines here all use port 465 to communicate with the server in question.
I see that tls_starttls defaults to on and understand that this is incompatible with my server wanting ssl.-a So I now have:
tls off
tls_starttls off
There's no improvement.
Does the line:
msmtp: the server sent an empty reply
... really mean that the server did not actually send a reply?
How can I get the debug option to work?
You probably want
tls on
tls startls off
port 465
at least, according to this description:
"The default behavior for tls on is to expect a plain SMTP connection and upgrade it to TLS
using the STARTTLS command, as you would usually have on port 587 (or sometimes port 25).
Port 465 isn't usually set up that way rCo the connection instead immediately starts off with
a TLS handshake, so you need to specify that using tls_starttls off.
"
It's the same kind of advice in Section 8.9 here.
Arch web pages are frequently used by other distros, for their
inspirational value. The Gentoo handbook is good for a few basics too.
https://wiki.archlinux.org/title/Msmtp
*******
For this purpose, TLS is the more secure option. Your browser
for example, is likely set right now, to only negotiate within
either TLS 1.2 or TLS 1.3 .
https://en.wikipedia.org/wiki/Transport_Layer_Security
Status
SSL 1.0 Unpublished Unpublished
SSL 2.0 1995 Deprecated in 2011
SSL 3.0 1996 Deprecated in 2015
TLS 1.0 1999 Deprecated in 2021
TLS 1.1 2006 Deprecated in 2021
TLS 1.2 2008 In use since 2008
TLS 1.3 2018 In use since 2018
*******
When a server sends an empty reply, that is with respect to
how servers normally respond. They respond with a code and
a "text string" which is basically an acknowledgement of the
kind of service you have reached. An empty reply, implies
no server sent the reply, and some sort of ACK/NACK in the
comm stack, terminated the session.
We use telnet a lot, to numbered ports, as a means of
verifying a service is on that port. Telnet of course,
is not secure, you would not be entering a username:password
in plaintext there. Your mission basically is just to verify
that the "correct response" comes back and it wasn't an
immediate "connection closed by remote end".
You can see this, if you run a USENET session and fire up Wireshark
while connecting on an unencrypted port. You might see a "211"
message and details of what kind of server you're talking to. The
SMTP server you're trying to reach, also has a message of that
sort. When that message does not arrive, MSMTP knows something
is wrong, and that error you got, indicates an abnormal termination
of the start of a session (a protocol problem).
I run a mail server in a VM, and while the software claims to
support six connection types, the author lies, as he has disabled
all the unencrypted connections and only supports the three encrypted ones. Your attempt to connect with an older email client, it's not
going to be able to get the welcome message from HMailserver.
You would get a snotty response, due to the limited protocols left.
*******
Since I have no experience at all with this (except at the conceptual level),
I can use CoPilot for a backgrounder.
**************************** CoPilot Question ******************************* Using the current version of msmtp in Linux, is there still a debug option,
and if so, how do I get that debug option working ? Does it only work
with some logging systems now, or does it still have legacy debugging capabilities ? Ecosystem is Debian/Ubuntu/Linux Mint.
**************************** CoPilot Answer ********************************* **Short answer:** Yes rCo *msmtp still has a real debug mode*, and on Debian/Ubuntu/Linux Mint
it works exactly the same way it always has. You enable it with `-d`, `-v`, or `--debug`,
and it prints the full SMTP conversation to **stderr**. It does *not* require any special
logging subsystem, and it has *not* dropped its legacy debugging behavior. [Debian Manpages] (
https://manpages.debian.org/msmtp)
[Ubuntu Manpage Repository] (
https://manpages.ubuntu.com/manpages/noble/man1/msmtp.1.html)
## **Current msmtp debug capability (Debian/Ubuntu/Mint)**
All current DebianrCafamily distributions ship msmtp in the **1.8.x** series (1.8.24rCo1.8.32 depending on release). In these versions, the manpage explicitly documents:
-v , -d , --debug
**rCLPrint lots of debugging information, including the whole conversation with the SMTP server.rCY**
[Debian Manpages] (
https://manpages.debian.org/msmtp)
[Ubuntu Manpage Repository] (
https://manpages.ubuntu.com/manpages/noble/man1/msmtp.1.html)
This is the same legacy debugging mechanism msmtp has had for years.
### What it prints
- SMTP commands and replies
- TLS negotiation details (if applicable)
- Authentication steps
- Internal status messages
- **Passwords may appear in decodable form** (msmtp warns about this) [Debian Manpages](
https://manpages.debian.org/msmtp)
### Where it prints
- **Always to stderr**, not syslog
- No special logging daemon required
- No NSPR, MOZ_LOG, or other subsystem involved (those are ThunderbirdrCaspecific)
---
## **How to use debug mode**
### **1. Command-line invocation**
msmtp -d
recipient@example.com < message.txt
or:
echo "Test message" | msmtp -d
recipient@example.com
### **2. Enable debug in a wrapper script**
If you use msmtp as your systemrCOs sendmail replacement:
sendmail="/usr/bin/msmtp -d"
### **3. Capture debug output**
echo "Test" | msmtp -d
recipient@example.com 2>debug.log
## **Does msmtp support any rCLnewrCY logging systems?**
**No.**
msmtp does **not** integrate with:
- systemd journal
- syslog
- NSPR/MOZ_LOG
- glib logging
- any structured logging framework
It only supports:
- **stderr debug output** (via `-d` / `--debug`)
- **exit codes** (sendmail-compatible)
- **optional logfile** via the logfile directive in ~/.msmtprc (this logs *deliveries*, not protocol debug)
There is **no modern replacement** for the legacy debug mode rCo because the legacy mode still works perfectly.
---
## **Legacy debugging status**
The debug option is unchanged across:
- Debian bookworm
- Debian trixie
- Ubuntu 22.04 raA 24.04 raA 26.04
- Linux Mint 21rCo22
All manpages from 2022rCo2024 confirm the same wording and behavior.
[Debian Manpages] (
https://manpages.debian.org/msmtp)
[Debian Manpages] (
https://manpages.debian.org/trixie/msmtp/msmtp.1.en.gz)
## **If debug output does *not* appear**
This is rare, but here are the only known causes:
1. **You are calling msmtp through a wrapper that discards stderr**
(e.g., some PHP mail wrappers)
2. **Your .msmtprc uses syslog logging**
--> This logs *deliveries*, not debug output.
3. **Your MTA replacement script redirects stderr**
--> Fix by editing /usr/sbin/sendmail symlink or wrapper.
4. **You are using msmtp-mta package**
--> It still supports -d , but your calling program may not pass it through.
---
## **Bottom line**
- **Debug mode still exists.**
- **It still works the same way.**
- **It prints directly to stderr.**
- **It does not depend on any external logging system.**
- **It retains full legacy debugging behavior.**
If you want, I can also show you:
- How to force debug mode when msmtp is used as `/usr/sbin/sendmail`
- How to configure a logfile for delivery events
- How to interpret the SMTP conversation msmtp prints
Just tell me what direction you want to go.
**************************** End: CoPilot Answer *********************************
An LLM-AI always likes to double down. It seems quite insistent that
there is an argument for the command line, plus the output goes to STDERR.
Paul
--- Synchronet 3.22a-Linux NewsLink 1.2