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

[raf]

On Thu, May 19, 2022 at 12:05:59PM -0700, "Kevin J. McCarthy" <kevin at 8t8.us> wrote:

> On Thu, May 19, 2022 at 01:12:31PM -0500, Derek Martin wrote:
> > On Thu, May 19, 2022 at 11:06:38AM -0700, Kevin J. McCarthy wrote:
> > > Sorry, this isn't currently possible in Mutt.  The $sendmail variable is
> > > handled specially: it's tokenized by space and invoked directly via
> > > execvp().  So you won't be able to use arguments with spaces in them inside
> > > the variable, or any shell quoting since it doesn't pass through the shell.
> > 
> > Couldn't you do something like the following?
> > 
> > set my_sendmail=/usr/bin/msmtp [...] --passwordeval=$(gpg --no-tty -q -d ~/.user.gpg)"
> > set sendmail=$my_sendmail
> > 
> > Don't know, haven't tried it, but as long as the first thing evaluates
> > to something that sendmail's tokenization can handle, seems like it
> > should work...
> 
> $sendmail goes through muttrc evaluation like other variables, but when
> invoked to send an email, the resulting string is tokenized by space, '--'
> and various arguments inserted as needed, and then passed to execvp().
> 
> Yes, this should be documented and I'll add it to the config option shortly.
> 
> I don't know why it was written this way, perhaps some security concerns,
> but I agree that it's surprising.
> 
> -- 
> Kevin J. McCarthy
> GPG Fingerprint: 8975 A9B3 3AA3 7910 385C  5308 ADEF 7684 8031 6BDA

I think the reason would be that mutt is modifying the
command, not just executing it. It's modifying a
command in a complex external language that it can't
parse by itself unless it imposes very strict
limitations on the allowable syntax of the command.
I don't think it's a security decision. It's just
necessary. How would mutt know how to modify
sendmail="blah1 | blah2 | blah3" ?

I think this limitation should be documented, but not
fixed. It could be fixed by adding something like %
interpolation placeholders for the things that are
added. But that might break existing commands that
contain %. Maybe # would be a better choice. But it's
still a bad choice. It requires the user to know and
use even more notation.

An elegant solution already exists. Put complex shell
commands in a file and mutt only needs to see its name.

But users need to be told when they are required to do
that. So in addition to documenting the limitation, a
new error message when the evaluated $sendmail contains
any (non-space) shell meta-characters would be helpful.
That's a clear indication that the user is expecting
shell parsing that isn't going to happen.

cheers,
raf