Re: New to Mutt, unable to send messages in *any* attempted way
On Thu, May 19, 2022 at 12:05:59PM -0700, "Kevin J. McCarthy" 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
Re: New to Mutt, unable to send messages in *any* attempted way
On Thu, May 19, 2022 at 05:47:06PM -0500, X Tec wrote: Do you think this could be modified in Mutt's source? As in, kind of a Github-like ticket/issue petition to make it work with arguments with spaces... I try asking because you make it sound as if there were doubts regarding why this is currently coded like this. Most likely I'm wrong, but, do you think a small analysis could be in place? Could it be changed *without* compromising security indeed? I think technically it could be changed (albeit it would require careful analysis of potential issues). And of course you are welcome to open a ticket. However, there are a few things weighing against it likely being done: * Right now, Mutt is in maintenance mode - no new development is taking place. I'm just fixing bugs and security issues in the 2.2.x branch. That may change eventually, or it may not. * The $sendmail behavior has been this way since the first git commit recorded. I'm not saying your attempted usage was incorrect. But given this is the first complaint I've heard, I think it's fair to say almost no one tries to parameterize all the config values to the MTA. So there isn't much demand for the change. * There is some risk of introducing behavior changes, or even a security issue. So again, feel free to open a ticket (noting that tickets should *not* be used as a petition), but don't get your expectations very high. Sorry about that. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: New to Mutt, unable to send messages in *any* attempted way
On 2022-05-19 12:05:59, Kevin J. McCarthy 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. > Thanks very much sir. I think this finally closes the last question of this -long- email thread... I'm not sure if marking as "SOLVED", like in forum threads, applies here in mailing lists. But if it does, before actually doing it, just a small last question: Do you think this could be modified in Mutt's source? As in, kind of a Github-like ticket/issue petition to make it work with arguments with spaces... I try asking because you make it sound as if there were doubts regarding why this is currently coded like this. Most likely I'm wrong, but, do you think a small analysis could be in place? Could it be changed *without* compromising security indeed? Of course, if it doesn't turn too impractical, neither; and if it's worth Thanks very much for your help.
Re: New to Mutt, unable to send messages in *any* attempted way
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 signature.asc Description: PGP signature
Re: New to Mutt, unable to send messages in *any* attempted way
On Thu, May 19, 2022 at 11:06:38AM -0700, Kevin J. McCarthy wrote: > On Thu, May 19, 2022 at 12:36:39PM -0500, X Tec wrote: > > set sendmail="/usr/bin/msmtp [...] --passwordeval=$(gpg --no-tty -q -d > > ~/.user.gpg)" [...] > > Hope someone else could give other advise, or if this is really not > > possible in Mutt, to confirm *why*. > > 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... -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. signature.asc Description: PGP signature
Re: New to Mutt, unable to send messages in *any* attempted way
On Thu, May 19, 2022 at 12:36:39PM -0500, X Tec wrote: But this specific part I'm having trouble with seems to be *not* from Bash or system's shell, but from Mutt *itself*; as in, Mutt's own "local shell" or configuration syntax (not sure how to call it...). Nevertheless, I tried your advise, and got this: msmtp: unrecognized option '--no-tty' Error sending message, child exited 64 (Bad usage.). Could not send the message. Hope someone else could give other advise, or if this is really not possible in Mutt, to confirm *why*. 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. -- Kevin J. McCarthy GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA signature.asc Description: PGP signature
Re: New to Mutt, unable to send messages in *any* attempted way
On 2022-05-19 00:25:32, Jon LaBadie wrote: > So I have NO IDEA IF IT WILL WORK, but you might try: > > set sendmail="/usr/bin/msmtp [...] --passwordeval=$(gpg --no-tty -q -d > ~/.user.gpg)" > Thanks very much for your advise. Actually I had already read about all the Bash stuff (and also other shells) regarding quoting rules, as well as variable/command substitutions. But this specific part I'm having trouble with seems to be *not* from Bash or system's shell, but from Mutt *itself*; as in, Mutt's own "local shell" or configuration syntax (not sure how to call it...). Nevertheless, I tried your advise, and got this: msmtp: unrecognized option '--no-tty' Error sending message, child exited 64 (Bad usage.). Could not send the message. You can see all what else I have tried already in my previous messages in this email "thread"/topic. Hope someone else could give other advise, or if this is really not possible in Mutt, to confirm *why*. Thanks again for your attention.
