New to Mutt, unable to send messages in *any* attempted way
Cameron Simpson
cs at cskk.id.au
Fri May 6 22:45:35 UTC 2022
On 06May2022 12:28, xtec at trimaso.com.mx <xtec at trimaso.com.mx> wrote:
>Thanks again.
>
>As mentioned in first message, system has Postfix by default, with its
>corresponding /usr/sbin/sendmail and /etc/postfix/main.cf .
>Since I don't have anything for $sendmail variable, it's defaulting
>indeed for Postix sendmail.
Probably not? If you've been debugging the $smtp* variables (in
particular, having to debug the password) then it sounds like mutt is
actually sending directly with SMTP and _not_ using the local postfix.
When you send with the local postfix, mutt just hands the message off to
the sendmail command and doesn't say anything about delivery - that is
sendmail's job.
>On Thu, May 05, 2022 at 19:19:45 -0500, Cameron Simpson wrote:
>>Might be. It won't be a "real" Message-ID line as it looks like the log
>>tries to include the username of the user who sent the email.
>>
>>However, you're using SMTP to smtp.domain.tld, which means you're not
>>using the local mail system, which means that it should not be logging
>>locally for email you send using mutt.
>>
>Sorry... By "log" here I meant the default ~/sent one, default set for
>$record variable
Ah, do this is a real message-id field then. Message ids are specified
here: https://tools.ietf.org/rfcmarkup/5322#section-3.6.4
I'm not sure you can put a second "@" in a message id - my reading of
the grammar says it basicly looks like "<left-part at right-part>".
>>No, it is just what gets written into the heder line so that people
>>know
>>what address to use for replies and citations.
>>
>Then how do I know the email is really being sent from
>user at domain.tld 's account/SMTP?
Hahahaha! You don't!
There are various headers which _may_ be added to messages and which a
receiver _may_ consult to verify identity, but they're not appplied by
default. (They inherently require extra setup, as you need to provide
the extra identity in your config.)
There are headers which confirm that an ISP sent the message - that
would tell the receiver that it can from _where_ it says it comes from,
but not from _who_.
There are DNS records (SPF) which specify where messages for a domain
may come _from_. These can be used by receiving systems to reject
messages from other sources claiming to be from that domain. These are
often loosely defined though, if present at all. Of course, you're then
trusting the receiving system on this point when you collect your email.
>>Mutt has some debug flags. Try using the "-d 5" option.
>>
>Got: "DEBUG was not defined during compilation. Ignored."
Oh, that is unfortunate. You might need to built it from source unless
your vendor provides some kind of "debugging enabled" version of the
mutt package.
>Any other ways to tell whether email is really being sent with STARTTLS?
The Received: headers of the message (when you get it back) record how
the message was received (possibly there will be several of these). For
example, this message of yours as received by me here has this header
for the final hop:
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail.cskk.id.au (Postfix) with ESMTPS id 773F343999
for <cs at cskk.id.au>; Fri, 6 May 2022 17:35:24 +0000 (UTC)
The second line doesn't say that STARTTLS was used, just that TLS was
used. That implies either a cleartext connect with a STARTTLS, or a
TLS/SSL connection directly. Encrypted either way.
Of course, you need to trust the content of those headers.
>On Thu, May 05, 2022 at 23:06:15 -0500, Nathan Stratton Treadway wrote:
>>Some ISPs specifically block outgoing traffic on TCP port 25 (which is
>>the default port for "smtp:" traffic)
>>
>Which means, if not specifying port then Mutt (or Postfix?) takes port
>25 as SMTP default...
>Wasn't/shouldn't port 587 the new default for SMTP?
>So Heirloom Mailx also takes port 25 as default?
Maybe? You could check its docs or help messages. You could get really
funky and watch it send your email. here's me testing the "nc" command
on a local Ubuntu system:
[~]borg*> strace -e trace=network nc 127.0.0.1 25 </dev/null
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory)
socket(AF_INET, SOCK_STREAM|SOCK_NONBLOCK, IPPROTO_TCP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EINPROGRESS (Operation now in progress)
getsockopt(3, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
220 borg.********** ESMTP Postfix (Ubuntu)
Now, I've _told_ it to use port 25, but you can see that reflected in
the connect() calls.
You can trace a running process (such as your Mailx programme) with its
pid, eg:
strace -e trace=network -p pid-of-the-programme-here
To see what it is doing. Once attached you then want to send a test
message and see what happens.
>Also, some more doubts aroused:
>
>---If adding the "-n" option to whole email sending command, it does
>*nothing*, just immediately getting an exit status of '1'. What's
>happening with this?
"man mutt" says that:
-n Do not read the system-wide Muttrc configuration file.
If you're getting an exit 1, I'd expect some kind of error message as
well.
>---Where in the manual can I find the meaning of each of the %Z
>letters here http://www.mutt.org/doc/manual/#index-format ? I mean,
>the letters norON, DdSPsK...
It's right there in the table:
%Z a three character set of message status flags. the first
character is new/read/replied flags (“n”/“o”/“r”/“O”/“N”).
the second is deleted or encryption flags
(“D”/“d”/“S”/“P”/“s”/“K”).
the third is either tagged/flagged (“*”/“!”), or one of the
characters listed in $to_chars.
Ah, there's more detail in "5.1 The Message Index" here:
http://www.mutt.org/doc/manual/#tab-msg-status-flags
http://www.mutt.org/doc/manual/#tab-msg-recip-flags
>---When browsing emails in Mutt, why do sizes inside () -for example,
>(1.1K)- change to something different and smaller -( 6)- when hitting
>enter to display the message?
They don't for me. Are you sure you're not confusing the index lines
(one per message, specified by $index_format) with the header shown
above a specific message when you're viewing it? Got an example?
Cheers,
Cameron Simpson <cs at cskk.id.au>
More information about the Mutt-users
mailing list