gmailieer: behave more like sendmail

[flokli]

sendmail(1) allows additional recipients to be passed in the command line. The path to the message is never passed, it's always stdin:

sendmail [option ...] [recipient ...]

At least neomutt makes use of the recipient arguments (and doesn't set -t), so lieer needs to handle this properly.

Most sendmail implementations allow passing additional recipients in additional arguments, but there's no way to express this to the GMail API - it basically only supports the -t (--read-recipients) mode of sendmail, without additional recipients.

However, MUA can make use of both -t and additional recipients, even in a redundant fashion (with -t set, providing recipients in the message AND as recipient in the CLI).

We need to check if the MUA asks us to do something we can't do.

The following combinations are OK:

• When -t is passed, we need to check for the CLI-passed recipients to be equal or a subset of the ones passed in the headers.

• When -t is not passed, all header-passed recipients need to be provided in the CLI as well.

This avoids silently not sending mail to some recipients (pretending we did), or sending mail to recipients we didn't want to send to again.

Fixes #152

[gauteh]

Hi, I think this looks good, just a few comments. It would be good to get this tested wih emacs as well (@skangas, #139). I think that maybe the error messages will be hard to understand without context, or at least figure out how to fix them. Maybe link to the readme or some wiki?

[flokli]

@gauteh I updated the error messages a bit, they now say

"Recipients passed via sendmail(1) arguments" … vs "those in message headers"

IMHO, this should be clear enough - we can't really document how every MUA uses sendmail, and it can be altered through configuration anyways. lieer now just works in more of these possible combinations, to the extend of what the GMail API allows us to do without using SMTP.

Regarding emacs: My guess would be it just passed -t, didn't specify any additional recipients, and passed the message as stdin - otherwise I don't see how code in master could have worked at all.

But I agree someone running an emacs setup should at least verify sending mail still works after this change.

[gauteh]

Thanks, sounds good, but I can't see any changes? Did you push?

[flokli]

:facepalm: now I did!

[gauteh]

Thanks, merged, I changed ArgumentError to ValueError since the former needed more arguments. I tweaked the readme a bit, trying to condense it a bit more. It is already super-long. I think this was a very necessary change, thanks.

[skangas]

Hi, I think this looks good, just a few comments. It would be good to get this tested wih emacs as well (@skangas, #139). I think that maybe the error messages will be hard to understand without context, or at least figure out how to fix them. Maybe link to the readme or some wiki?

I didn't have time to test it in time before it was merged. I will report back if I see any issues.

[gauteh]

Stefan Kangas writes on May 19, 2020 2:18:

Hi, I think this looks good, just a few comments. It would be good to get this tested wih emacs as well (@skangas, #139). I think that maybe the error messages will be hard to understand without context, or at least figure out how to fix them. Maybe link to the readme or some wiki?

I didn't have time to test it in time before it was merged. I will report back if I see any issues.

Great, the safest is to add the -t option in emacs as well. I updated the wiki.