Replies: 2 comments 3 replies
-
Thanks for the report. You are right. While the sendmail binary will not be waiting for a "." we should force the closing of STDIN so that the connection to receiving end can be completed with a EOF. I've added the forcefully close in commit 070eb39 and merged it into main. Please give it a try. I've also realized that sendmail is located in /usr/sbin on most common unix systems therefore the default path has been adjusted accordingly. |
Beta Was this translation helpful? Give feedback.
-
Thank you for quick update! May I ask to tag latest changes so that go modules system will see updates without the need to explicitly pull it via |
Beta Was this translation helpful? Give feedback.
-
Not sure if it's an issue or my bad understanding of how cli MUA works, so I open a question here in discussions. In my target setup I'm using
exim
to send mails to users. I don't have workingexim
setup on my dev machine, so I decided to write a small program to log all calls to "exim" to a file while testing everything.Here is how it looks like:
It uses own logger based on standard logger. This program is compiled as
exim
and put inPATH
. Not sure if originalexim
interprets "." as message ending, but added this just in case.What I observed, effectively, is that
WriteToSendmailWithContext
hangs unless there is timeout set on given context. In last case such call return an error. In logs I can see that reading fromos.Stdin
stops somewhere before last line and that's it:I looked at implementation and I think problem (if I get it right) is that there is no indication that message is done. There is neither a single dot on a line "." (not sure if it's a correct way of terminating message on
sendmail
-like cli) , nor closed stdin, because itsClose
method is called in deferred closure. Instead, I thinksi.Close()
should be called right beforeec.Wait()
so that stdin would be closed just after message written to it, but before program is exited.Beta Was this translation helpful? Give feedback.
All reactions