On Thu, May 19, 2022 at 12:05:59PM -0700, "Kevin J. McCarthy" <ke...@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
