himalaya
himalaya copied to clipboard
soywod
Set up custom SMTP send command
https://github.com/soywod/himalaya/discussions/177#discussioncomment-2298474
For reference, this is how it works in Evolution: https://www.dropbox.com/s/r151wkp33y7480w/Screenshot%20from%202022-03-21%2006-19-42.png?dl=0
@soywod I've kind of started working on this, so here's what I've planned.
Git has chosen the approach of having a single option:
[sendemail]
smtpserver = /usr/bin/msmtp
On the other hand, mutt has a separate option:
set sendmail = "/usr/bin/msmtp"
The upside of Git approach is less ambiguity in semantics because both SMTP server and a send command cannot exist in the same configuration file. The downside is more ambiguity in the mean and purpose of the configuration option.
I'm leaning towards adding a new option smtp-host-cmd and sane defaults: if the configuration option exists for an account, it overrides smtp-host if they co-exists. Or should it be an error condition?
I can prepare a PR but need to know first the preferable semantics for the user interface :-)
@soywod I've kind of started working on this
First of all, thanks for considering helping the project! I invite you to read the contributing guide. I just realize that this guide misses information about the branch to start from (development). I also invite you to check this discussion about where I plan to bring the tool in the nearest future.
The upside of Git approach is less ambiguity in semantics because both SMTP server and a send command cannot exist in the same configuration file. The downside is more ambiguity in the mean and purpose of the configuration option.
Backends got the same dilemma (https://github.com/soywod/himalaya/issues/344). Using the untagged enum was a mistake because it leads to helpless error messages when the config does not match anything. We should go for an adjacently-tagged enum, which can be resumed by:
- introducing a config entry that will determine the type of the STMP client to use (let's say
smtp-client-type = "internal" | "script") - implementing those 2 structs (internal would be mapped to the actual
smtp-*config, and script would be mapped to a newsmtp-send-cmd)
It will break the API, but I'm OK with that. The tool is growing, breaking changes are unavoidable. Plus it did not reach the v1 yet, it is the good moment!
What do you think?
smtpserver = /usr/bin/msmtp
I just understood what you mean. The fact to use a path to an executable at the place of the smtp-server config entry. I'm not so fan because this will lead to some messy conditional stuff in the config parsing. I would like to keep it really simple and to let serde do the job as much as possible. I still highly consider the explicit way with an adjacently-tagged enum.
@soywod I've kind of started working on this
First of all, thanks for considering helping the project! I invite you to read the contributing guide. I just
Yeah, I mean I just found about this. It kind of complements my mutt workflow (I'm a kernel maintainer so a great email workflow matters to me a lot), rather than replaces mutt :-) This kind of command-line interface is perfect when you're working on e.g. a patch set, but do not want to do a full context switch to email but still want to have full access to it. Thank you for making such a great program!
I was thinking something along the lines of this.
SMTP:
sender-type = "smtp" # default
Sendmail:
sender-type = "sendmail"
sendmail-command = "/usr/bin/msmtp"
The 2nd is any command that is (semi)compatible with the command-line of the original sendmail program. smtp-* has effect when the sender type is SMTP, and sendmail-* for sendmail type.
sendmail is these days more like a "protocol" for piping an email to a command than the actual program that was called sendmail. I.e. himalaya speaks "sendmail", not SMTP, in this case by forming a compatible command-line, and piping the payload.
That's why I think that smtp and sendmail are better names than internal and script.
I understand your point. I was stuck to the fact that no matter if we use the Rust SMTP client or a script, it is still a SMTP client. Then sender-type makes sense.
To be in phase with https://github.com/soywod/himalaya/issues/344, I suggest the following:
# everything related to sending emails goes here,
# in contrast of having everything at the root level
# starting by `smtp-*`
[outgoing]
type = "smtp"
host =
port =
starttls =
insecure =
login =
passwd-cmd =
# does it make sense to have multiple types,
# one per tool (to maximize the compatibility)?
[outgoing]
type = "sendmail"
bin = "/usr/bin/sendmail"
[outgoing]
type = "msmtp"
bin = "/usr/bin/msmtp"
[outgoing]
type = "mailx"
bin = "/usr/bin/mailx"
# ...
The layout you proposed makes sense but I would add just sendmail type for now. It has worked for Git, mutt and Evolution for years and people use msmtp, mailx, ssmtp, postfix etc. as a drop-in replacement for it. So as long as the structure is extensible I would focus solely on sendmail and consider anything else on request. Sendmail has such a strong legacy that you cannot realistically make an MTA that does not adhere to it.
Maximizing compatibility should happen on-need basis but it is of course important to make design that allows to do it on need :-)
Thanks, from that example I anyway fully understood how and why you would prefer adjacently-tagged enum :-) Makes a lot of sense.
The layout you proposed makes sense but I would add just sendmail type for now.
Alright, let's go for it! Thanks for your precious help. Let me know if you need help implementing this.
Just for info, the development branch is a bit "messed up" because of https://github.com/soywod/himalaya/issues/340. For now I just moved everything in a cargo cli workspace, but stuff needs to be extracted into the lib workspace. Maybe it could be a good occasion for you to develop it directly inside the lib workspace to limit future conflicts!