On 06May2022 12:28, x...@trimaso.com.mx <x...@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@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 >u...@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 <c...@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 <c...@cskk.id.au>
