New to Mutt, unable to send messages in *any* attempted way
Hello. I already tried every way I could imagine to debug my problem, and simply no dice; thus trying to post everything here as last resort. Using Mutt 1.10.1 (cannot update for now; please don't ask why) Using Postfix /usr/sbin/sendmail ($sendmail variable is empty) Remote mail server just accepts "login" mode IMAP does work correctly *Beforehand*, if you'll answer just with questions without advise, or mock, just ban me better. printf "%b\n" "$msg" | mutt -s "Test message" -e "set my_user=u...@domain.tld; set my_url=smtp.domain.tld; set from='User'; set use_from=yes; set smtp_url=smtp://$my_user@$my_url; set smtp_pass=p4ss; set ssl_starttls=yes; set ssl_force_tls=yes" recei...@domain.tld Could not find the host "" Could not send the message. Tried with and without simple/double quotes for $smtp_url variable, as well as using "%40" instead of '@' printf "%b\n" "$msg" | mutt -s "Test message" -e "set my_user=u...@domain.tld; set my_url=smtp.domain.tld; set from='User'; set use_from=yes; set smtp_url=smtp://$my_u...@smtp.domain.tld; set smtp_pass=p4ss; set ssl_starttls=yes; set ssl_force_tls=yes" recei...@domain.tld Could not connect to smtp.domain.tld (No route to host). Could not send the message. Have to explicitly specify the port; though it varies from ISP to ISP!? In some I need, in some other I don't! printf "%b\n" "$msg" | mutt -s "Test message" -e "set my_user=u...@domain.tld; set my_url=smtp.domain.tld; set from='User'; set use_from=yes; set smtp_url=smtp://$my_u...@smtp.domain.tld:587; set smtp_pass=p4ss; set ssl_starttls=yes; set ssl_force_tls=yes" recei...@domain.tld No authenticators available Could not send the message. I have to explicitly specify $smtp_authenticators variable... Shouldn't Mutt check all possible ones one by one if empty variable, according to manual? printf "%b\n" "$msg" | mutt -n -s "Test message" -e "set my_user=u...@domain.tld; set my_url=smtp.domain.tld; set from='User'; set use_from=yes; set smtp_url=smtp://$my_u...@smtp.domain.tld:587; set smtp_pass=p4ss; set ssl_starttls=yes; set ssl_force_tls=yes" recei...@domain.tld; echo $? 1 Just what?? printf "%b\n" "$msg" | mutt -s "Test message" -e "set my_user=u...@domain.tld; set my_url=smtp.domain.tld; set from='User'; set use_from=yes; set smtp_authenticators=login:gssapi; set smtp_url=smtp://$my_u...@smtp.domain.tld:587; set smtp_pass=p4ss; set ssl_starttls=yes; set ssl_force_tls=yes" recei...@domain.tld login authentication failed, trying next method No authenticators available Could not send the message. printf "%b\n" "$msg" | mutt -s "Test message" -e "set my_user=u...@domain.tld; set my_url=smtp.domain.tld; set from='User'; set use_from=yes; set smtp_authenticators=gssapi; set smtp_url=smtp://$my_u...@smtp.domain.tld:587; set smtp_pass=p4ss; set ssl_starttls=yes; set ssl_force_tls=yes" recei...@domain.tld No authenticators available Could not send the message. printf "%b\n" "$msg" | mutt -s "Test message" -e "set my_user=u...@domain.tld; set my_url=smtp.domain.tld; set from='User'; set use_from=yes; set smtp_authenticators=whatNonsense; set smtp_url=smtp://$my_u...@smtp.domain.tld:587; set smtp_pass=p4ss; set ssl_starttls=yes; set ssl_force_tls=yes" recei...@domain.tld No authenticators available Could not send the message. printf "%b\n" "$msg" | mutt -s "Test message" -e "set my_user=u...@domain.tld; set my_url=smtp.domain.tld; set from='User'; set use_from=yes; set smtp_authenticators=gssapi:login; set smtp_url=smtp://$my_u...@smtp.domain.tld:587; set smtp_pass=p4ss; set ssl_starttls=yes; set ssl_force_tls=yes" recei...@domain.tld SASL authentication failed Could not send the message. And finally: What's the difference between Mutt and Neomutt? Which one preferable?
Re: New to Mutt, unable to send messages in *any* attempted way
On Thu, May 05, 2022 at 12:07:44PM -0500, Kevin J. McCarthy wrote: 1) On the command line, the shell will expand shell variables inside double quoted strings, before Mutt even sees it. So in the part "set smtp_url=smtp://$my_user@$my_url" Mutt is probably only seeing "set smtp_url=smtp://@", because $my_user and $my_url are unset in your shell. You may want to use single-quotes around the whole "-e" expression, but then be careful with nested single quotes, e.g. the set from='User' part. First: had to delete/rename ~/.muttrc, because some previous settings were perhaps conflicting... This seemed to *finally* work (had to play with both single and double quotes...): printf "%b\n" "$msg" | mutt -s "Test message" -e 'set my_user="u...@domain.tld"; set my_url="smtp.domain.tld"; set from="Send User "; set smtp_url="smtp://$my_user:my_p4ss@$my_url:587"; set ssl_starttls="yes"; set ssl_force_tls="yes"' recei...@domain.tld Finally worked -seemingly-, but popped just many doubts: ---There's a "sent email" log in local system, where sent emails are logged. There's always this line: Message-ID: < @ mylocalpcu...@localhost.myisp.com > Is this correct? ---Without "set from=" field, sender becomes "mylocalpcu...@localhost.myisp.com"... What is this? Does the "from" field kind of guarantee that email is being *really* sent from the u...@domain.tld address, and not from *local rig*? ---In "set smtp_url" field, if using "$my_user:my_p4ss" notation, this seems to override the "set smtp_pass" field completely? ---Seemingly not needed smtp_authenticators... ?? ---Without smtp_url and smtp_pass fields, where does email go? recei...@domain.tld doesn't receive it... ---Is email really being sent with STARTTLS, as wanted? How can I tell? ---In "set from=" field, spaces between "Send User" and actual email address... don't seem to matter? Are you able to send email via that account using other applications? Yes, I used to use Heirloom Mailx. Yes. Whether or not you have to explicitly specify the port may depend on the mail server's configuration. This configuration can vary from ISP to ISP. I didn't mean email provider, but ISP internet service I'm connected to. And did test again: I connected to an internet network, did not specify port in smtp_url, tried send email, and got: Could not connect to smtp.domain.tld (No route to host) Tried connecting to a different internet network, tried to send email using *exact* command, without port, and *it succceeded*. WTH?
Re: New to Mutt, unable to send messages in *any* attempted way
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. 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 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? Mutt has some debug flags. Try using the "-d 5" option. Got: "DEBUG was not defined during compilation. Ignored." Any other ways to tell whether email is really being sent with STARTTLS? 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? 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? ---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... ---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? Thanks again.
Re: New to Mutt, unable to send messages in *any* attempted way
Sorry for late answering... On Sun, May 08, 2022 at 04:25:05PM +1000, Cameron Simpson wrote: You're failing in this because you have $smtp_url defined. Comment out it and the other $smtp* variables. When you send with $sendmail (the local system's mail system, postfix for you) the smtp settings come from the main.cf file, not from mutt. OUCH So all this whole time I have been using Mutt's builtin SMTP, the less orthodox way according to Mutt wiki... And seemingly Heirloom Mailx also works this exact way when specifying SMTP options as well >By the way, in Mutt default pager for reading emails, your words between underscores '_' (_not_, _may_, etc...) are not being displayed... Why? I think someone suggested turning off any colouring settings you have active. Possibly some colours match the terminal background colour. Are the words invisible (gaps in the text) or missing (no gaps)? You all were right: setting "uncolor body *" solved it, at least in the Mutt version I'm currently using. I'd really need to try latest release and compare. Hope I'm able to do soon... So finally tried using Mutt the orthodox way: with external sendmail SMTP/MTA. In the end, I chose to begin with Msmtp instead of Postfix... Why? Because after just installation, I realized that Postfix is kind of "overkill" if just wanting to send: it's designed as a full-blown server for sending and receiving. Msmtp, on the other hand, is just a SMTP client; no need to setup a whole server. So first read the Msmtp documentation, and then for sending I first tried: printf "%b\n" "$msg" | mutt -s "Test message" -e 'set my_user="u...@domain.tld"; set my_url="smtp.domain.tld"; set record=""; set sendmail="/path/to/msmtp --port=587 --tls=on --host=$my_url --from="SendUser<$my_user>" --auth=on --user=$my_user"' recei...@domain.tld Incientally "--password" is not a valid command line option; so I was expecting to be prompted for the password, but instead I got this: msmtp: authentication method PLAIN needs a password msmtp: could not send mail Error sending message, child exited 69 (Service unavailable.). Could not send the message. Even after making a very minimalist .msmtprc with *only* the "password" line (trying plain password for now just for testing), I kept getting the above error. I did chmod .msmtprc to 600, BTW. So had to make a full .msmtprc according to documentation, and tried this command: printf "%b\n" "$msg" | mutt -s "Test message" -e 'set my_user="u...@domain.tld"; set my_url="smtp.domain.tld"; set record=""; set from="Send User<$my_user>"; set envelope_from=yes; set sendmail="/path/to/msmtp"' recei...@domain.tld This time it succeeded. ---So, do I really need to set password apart in some of Msmtp's other 4 ways in order to successfully use it? ---To respond a received email in Mutt pager I hit 'r', and all the rest. I only change the destination email address, and eventually send. But even after successfully sent, the "responded" email in Mutt pager is not marked with 'r'. Why? Thanks beforehand yet again.
Re: Having problems with POP3 setup
Thanks for all the advice. I did give Getmail a try, and you're right: it has more features. I'd probably try using it for daily use, like Msmtp, if it weren't for 2 issues: ---No STARTTLS support, only SSL: author at the mailing lists seems to not like very much the idea of implementing it. ---Unlike Msmtp, no direct integration with Mutt: it's run like an entirely separated program, no chance of running it from within Mutt since "custom commands" are not supported, not even with macros. Nevertheless, it's remains an interesting option. Now, three final doubts: ---Why isn't there a default binding for the "imap-fetch-mail" function, just like 'G' for POP3? I know I can assign it, but was curious ---If "LAST" command has been deprecated since long ago, is there a reason to still keep it? In the case of Getmail, is it that it actually does not use this command but another implementation? ---What's the current panorama for POP3 nowadays? Is it still used or is it dying? I heard Yahoo dropped POP3 support since years ago, except for paid users... Thanks again. El 2022-09-02 14:32, Sam Kuper escribió: On Fri, Sep 02, 2022 at 01:11:53PM -0500, X Tec wrote: On 2022-08-31 11:46:15, X Tec wrote: On 2022-08-30 18:34:42, Kevin J. McCarthy wrote: On Mon, Aug 29, 2022 at 03:14:21PM -0500, X Tec wrote: Fetching email with 'G' key just ignores the "pop_last=yes" setting because it always downloads all email regardless of locally read or not, even though other clients such as Outlook or Thunderbird don't do this mistake. So I don't think server doesn't support the LAST command... Run with debugging enabled (-d 2) and check the log file to see what the LAST command response is from the server. Since the command was deprecated some time ago, I would venture the server is returning an unknown command error. With debugger I saw this line: "-ERR Unknown command: LAST"; so I think you were right once again... OK, so that's that mystery resolved. Mutt's POP3 support *is* simple, so if LAST isn't supported, the behavior you are seeing with is expected. You may be happier just directly connecting to a pops:// URL via one of your mailboxes instead; or with a more sophisticated tool, such as Getmail (which Sam mentioned). So if I wanted this function, or the one of "keep messages in server for x days", would I need another external POP3 mail fetcher? Yes. There is one caveat. If the POP3 server is totally kooky, then even Getmail or suchlike might be unable to extract the desired behaviour from it. Fortunately, nothing so far seems particularly kooky about the POP3 server in your case. I did read in the Mutt wiki that Mutt originally didn't intend to have native SMTP support, but it ended up (reluctantly?) being added eventually; which is why I decided to learn Msmtp as well. However, I was unable to find any proof of this being the same case for IMAP and POP3, and I searched the whole wiki and docs. So I thought "so unlike SMTP, Mutt has always been supposed to support IMAP and POP3 natively". But then, must I understand that this is *not* the case for POP3? Could someone still help with these issues please? Mutt *does* support POP3, but as Kevin pointed out above, its POP3 support is simple, i.e. basic. If you want a more sophisticated MRA (i.e. POP3 client), then a third-party MRA such as Getmail will likely suit you better. Mutt roughly adheres to the Unix philosophy - "Make each program do one thing well." Mutt is an *amazing* MUA. It does not excel at anything else. (Nor should it.) Yes, Mutt has MRA and MTA capabilities, but these are limited. It is *good* that these capabilities are limited because that keeps the codebase, and the consequent bug surface and attack surface, small. (Purists might argue that Mutt should not have MRA or MTA capabilities at *all* - but for better or worse, the pragmatists who argued Mutt should have limited MRA and MTA capabilities got their way.) So, if you want an *amazing* lightweight MTA to sit alongside Mutt, msmtp is a great choice - and it seems you made that choice. Ace! Similarly, if you want an *amazing* lightweight MRA to sit alongside Mutt, Getmail is a great choice. Good luck, Sam
Two doubts about POP3 and IMAP
Why isn't there a default binding for the "imap-fetch-mail" function, just like 'G' for POP3? I know I can assign it, but was curious If "LAST" command has been deprecated since long ago, is there a reason to still keep it? In the case of Getmail, is it that it actually does not use this command but another implementation? Thanks again.
