New to Mutt, unable to send messages in *any* attempted way

2022-05-05 Thread xtec
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

2022-05-05 Thread xtec
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

2022-05-06 Thread xtec
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

2022-05-09 Thread xtec
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

2022-09-03 Thread xtec
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

2022-09-07 Thread xtec
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.