esmtp
esmtp copied to clipboard
Mails are lost if sending fails
Currently the client does not detect if a message is not sent and therefore it gets lost. It would be nice if the client would try to resend the message in this case. I discovered this during load testing in a system that is supposed to send mail on different events.
Would be great if this could be fixed.
I have submitted a bad fix in my forked repository, feel free to use it.
http://github.com/sedrik/esmtp
I'm not in favour of doing this in esmtp. The rules for re-sending messages with smtp are pretty complex and if I'm not mistaken, implementing these properly would require esmtp to turn into a real mailserver. I'd like to keep the esmtp code (brain-dead) simple, so I'm against merging a patch like this.
If you need smtp-compliant message retries (a perfectly reasonable requirement), I suggest configuring a local mail relay - something that will always accept mail from esmtp and then attempt mail delivery and redelivery. Postfix and exim running on localhost are both great at this kind of thing.
Would a setup like this solve your problem?
If we're talking about protecting against esmtp internal failures only, then yes - we could add a way to wait on the result of an esmtp_client run so you can figure out if it crashed or not. Your application would be responsible to retry failures however as you could get into overload and thrashing pretty easily with a naive retry policy.
I know that my solution is a bad one, it was just a quick fix to get the system I'm working on to behave.
Setting up a local mail relay would of course solve the problem or allowing my application to be notified if the send fails in whatever way so that I can take action (might be a better solution so I can propagate the error to the correct parts of the system). Having esmtp telling me that it could not send and why would be the ideal solution in my case.
Did this issue ever recieve any attention after this discussion? If else I need to investigate how much time it would take to implement such a solution myself.
Ops, accidentally closed the issue. Dont seem as I can reopen it :(
I have done a basic implementation of a callback function for this problem, you can view it in my fork.